Password Manager with Zero-Knowledge Architecture

Here, i will explain the core features of this application, namely how the encryption and decryption processes work in the authentication section and the items that will be stored by the user's.

This registration process will be divided into 3 sections, The first section is telling you to submit a username and email, after submitting, you will get OTP verification for the next section to proof yourself if the email is really yours.

The second stage is telling you to submit the OTP verification sent to your email.

The last section, After OTP verified the user requested to create their password and all the encryption process is happen on the browser (client-side).

Passwords are not simply hashed and then entered into the database. The system generates a random salt and uses the Argon2id algorithm to convert the master password into a master key. From this master key, the system also derives an auth_verifier using HKDF-SHA256 as proof of password knowledge. The master key then encrypts the Data Encryption Key (DEK) a 256-bit random key using XChaCha20-Poly1305 with a unique 192-bit nonce. The encrypted DEK (encrypted_DEK), nonce, salt, Argon2 parameters, and auth_verifier are stored in the database.

When logging in, the user enters the master password; the system takes the salt, nonce, and Argon2 parameters to regenerate the master key on the client side. The client then decrypts encrypted_DEK if decryption fails (Poly1305 authentication tag does not match), it means the password is incorrect.

Next, the client derives the auth_verifier and sends it to the server for constant-time verification against the stored value. With this architecture, the server never knows the user's master password (zero-knowledge). All sensitive data (e.g., Facebook password) is encrypted with a unique DEK and nonce, ensuring that the ciphertext is different even if the data is the same.

After the user successfully logs in, the decrypted DEK (Data Encryption Key) is temporarily stored in the browser's sessionStorage. This DEK is used to encrypt and decrypt all sensitive data in the vault without having to re-enter the master password. When the user saves a new item (e.g., Facebook account credentials), the encryption process occurs entirely on the client side using WebAssembly (WASM). The system generates a unique 192-bit random nonce for each item, then encrypts the data using the XChaCha20-Poly1305 algorithm with the DEK as the key and Additional Authenticated Data (AAD) as the validation context. The result is ciphertext that includes the encrypted data along with a 128-bit authentication tag to ensure integrity. The encrypted data (encrypted_data) and nonce are sent to the server for storage, while the DEK is never sent to the server. The decryption process occurs when the user wants to view the stored data.

Client retrieves encrypted_data and nonce from the server, then uses the DEK stored in session Storage to decrypt. The XChaCha20-Poly1305 algorithm first verifies the authentication tag if it does not match, decryption is canceled because the data may have been modified (tamper detection). If valid, the plaintext is returned to the user.

That's it, those are all the core features of this application. There are still features such as rate limiting with Redis, but it seems that they don't need to be explained in the context of this password manager application.

Here is my github repository for this app: secure vault