Salt to user table

[maitsarv]

Add salt column to user table and generate a random salt on user add. For password hashing combine the generated salt and env variable salt.

This adds extra protection against cases when database might be comprised. If salt is unique, then guessing one password does not give good hints for other passwords.

[Alex-CodeLab]

iirc, Argon2i already 'salts' the input, it is the first part of the string

[maitsarv]

It does not seem so. If I look at the login handler, then it just hashes user input and compares it to the hash in database. If salt would be stored in the password hash, then it would have to extract it before hashing the user input.

[Alex-CodeLab]

yes, but the hash function is from argon2i_simple (perhaps it should not have been named hash, because it is more then that) ,

rust-actix-example/src/auth.rs

Line 50 in 4b7c224

argon2i_simple(&password, &CONFIG.auth_salt)

and
https://bryant.github.io/argon2rs/argon2rs/fn.argon2i_simple.html

(I didn't check how it works internally, so I might be wrong)

[maitsarv]

Ahaa, yes argon2i_simple is the hashing function, but the salt there is only the server side secret salt (that is shared for all the passwords).
Using only server side secret gives some protection against password hacking, but it also has some weak points.
I'll list some pros and cons of using just server side salt and per password salt.

Server side secret salt
Pros

• If only database is compromised (and not to server side secret salt), then it is close to impossible to crack the passwords.

Cons

• Users with same password will have the same password hash.
• If hacker has access to database and to server secret sThe onlyalt, then all passwords can be cracked all at once.
• In case of this project it is likely that programmers will not generate a new salt (or would only make minor changes), so if only database is compromised, then guessing the salt would be good option for cracking passwords.

Per password salt
Pros

• If database is compromised, then all passwords need to be cracked one by one.
• All the hashes are different, so guessing passwords based on other known passwords would not be possible.

Cons

• It is relatively simple to crack "easy" passwords.

Using server side secret salt and per password salt together gives best of both worlds. One con that will remain is that when database is compromised and server side secret is known, then it is relatively simple to crack easy passwords.