Is still valid password hashing using md5 or sha1?

Question

Just now I'm working in a financial project. Here, the team is thinking to use MD5 for password hashing. But, today is easy copy a SHA1 or MD5 password to decrypt, inclusive if they are complex password like: My$uper$ecur3PAS$word+448, you might use a online page to decrypt it and there is it. Small and mid-range developers (including me) uses those hashing methods, but I think is not enough to provide security over the database. (Excluding firewalls, network security, iptables, etc.).

Can someone give me a clue about what is the better approach to solve this vulnerability?

Answer 1

As per OWASP Password Storage Cheat Sheet, the recommendation is:

• Argon2 is the winner of the password hashing competition and should be considered as your first choice for new applications;
• PBKDF2 when FIPS certification or enterprise support on many platforms is required;
• scrypt where resisting any/all hardware accelerated attacks is necessary but support isn’t.
• bcrypt where PBKDF2 or scrypt support is not available.

MD5 and SHA1 are not secured for most security related use cases, because it is possible to find collisions with these algorithms. In other words, given an input and its hash value, it is possible to derive another input with the same hash value.

SHA-2 group of hashing algorithms are secured for many security use cases, but not for password hashing because they are blazingly fast when compared with the above algorithms. And performance is something we don't want for password hashing because that would make it easier for an attacker to perform a brute-force attack by trying a wide range of passwords in a short period of time.

The above 4 algorithms are therefore meant to be expensive in terms of memory, computation power and time. These values are usually parameterized so that they can be tuned to a high value as new technologies improve the computation power with passsing time. Therefore while using these algorithms, it is important to choose the work factor values correctly. Setting a very low valur may defeat the purpose.

In addition to that a salt should also be used.

Again from the same OWASP source:

• Generate a unique salt upon creation of each stored credential (not just per user or system wide);

• Use cryptographically-strong random data;

• As storage permits, use a 32 byte or 64 byte salt (actual size dependent on protection function);
• Scheme security does not depend on hiding, splitting, or otherwise obscuring the salt.

Salts serve two purposes:

• prevent the protected form from revealing two identical credentials and
• augment entropy fed to protecting function without relying on credential complexity.

The second aims to make pre-computed lookup attacks on an individual credential and time-based attacks on a population intractable