User Authentication

Key-Based Management

In typical Web 3.0 fashion, Kwil utilizes public/private key-pairs to verify all user interactions and access. By matching a 4096 bit RSA-PSS key to each unique username, Kwil Social Gateways can easily verify any data entry by checking the submitted data and corresponding RSA SHA-256 signature against the publicly known user modulus.

Creating An Account

An account can be created by sending a POST request to the /createAccount endpoint. The request data must contain data formatted in JSON that contains both mutable and immutable user data and signatures.

The signatures must be SHA-256 signatures using the private key whose modulus is stored in the "modulus" field.

If a username already exists on that moat, it will reject the new username, so it is advised to check if a user exists before registering:

curl https://demo.kwil.xyz/{some_username}/ifUserExists

curl -d {data} -X POST https://demo.kwil.xyz/createAccount

Data Format:

{
    #mutable data
    username: SOME_USERNAME,
    modulus: RSA_MODULUS,
    name: '',
    bio: '',
    pfpHash: '',
    bannerHash: '',
    settingsHash: BASE64URL_ENCODED_HASH,
    settings: SETTINGS_CIPHER_TEXT,
    signature: sign({
            username: SOME_USERNAME,
            modulus: RSA_MODULUS,
            name: '',
            bio: '',
            pfpHash: '',
            bannerHash: '',
            settingsHash: BASE64URL_ENCODED_HASH,
            settings: SETTINGS_CIPHER_TEXT,
    }),
    
    #immutable data
    salt: SOME_SALT,
    login: LOGIN_CIPHER_TEXT,
    creationSignature: sign({
            username: SOME_USERNAME,
            salt: SOME_SALT,
            login: LOGIN_CIPHER_TEXT
    })
}

Secure Key Storage

All user authentication keys are encrypted using AES-256 and stored on each node. The cipher-text for any user key can be easily retrieved by requesting a node's "login" endpoint:

curl https://demo.kwil.xyz/brennanjl/login

To decrypt the user's RSA key, you need to generate the AES Cipher Key. All AES Cipher Keys are generated using 8192 iterations of the Scrypt slow hashing algorithm to help prevent against brute-force attacks. Each Scrypt iteration is performed with the account's publicly known 16 byte salt to help prevent against rainbow hash table attacks.

Furthermore, if a private key were to somehow get leaked, data-moat owners have the ability to reset any usernames salt, modulus, and key cipher-text, acting as a final fail safe for account security.

Account Scrypt Passphrase

By standardizing login cipher keys with a hashing function, the main concern of account security breaches comes from the use of weak / reused passwords. Therefore, Kwil Social provides the ability for users to either use a regular username password login, or for users to substitute their password with another RSA Signature. Users can utilize crypto wallet services (such as MetaMask) to generate RSA SHA-256 Signatures to be used for sign-up. By signing their accounts own salt, these signatures can be used in lieu of of a passphrase for sign-in/sign-up. Effectively, users can replace their authentication with a more Web 3.0 friendly method, while not exposing their personal crypto keys to any additional risk.

Potential Security Risks

As with any system, this method of user authentication does present some security risks. Below are the three most common ways in which a user's account access could be compromised:

1. A user could use a weak / reused password, opening the door for a potential brute force attack. Since user key cipher-text is stored publicly, accounts will be more prone to brute force attacks. Therefore, it is extremely important that, should a user choose to use a typical password login, that they follow good password security practices.

2. A user could accidentally sign their salt on an untrusted website. While your signature only exists for a brief moment in memory on the Kwil Social application, other websites could try to phish your signature. Since wallet services like MetaMask ask the user before signing data, this would require a fair amount of user error, however it cannot be ruled out as a potential attack vector.

3. An attacker with access to the victim's machine could access poorly stored keys. With enough time and knowledge, an attacker who physically has access to a user's machine (and therefore browser) could access keys stored in insecure methods.

Good to know: While several attack vectors may exist to target a user's account, it is important to note that at no point could a data breach reveal your crypto wallet keys. Furthermore, data-moat owners and operators have the ability to reset user authentication, allowing for accounts to be recovered.