0
votes

as I understand it, user passwords must be stored as hashes instead of encrypted, because an attacker cant deduce a password from its hash, while he can deduce a password from its encryption, if he gets access to the encryption key.

Now, obviously every system must use a different hashing function to hash its keys. My question is, how do they create these different hashing functions? Do they use a standard hashing function and prime it with a big key? If so, wouldn't an attacker be able to deduce the passwords if he got access to this key, making it the same as encryption?

2
Please search the Internet and StackOverflow archives before posting a "new" question.Prune
I'm voting to close this question as off-topic because this is not about programming. Information Security is much better suited for this type of question. Please check out other questions beforehand.Artjom B.
Don't mix up encryption and hashing. Those are two different approaches. Hint: iterated hashing functions take a random salt.Artjom B.

2 Answers

1
votes

Cryptographic hash functions are always non reversible, this is their purpose. Even discouraged "unsafe" function like MD5 and SHA1 are not reversible and they don't need a key. The problem is that you can find possible matching passwords too fast with brute-forcing (more than 10 Giga MD5/sec).

The "big key" you mentioned is probably the salt. You generate a random salt and use this salt in the calculation. It is safe to store this salt together with the hash, because its purpose is to prevent the attacker from building one single rainbow-table and finding matches for all passwords at once. Instead (s)he must build a rainbow-table for every salt separately, what makes those tables unpracticable.

The problem with the speed you can only overcome with iterations of the hash function. A cost factor defines how many times the hash is calculated. Recommended algorithms are BCrypt, PBKDF2 and SCrypt.

0
votes

Now, obviously every system must use a different hashing function to hash its keys

No, they don't.

If your password is s3cr3t, then it will have the same hash value in the database of a lot of servers, sadly likely A4D80EAC9AB26A4A2DA04125BC2C096A

The way to make this suck less is to generate a random code per password, called a salt, so that the hash of s3cr3t on server 1 is likely to be different than the hash of s3cr3t on server2: hashFunction('s3cr3t' + 'perUserSalt')

Use bcrypt, scrypt, or PBKDF2 only for password storage.