0

Lets say that I'm building an website and a app which saves the users' secrets. The user logs in and can save into the app his deepest secrets.

I'm worried about two things:
- Should I save the password (hashed/bcrypted/etc)?
- How can I prevent people who has access to the database to be able to correlate the secrets with the users, with the emails?

I read a article recommending to not store the user hashed password and to not use traditional foreign keys to relate the tables. To use a hash as foreign key instead. How would it work?

If I don't save the password hash somewhere how can I verify if the username/password matches?

Improve this question

1 Answer 1

Reset to default
2

If you want to store data in a way that the person holding the data cannot read it, then

  1. You need to encrypt the data client-side. Encrypting server-side opens the possibility that someone (say, the operator of the service) can record the data while it's in transit.
  2. The encryption needs to be done using client-selected keys. If anyone else provides the keys, they can record them.
  3. The client needs to be storable offline (so the service operator can't tamper with it after the fact) and should have source code available (so the user can audit it to ensure it does what it's supposed to).

To prevent the service operator from associating data with an account, the "store" operation is not "associate a new record with this account", but "store a record tagged with this hash", where the hash in question is provided by the client (say, a salted hash of their password, where the salt is the index number of the desired record). Conversely, the retrieval operation is not "select records associated with this account", but "select records tagged with this hash". Further, the "store" and "retrieve" operations cannot require the user to be logged in. There's probably a way for a user to prove they have an account without revealing which account it is, but I don't know how to do it.

Theoretically, any user can request any other user's records, though with a 256-bit hash, the odds of any random request returning a value are vanishingly rare (1 in 10^68, if you've got a billion records stored). Since an attacker doesn't have the decryption password, being able to retrieve someone else's record is of little value.

Improve this answer
2
  • plus, encrypting server-side implies that the operator has the encryption key (slightly different from the "while it's in transit" consideration, but related.)
    – strugee
    Nov 17, 2014 at 7:09
  • It's worth nothing that client side encryption can still be vulnerable if you logging via a website as anyone in charge of the login box could change the code to steal the passwords. Viewing the JavaScript can help but unless the user sets up an automatic auditing system that checks the code hasn't changed every login it could be swapped out at any point, eg after 5 logins, for a specific user only, %3 of the time, etc...
    – David C. Bishop
    Aug 4, 2015 at 2:49

You must log in to answer this question.

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