Best practices regarding password authentication for a Web service

[mkpankov]

Hi. I'd like to ask some advice regarding the best way to use this library to implement password authentication for a Web service. I understand this might be out of scope of the project so please forgive me if I'm asking too much.

I'm using HTTPS to connect to server. My client is in Rust compiled to WASM, server is in Rust. There are several questions:

1. I've read that applying salt to hashed password is a good practice. How do I obtain this salt so that it would make sense
   from cryptography point of view? Doesn't look like I can pick any string of any length. Also, does it need to change? Should it be per user or per request? Should I apply it before or after hashing (since library has both)?
2. Do I transmit the password in plain text over HTTPS and hash it on the server? I've read conflicting arguments on this. I believe this is the correct way to hash password and store it in the database because otherwise I'm trusting client's code and the password hash itself becomes visible on the wire for any MITM attacker (hence becoming the password).
3. Example of doing password authentication has a case for password schema update. It says we should hash it again. Since we're not storing the original password, we should be doing a password reset procedure for the user, so that they can enter their old and new passwords, and we could hash new one and update the schema. Is that correct?

[breard-r]

Hi!

1. LibreAuth already handles the salt, you don't have to do it yourself: each hashed password has a random one. Although you can change the salt's size, I would recommend to stick to the default value.
2. Yes, transmitting the plain-text password over HTTPS and hashing it on the server is the most common and easiest way to go. It's ok to do it as long as your HTTPS stack is secured (no self-signed certificates, no deprecated protocol versions, no weak cipher suites, etc).
3. Yes and no. Instead of creating a specific procedure, the best way to do so is to do it when the user logs-in since that, at this moment, you have the plain-text password.

Concerning your second question, here is more detailed answer since it's a really interesting topic :
When talking about a web application, the main use of such protocols was, before HTTPS was wildly supported, to prevent the plain-text password being sent on an unprotected channel. A good example of such an historic and now deprecated protocol is DIGEST-MD5 (RFC 2069). In this context, now that HTTPS is almost everywhere, there is little use for such things. Sometimes you may encounter other protocols, like SCRAM, but I think (this is a personal opinion, don't take it for an authoritative answer) they are mostly relics from the past and therefore not worth the implementation cost.
However, there is some other contexts where it is necessary to use protocols where the password is never sent to the server. The current best practice to do so is to use a PAKE (like OPAQUE). A well-known use-case is WiFi: WPA3 uses SAE, which is a PAKE.
However, unlike sending the plain-text passwords, PAKE are not (yet?) supported by ACMEd.

[mkpankov]

1. I must have misunderstood the purpose of xhmac_before and xhmac_after. Is the key word here "additional"?

[breard-r]

Is the key word here "additional"?

Exactly. Those functions adds an extra hash either before or after the real hash computation. This extra hash uses a pepper (I wrongly used the term salt, it's corrected but not published yet) which is common to all passwords.
The key for understanding the purpose of this operation is the pepper: you have to provide one that will not be stored in the database and must be kept secret. Since this pepper is required to compute the hashes, should your database leak (following an SQL injection or anything else), an attacker will not be able to crack the hashed passwords.

This is a nice thing to have, but it's far from perfect. The main disadvantage is that the pepper is almost impossible to rotate. If it leaks, you're doomed. Sure you can create a new version that uses a different pepper, but that's a bit cumbersome and users that have not logged in since the change will still use the old pepper.

In the future, I will add to ACMEd a different feature with the same purpose but not the same issue: hash encryption. You will also have an external secret key (similar to the pepper), but this time it will be used to encrypt the hash. It provides the same protection over database leaks, however it can be rotated whenever you have to. I would strongly recommend to rotate it on a regular basis.