0

I am designing an account system that will use salting/hashing to securely store and compare passwords. For now, I'm looking at using bcrypt for password hashing. Somewhere along the way I'll need a way to ensure that users can store secrets in their account. These secrets will need to be encrypted using a key derived from the user's login info and decrypted the same way. I want to make it such that even if someone has access to the whole database contents and source code for the front- and back-ends, they cannot access the data in these secrets. How can I do this?

If it's helpful, the web app is being developed with a Python/Flask backend.

Edit: These secrets aren't nuclear codes or anything like that. They're keys to unlock private messages and non-public chat rooms. I do not trust clients. I never trust web browsers...

Improve this question
5
  • 3
    I don't think we can provide a complete design for you, but generally this is done by generating an encryption key from the users password by using the same hash function that is used for password verification but with fewer rounds. Then do all the encryption/decryption of the secret client-side. You can, of course, use a completely different hash function for key generation, but that would be unnecessary complication.
    – nobody
    Feb 8 at 4:03
  • 2
    This sounds similar to how a password manager works. When I was building one I read most of bitwarden.com/images/resources/…, which gives fantastic details on how BitWarden implements a "zero-knowledge" architecture. It's basically what @nobody says above, but with a few additional steps for key strengthening, and ensuring the server never has direct access to the master password, derived secret key, or any of the plaintext secrets (sent either hashed or encrypted, depending on what it is). I'd also check out the SubtleCrypto API for client side crypto
    – ChristianF
    Feb 8 at 8:03
  • 1
    See protonmail.com/blog/encrypted_email_authentication for an interesting read on how protonmail uses SRP to derive two keys from the user's password - one that is used to authenticate with the server, and another that is used for client-side encryption.
    – mti2935
    Feb 8 at 13:10
  • 1
    If you do not trust clients or browsers, how will users access the chatrooms?
    – schroeder ♦
    Feb 8 at 15:15
  • @shroeder fair point...
    – AwesomeCronk
    Feb 9 at 0:56

1 Answer 1

Reset to default
3

In my opinion, there is a responsibility question here. If the secrets are really secrets and you do not want to be liable for leaking them, do not know them.

That means that the encryption/decryption should occur client-side, and your application only processes opaque data without being able at any time to access the plain text data. Secure, but not really sexy.

If the legal responsibility is not a problem (the secrets are not nuclear weapon codes, are they?), a common workaround is to ensure that data at rest cannot be enough to extract the plain text information. This is much more than obfuscation because it means that the decryption key is never stored in any form on long term storage. For example, you could derive a master key from the user password and only keep it in session memory. But this is still vulnerable to a rogue admin or security flaw in the application which is clearly your responsibility. Because as the master password exists in clear form in the machine memory, it can possibly be extracted, and from there on decode and leak any secrets...

This is the reason why some of us are reluctant to use remote password managers, simply because whatever security practices are advertised by the site owner, it means an additional security zone to trust.

Improve this answer
2
  • This is an interesting read for certain! I'm not sure how I would be able to manage this, as the secrets will be necessary to access things like private messages and chat room contents. To top it off, I don't trust the clients, because the secrets have so much data locked behind them that may belong to multiple users.
    – AwesomeCronk
    Feb 8 at 13:14
  • 3
    The technics will only be the implementation part. What matters on a higher level is who is the owner of the data and who is responsible for the security of the data. Nothing is bad in endorsing that responsibility. For example the bank has the true access to your accounts and you do not, so the responsibility is their. You just have to be aware of it and as much as possible to make it clear in the presentation of you service.
    – Serge Ballesta
    Feb 8 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.