I'm a bit new to the cryptography field (completely new), and could really use your guidance.
Please, correct my understanding, as defined by the following statements.
Argon2Hash Generator has won the Password Hashing Competition, and is therefore believed to be the best solution at the moment for safely hashing passwords. Is is recommended to be used instead of
Argon2requires additional configuration, through parallelism factors, memory cost, iterations and hash length in order to be used in the most effective. However, default parameters are usually just fine.
Argon2also requires a 'salt' for security reasons - this one is meant to be generated using Cryptographically Secure Pseudo Random Number Generators (CSPRNGs for short), but any reasonably random value can be used here.
Some implementations of the
Argon2(such as this one), allow to secret keys and additional data to the function, but these are optional and are not required for the resulting hash to be secure.
Since any reasonably random value can be used as a salt, the result of another hashing function, such as
Blake3, could also be used as a salt.
If I want to store both email hash and password hash securely in a database, for the potential attacker to have as little information about the user as possible, I could:
- Store the registration date (RD) of a user
- Generate the
Argon2hash of the email address, using the
Blake3hash of the RD as the salt
- Generate the
Argon2hash of the password, using the
Blake3hash of the
Argon2hash of the email as the salt
The point above would not compromise the security, offered by the
Argon2hash, and would make it quite difficult for anyone, even those with a direct access to the database and the source code, to figure out what the email and the password of the user actually are - but would make it trivial to verify whether the user's input was correct or not
Any criticism, comments, thoughts, opinions (grounded in facts) - are more than welcome.
Correction: as Marc pointed out, 6.2. doesn't make any sense - it would make it (nearly) impossible to look the email up for a registered user. If we substitute the step 6.2. with a random scrambling of the user's email - such as Fisher-Yates Shuffle, repeated for X iterations - to make it consume time, using a random generator from this function, with a seed number derived from the email once again, would the rest still make sense?