Designing the Password Manager Backend

[DenizAltunkapan]

We need to discuss how to securely design the backend of our Password Manager. The main concern is that we cannot rely on the JWT secret key or standard encryption alone, because that would allow the server owner to decrypt and access all stored passwords. We need a strategy where passwords remain encrypted in such a way that only the user can decrypt them, while still enabling CRUD operations through our backend.

Key points to consider:

• Avoid using the master key or JWT secret as the sole encryption key for passwords.
• Explore client-side encryption approaches (e.g., user-derived keys) so the server never sees plaintext passwords.
• Maintain usability for operations like password retrieval and updates without exposing sensitive data to the server.
• Integration with the existing PostgreSQL setup and Vault Web Docker environment.

Question to participants:
@MaximilianRau04 @DevEpso @hamadiddi, how do you propose we handle password encryption in the backend so that the server and other people never has access to the plaintext passwords? Should we implement client-side encryption, or do you have other secure approaches in mind?

[MaximilianRau04]

We could adopt client-side encryption (zero-knowledge) so the server never sees plaintext passwords. Concretely:

• The client derives a per-user key from the master password (Argon2id) and encrypts/decrypts entries locally (AES-GCM/XChaCha20-Poly1305).
• The backend stores only ciphertext + metadata (nonce, version, optional blind indexes).
• For sharing or recovery we can add envelope encryption with a KMS/Vault, but this must be opt-in and auditable.

This approach prevents server/admins from decrypting user passwords while still allowing CRUD via ciphertext storage. I can draft an API/DB schema and a step-by-step flow if you want.