1

Language used is Javascript.

For context, I am making a password manager where users can store different accounts of service and their passwords. The idea was to store multiple encrypted passwords in the database and decrypt them on the client side to display them to the users without any input from the user.

What is the ideal way to go around this?

I am aware this method is not recommended as the encryption key could be stolen from the client side. Regardless, I would like to hear any thoughts on this.

Improve this question
9
  • 1
    I've edited your question and changed "hashed/encrypted passwords" to only encrypted since hashed cannot be decrypted.
    – Steffen Ullrich
    Jan 13 at 17:59
  • @SteffenUllrich Okay, thanks buddy
    – cannons
    Jan 13 at 18:00
  • 1
    Just checking, is this a serious product you're making, or a toy/academic thing? Because there's a substantial number of zero-trust end-to-end encrypted online password managers already, and - even if you have some feature you want to create that the existing ones are missing - if you have to ask a question like this, you shouldn't be trying to create a new one.
    – CBHacking
    Jan 13 at 18:17
  • 2
    Check out the web crypto api. This API contains a complete set of cryptographic primitives that you can access using client-side javascript.
    – mti2935
    Jan 13 at 18:29
  • @CBHacking, it's an academic thing. Just a school project I'm working on.
    – cannons
    Jan 13 at 18:45

1 Answer 1

Reset to default
1

You might be able to "enjoy both worlds" in the following sense: Assuming that the server doesn't need to know the actual contents of the passwords you can employ the following scheme:

  1. The client generates a client key for the password
  2. The client encrypts the password via said key
  3. The client uploads the client encrypted password to the server
  4. The server, before storing this ciphertext in the DB, also generates a key and
  5. The server encrypts the password with this independent, server generated key
  6. The server stores the password in the DB which is doubly encrypted (first via client key, then via server key)
  7. Needless to say, before the server sends a password to the user, it will need to remove its own layer of encryption (=decrypt) via using the same key it generated.

Now, perhaps the most important point which is relevant to the security of this entire setup, is that the client key/s should be protected via a passphrase that the client must enter whenever he wants to access a password. Ideally, the program should be written so that the client key/s are always stored encrypted and get decrypted only in volatile memory after the appropriate passphrase has been entered. You can then derive a "main client key" from this passphrase...

This is only a rough sketch of how to tackle this, and a lot more can be done to improve this probably. For example if you're talking about Windows in particular, you can employ DPAPI and in some scenarios it can replace the passphrase...

Important comment: whenever I wrote "generate a key" it also means that you need to store this key somewhere, since those are long term keys (used for encryption of what is, eventually, persistent data in the form of a password, as opposed to transient keys which are employed for example, for communication...)

Improve this answer
2
  • BTW if you need to authenticate to a server anyway, you can store the client key there as well (and the server can protect it via a server generated key). It's a rule of thumb in client-server architectures that a server is less vulnerable than the client (which is usually true, as you have more control over the servers), so it follows that you should prefer using that server to store sensitive data, over storing it on the client side. Then essentially the authentication step (which is for example, password based) is your "bridge" to the sensitive data that's on the server.
    – Amit
    Jan 25 at 19:31
  • The down side of that is the privacy aspect: if the server knows your client key, it can decrypt your local password data. So consider mixing both secret materials that are on the server and on the client, to derive the final client key. ("Enjoying both worlds" once more :))
    – Amit
    Jan 25 at 19:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .