where to store the salt for "crypto_pwhash" in a web application with no local storage

Question

I am developing a web application which stores encrypted data on a server. I want to derive the encryption key as well as the login key from a single user password, so I want to use libsodiums crypto_pwhash to generate a long enough key, that I can split in two. The idea is that the server cannot decrypt the encrypted data.

To use this function it needs a salt. I understand that the salt may not be secret, but it must be stored somewhere.

• If I store it in the server, it must be retrieved before authentication (because it is needed to derive the login key). So this would allow for testing if a username exists without knowing its login key. I am unsure if that would be a security risk.

• Could I derive the salt some other way? What if I would just hash the username? Or the password itself? Or would I run into the risk of not having enough entropy?

Answer 1

The required property of a salt is to be unique, cause it make impossible to use dictionary table for reverse hash of all user with the same table.

The other usefull property is to be impredictable so attacker can't pre calculate dictionary table before obtening the salt.(scenario where this is usefull : the attacker detect a security problem he can use to obtain password hash, he generate a table for the username he want to access then when he obtain the password he can use it before you can react to the attack)

random salt give the two property.

Using site name + username give you the first property.

password give you nothing cause when generating a entry in your dictionary table you know the password (the one you are hashing).

If you store it on the server you can respond to request with invalid username by an random number of the same size of your random hash(this is only obscurity and absolutly no security)

Answer 2

I think the way to go about this problem is to separate, as much as possible, authentication and confidentiality. The ideal way to do this would be to have two passwords, one for authentication and a completely independent one for confidentiality. The problem is, users are not ideal. Likely they would make the password the same or add some very predictable string to the end of the confidentiality string.

The other thing to remember is that since this is a web application, I'm assuming that all the computations are taking place in javascript that the server sends to the client. This makes your adversary model interesting. If you are trying to protect confidentiality from a malicious server, but allowing that server to send you code (javascript) that you will run and that will have access to the password, you really can't protect yourself from a malicious server. Nothing stops the server from sending you javascript that performs as expected but also sends the password to the server.

So, you are definitely in a quandary and I think without additional assumptions and a better defined adversary model, you cannot protect the confidentiality of the data.

Answer 3

If I store it in the server, it must be retrieved before authentication [...]

It would be retrieved at the same time as authentication, like

select salt, pw_hash from users where name = '@name'

You would use both salt and pw_hash to validate the password that the user entered. You still might want to be careful about leaking information about whether your select returned a record or not, but that isn't complicated by the salt.

Your situation is complicated because you also want to derive an encryption key from the user's password such that the server can't do the same. Part of the confusion is because the user has a single password that he can't give to the server but it must somehow be used to authenticate the user - and therefore whatever is sent to the server is not strictly speaking a password. But most of the time you are read about salting and hashing inputs they will be called passwords.

So let's break this into 2 steps. The user enters a password. For authentication, the user runs some KDF without salt and send the result "C" to the server. The server looks up the user's salt, hashes the salt and C and compares that to its stored hash. If successful, the server returns the salt (either the same or possibly a different one) to the user. The user combines the password and the salt using KDF2 to get his encryption key. If the two KDFs are different, or are tweaks of one another, the two keys generated will not be related.