Hashing Passwords and Hash Functions

Question

I'm a complete noob. I was reading up on hash functions. So if a bank has its user password's run through a hash function, it'll produce a unique hash for every password right? Thus, even if hackers are able to get their hands on some data, they'll only have the hashes and not the original passwords.

But I also read that if a hacker runs a lot of common passwords through a hash function, and then compares the common hashes he generated with the stolen hashes, he can find the original passwords out.

My question is, the hacker can do this only if he knows how the hash function (used by the bank) works. He obviously can't generate the hashes of common passwords if he doesn't know how the hash function used by the bank works. So then why is hashing without salts a security hazard? Does this mean that all hash functions work the same?

Answer 1

My question is, the hacker can do this only if he knows how the hash function (used by the bank) works. He obviously cant generate the hashes of common passwords if he doesn't know how the hash function used by the bank works. So then why is hashing without salts a security hazard? Does this mean that all hash functions work the same?

Your premise is wrong as you assume that banks are secure against hacking and keeping the password hashes from the attackers. If ever banks use password hashing without salts then their risk management is very bad, they need to fire the risk analyzers.

So, when the bank uses password hashes without salt it is a matter of time that they are attacked and almost all passwords are easily revealed.

Hopefully, the banking systems are not only relying only on passwords since their risk is higher. They usually require two-factor authentication, One-Time-passwords, etc.

And remember that, we don't use cryptographic hashes as password hashes since they are designed to be fast and secure. Modern Password hashes, on the other hand, require, unique salt and;

• controllable iteration to reduce the attacker's massive parallelization,
• high memory to reduce the massive usage of ASIC/GPU-like environment, and
• adjustable threads to reduce parallelization.

Some good password hashing algorithms that you may want to look at are Argon2, Scrypt, and Balloon hashing. In the end, password hashing without a unique salt is not recommended. If used then Rainbow Tables are the monsters lurking on the next street...

Answer 2

He obviously can't generate the hashes of common passwords if he doesn't know how the hash function used by the bank works.

This is the faulty premise. If a bank wants to have FIPS certification, for example, then it must hash passwords with some good, standardized hash function. Security of password-based authentication does not stem from secrecy about how a hash function works --- that would be considered "security-by-obscurity". Regardless of any kind of government certification, it's just bad practice to let security-by-obscurity be the main basis of your security. See Kerckhoffs' principle.

However, it is possible to incorporate "secret" information as inputs to the hash -- information that the attacker doesn't have.

• Salt is extra information used as input to the hash, but stored alongside the password hashes. So if an attacker can obtain the password hashes, they can generally obtain the salts, too. Salts don't prevent the attacker from trying common password guesses. But they do prevent pre-computation like rainbow tables --- the attacker can't start trying common password guesses until after learning the salt. Salts also "personalize" the hash function, so that two users with the same password don't have the same has.

• Pepper is extra information used as input to the hash, that is not stored alongside the hash outputs. Pepper is truly secret, since it may be possible to steal the password hashes without also stealing the peppers. The authentication system needs to be set up to allow for pepper. Server #1 holds the password hashes and collects the password from the user. A separate server #2 (generally much more locked down from the outside world than server #1) holds the pepper and computes the hash. Server #1 then compares the newly-computed hash to the stored hash and makes the decision to authorize the user.