Why SHA-256 is not enough to store passwords
Hash file and saving password on the server have different requirements. For passwords it also counts the cost of each attempt to guess.
In this guide
Hashination is not an encryption. The cipher can be decrypted with the right key. The shortcut function does not offer an analogous reverse operation. However, this does not mean that the password saved as a shortcut remains out of reach of the attacker.
After the leak, the attacker can guess the passwords locally: calculate the result for each proposal and compare it with the stolen record. At the same time, he does not have to go through the limit of your application login attempts.
SHA speed becomes a flaw
SHA-256 is perfect for many cryptographic applications, including integrity checking. It is designed for fast processing of data. However, for storing passwords we want each attempt to cost the attacker noticeable resources.
Adding salt to SHA256(sól + hasło) does not solve the problem of speed. Salt and cost of calculation perform different roles. Do not replace the specialized function with your own shortcut loop or design your own format of certifications.
Use the library to hash passwords
For the new solution OWASP indicates Argon2id as the preferred choice. Scrypt is an alternative when Argon2id is not available. PBKDF2 applies among other things in environments with specific compliance requirements. BCrypt is needed in older systems, but has limitations, including input length.
Select the maintained library with the creation and write verification functions. It should support salt generation and storage of parameters. Select cost parameters according to current recommendations and measurements on the target server, taking into account parallel logins and resource limits.
The high cost of one operation must not allow for easy overloading of the service. Online protection still requires reduction of tests and load control.
Salt, parameters and pepper
Salt is a random value for each record. It does not have to be secret. Thanks to it, the same passwords do not give identical entries, and work performed for one record does not move directly to all others.
In the database, you also keep the algorithm identifier and parameters needed for verification. Libraries often place them together in one encoded string.
Pepper This is an optional extra secret stored outside the password database. It can help in specific spill scenarios, but it makes key management and rotation difficult. It is not a substitute for salt or proper hash function.
How do you raise costs without knowing passwords?
When successfully logging in, the application has a password given by the user. First it verifies it according to the old record and then, if the parameters are out of date, creates a new record with the current settings. This is a typical moment for rehash.
You will not recover the original password from the current shortcut to recalculate the entire database. For accounts that do not return to the service, a separate migration or reset policy is needed.
Before implementing, check rejection of the incorrect password, migration of the old record, length limits and load behaviour. Do not log on the passwords or send them to analytical tools during these tests.