| |||||||||||||
Responsible disclosure in open source: The crypt() vulnerabilityResponsible disclosure in open source: The crypt() vulnerabilityPosted Jun 7, 2012 20:56 UTC (Thu) by intgr (subscriber, #39733)Parent article: Responsible disclosure in open source: The crypt() vulnerability
> Given the age and limited computational "strength" of crypt-DES, however, this is no longer true; brute-force computation of crypt() passwords is easily done. Programmers are encouraged to use more modern hashing and encryption algorithms, such as SHA1 and Blowfish
Seriously? This is bad advice! While crypt-DES is indeed old and should be deprecated, it is a proper salted password hashing function.
SHA-1 is NOT a replacement for crypt-DES at all -- it's a hash designed to be fast and it defines no salting mechanism. Thus, all passwords in a compromised database can be checked in parallel and cracking can be very fast using precomputed (publicly available) rainbow tables; yet it's faster than crypt-DES even in the brute force case. Worse, it's vulnerable to collision attacks, which makes it unsuitable for some applications, so it shouldn't be recommended at all for anything new.
PBKDF2 is *the* standard for password hashing. It defines a variable iteration count and salting, with some other nice properties. Or if you're feeling adventurous, scrypt is interesting.
And Blowfish... It's even further from a crypt-DES replacement. It has no known vulnerabilities, but even its designers recommend using AES instead.
(Log in to post comments)
Responsible disclosure in open source: The crypt() vulnerability Posted Jun 8, 2012 8:37 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
I imagine the author means algorithms based on... rather than intending that you should use an unpessimised and unsalted hash.
Probably this is because of the same error that Poul-Henning Kamp has made in the last few days here: http://phk.freebsd.dk/sagas/md5crypt_eol.html, giving advice with the assumption that the people receiving it are smart, well-motivated people who know the topic.
A handful of people will muse on what PHK wrote and then write robust, heavily pessimised and salted hashing algorithms, custom for their application, properly review and test them and put them into production. But far more people will take this as an opportunity to either:
(a) continue using crude variants of MD5(password) using e.g. a small per-application salt under the belief that a little obscurity buys them more than the security of an established algorithm such as PHK-MD5 or even the DES crypt.
(b) argue that these crypto programmers don't understand real world problems such as the desire to re-use passwords across applications and thus ought to be ignored by "real" programmers who need to get that PHP web forum working to keep the client happy.
Overall I think PHK's article was mistimed, not least because the numbers he gives to "scare you straight" seem to be exaggerated or based on some additional assumptions he didn't provide.
Responsible disclosure in open source: The crypt() vulnerability Posted Jun 9, 2012 7:50 UTC (Sat) by bsdphk (guest, #85042) [Link]
With respect to "exaggerated numbers": Yes, for reasons of confidentiality I cannot reveal all I know, but do read the provided reference about GPUs, and then ask yourself "I wonder what speed an FPGA runs then...?"
With respect to mistimed, no, it was very carefully timed and I hit it very close to perfect.
To get a message like this out to all the people who need to hear it is very difficult.
I don't have a Vogon Tanoy where I can press a button and go "People of Earth, Your attention please..."
Piggybacking on the LinkedIn attention-wave, meant that news-providers had "password" in their short term memory and my message got very efficiently relayed.
With respect to the guidance I give: I you think that is a bad idea, I suggest you write an easy to use, liberally licensed password scrambler which actually solves the problem for a decade or two.
The present wave can be surfed for about a week more...
Thanks for using my code
Poul-Henning
Responsible disclosure in open source: The crypt() vulnerability Posted Jun 11, 2012 10:31 UTC (Mon) by intgr (subscriber, #39733) [Link]
> With respect to the guidance I give: I you think that is a bad idea, I suggest you write an easy to use, liberally licensed password scrambler which actually solves the problem for a decade or two.
There are tons of free implementations of PBKDF2 and a few of scrypt. Those are the only two that are worth using. Surely you were aware of both? I'm surprised you're even suggesting that we need any new libraries/standards.
Responsible disclosure in open source: The crypt() vulnerability Posted Jun 8, 2012 8:58 UTC (Fri) by epa (subscriber, #39769) [Link]
Is there any reason for an application to do its own password hashing at all? Surely there is a small, permissively-licenced library which does it?
I'd go further and say that for web sites there is no reason to handle the authentication in the application code at all - you should use what Apache or another web server provides, with a small utility page for adding users - but most web developers seem to disagree with me on that. Perhaps because it's felt that users are not able to cope with the plain username/password dialogue box that browsers give for http authentication.
Responsible disclosure in open source: The crypt() vulnerability Posted Jun 8, 2012 13:55 UTC (Fri) by dps (subscriber, #5725) [Link]
Most web browsers and servers don't support anything that looks safe. You either need the user name and password (plain), which is a particular bad idea when not using SSL/TLS, or have password equivalent data on the server (cram-MD5). There are also attacks against some browsers on windows.
If you use a form instead then you can implement more secure protocols which do not have those problems, for example proving you can decrypt RSA given the E_K(secret key) where K=KDF(salt,password). This is not difficult to implement and a lot better anything a browser or server is likely to support.
Sending passwords and using unsalted hashes is plain stupid and should be severely punished. Did anyone tell these people about rainbow tables and them not working if you use salt?
Responsible disclosure in open source: The crypt() vulnerability Posted Jun 8, 2012 15:14 UTC (Fri) by epa (subscriber, #39769) [Link]
I kind of trusted that the Apache developers would know what they were doing and the 'htpasswd' files supported by Apache would use a good-quality salted hash.
As for sending passwords over the wire, I suppose that in principle you could use some awesome piece of Javascript to implement a zero-knowledge proof, but surely 99.999% of HTML password forms out there on the web just send the password back to the server anyway.
HTTP digest authentication uses salted MD5, which is not ideal but not awful.
Rainbow tables Posted Jun 8, 2012 15:37 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
Other commentators have observed that Rainbow tables have been "eclipsed" by the rapid progress of GPU-based parallel brute force attacks for most scenarios where they would once have been viable.
Rainbow tables are a time-space tradeoff, RAM and disk space continues to be only marginally cheaper than it was a few years ago, while GPU based "brute force" attacks can be thousands of times faster than CPU based attacks from a few years ago. So rather than buy 50TB of storage for rainbow tables targeting a single algorithm, it is more tempting for attackers to buy, rent, or indeed steal (through a botnet) a dozen mid-range gaming GPUs and have the flexibility to attack dozens of different algorithms for which GPU-based brute forcers are available.
Salt does still mean the attackers have to attack every individual password, rather than gathering a list of the most common hashes and attacking those for disproportionate gain, and it also means if some day rainbow tables or a newer time-space tradeoff would otherwise have been viable that's sidestepped. But it's far less important today than it was a few years ago.
Rainbow tables Posted Jun 8, 2012 15:57 UTC (Fri) by intgr (subscriber, #39733) [Link]
> Rainbow tables have been "eclipsed" by the rapid progress of GPU-based parallel brute force attacks
The time-space tradeoff goes both ways. By using GPU instead of CPU for the time-intensive parts, you can increase the storage efficiency of rainbow tables (generate longer hash chains); the speedup would still be the same proportion. However, I don't know whether there are any actual implementations of this.
Rainbow tables Posted Jun 8, 2012 20:18 UTC (Fri) by jackb (subscriber, #41909) [Link] GPU-based parallel brute force attacksYou could probably blame Bitcoin in part for making these kinds of rigs popular.
|
|||||||||||||