User: Password:
|
|
Subscribe / Log in / New account

Responsible disclosure in open source: The crypt() vulnerability

Responsible disclosure in open source: The crypt() vulnerability

Posted Jun 8, 2012 13:55 UTC (Fri) by dps (subscriber, #5725)
In reply to: Responsible disclosure in open source: The crypt() vulnerability by epa
Parent article: Responsible disclosure in open source: The crypt() vulnerability

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?


(Log in to post comments)

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 (guest, #41909) [Link]

GPU-based parallel brute force attacks
You could probably blame Bitcoin in part for making these kinds of rigs popular.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds