Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- Passwords: to crypt or to hash?
February 10, 2011, 3:38 pm
rate this thread
I always thought that it was best to store crypted passwords but I
read recently that hashes are stored rather than crypted versions. I
have a question about this....
First, it goes without saying that if crypting is used the password is
never decrypted. A password check is done by crypting the attempt and
comparing the crypted attempt with the stored crypted password. Now
I've got *that* out of the way....
I recently came across bcrypt. It caught my eye because it said that
many systems store passwords as hashes and hashes by their very nature
are fast to produce, making dictionary attacks possible. The hashing
algorithm for bcrypt is designed to be expensive to compute so
passwords hashed using it are resistant to dictionary attack. This was
news to me. I always thought that in UNIX systems the password was
stored crypted using a modified form of DES with added salt. It seems
from the bcrypt article that some versions of UNIX do still do this
(e.g Linux) but others, notably ones based on freeBSD do not.
So my question is "Why have systems moved from crypting passwords to
storing a hash?". I dont understand why this should be if it makes
them vunerable to dictionary attacks. Can someone explain please?
If one wants a better crypting algorithm than the modified DES there
are loads to choose from. Triple-DES seems pretty good, and of course
there is AES. Why aren't login passwords stored using these
Re: Passwords: to crypt or to hash?
So is encryption fast to produce, -- that is one of the design goals of
encryption. To get around this the password hashing routines engage in a
whole bunch of irrelevant operations as far as hashing is concerneed (
eg rehash the password with the old hash 1000 times after bit
rotatatine, permutting, etc the old hash.)
That is of course an idiotic design goes for encryption. However, it is
also a really really bad idea, because then the sysadmin can decrypt the
password and know what password the users use. This then allows them to
try that password on any other system the user uses ( eg bank accounts).
The password should be stored in a form hidden from EVERYONE.
Completely bogus claim.
The crypt(3) based ones are too fast. The BSD MD5 based one ( it is NOT
MD5 it uses MD5 like the old unix one uses des as one element in a huge
The unix one was also a hash. It was NOT a crypt. It used, as one of its
elements the encryption of a set string using the password as the
password to a modified des. Systems have always used hashes not
Explain what? Your premise is false.
Re: Passwords: to crypt or to hash?
Very few systems have ever stored crypted passwords. Unix systems have
been using hashes with salts since at least when Robert Morris
implemented it in 1978? http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps
Of course in those days, the hash function took over a second to compute.
Don't confuse the name of the function (crypt()) with what it is being
used for. You can also build hash functions out of block ciphers like DES
Not necessarily. Hash functions generally haven't been as heavy as the
many rounds of block ciphers used for encryption, but you can do more
rounds and bigger keys in order to beef them up.
Dictionary attacks are possible because CPUs get faster and faster,
and utilizing clouds of computers, or having gobs of storage space for
precomputing steps are possible because computer technology always grows.
No, traditional unix crypt hash function always stored hashes. The
fallback hash store on any modern unix system is still the DES based
hash function in crypt(). BSDi was the first to publicly modify this
(private modifications were in place on some installations) with more
rounds and a bigger salt. Then others took over to do MD5 hashes
(taken up by Linux fairly quickly), and others did a hash scheme built
on the Blowfish block ciper (bcrypt, which is what you were looking at).
Most modern unix systems today support all three of these variants
(DES based hash, MD5, Blowfish). Some linux systems have a system
supporting SHA1 hashes now as well that isn't as widely used on others.
Hash systems become vulnerable to dictionary attacks because CPUs get
faster, and people can harness more of them together to run through
things faster and faster. The counter-attack is to make the hash
functions bigger, run through more loops, and provide more keying material.
Its all a trade off. Somebody doesn't want to wait 30 seconds for
login to commence because the system has to sit and hash their
password for that time. But 10 years ago, what took 30 seconds of CPU time
goes by in a fraction of a second now.
Passwords aren't stored encrypted on most systems. Unfortunatly this
is not true for basic web apps. :( Encrypted items need a key to
unlock them. In automated systems like login daemons, having a master
unlock key would be bad in the case of a system compromise.