Dear Peter Watkins, PW> I don't know how small the salt universe would need to be before PW> precomputing dictionaries would be worthwhile (vs. having a botnet only work PW> on crypted passwords already captured), but certainly the obviously weak PW> srand(time(NULL)) code only helps the black hats. And with modern OSes PW> providing reasonably good entropy sources, there's little reason not to PW> "do it right". It's not the worst mistake I've seen, by far not the most PW> dangerous. But it's sloppy of the Apache Group to have ignored it for half PW> a decade. It's quite easy. Precomputing rainbow table for MD5 crypt with known salt is somehow equivalent to MD5 crypt bruteforcing, if you don't mind about required amount of storage. So, predictable salt and narrowed salt space will have some impact if salt changes in a time comparable with time required for bruteforcing. Salt changing once in a second is really good one, because bruteforcing takes much longer. The only situation I can imagine predictability is significant, is you can predict with precision of few seconds a time of password generation in a password file you will steal next week/month. In this case you can start to build rainbow table :) --Saturday, February 16, 2008, 12:07:10 AM, you wrote to 3APA3A@xxxxxxxxxxxxxxxx: PW> On Fri, Feb 15, 2008 at 08:44:08PM +0300, 3APA3A wrote: >> PW> As a result: >> PW> - Salts created by htpasswd are very predictable. >> PW> - The universe of salts for htpasswd is far less than the MD5 algorithm >> PW> provides for -- 29 bits vs. 48, or 0.000191 percent of the range that >> PW> should be used for MD5. >> >> As far as I understand, salt predictability gives nothing to you. Salt >> protects against rainbow tables attacks in case stored passwords are >> stolen. Salt is stored with password, that is salt is known to attacker. >> All you need for salt is to be different for different passwords and for >> different systems. That is 175, 176, 177 etc are pretty good salts for >> sequentially generated passwords in case 175 is apriory unknown. >> >> Salt universe is more important, but 29 bits against 48 is not something >> scaring. >> >> May be I am missing something? PW> A naive attacker might look at the Apache APR1 MD5 spec and decide not to PW> bother precomputing tables for 2^48 salts. But with the htpasswd weakness, PW> fewer than 2^25 salts are used in an entire year; fewer than 2^21 in a given PW> month. I can't imagine anybody wasting a botnet's computing resources now on PW> building 2^48 attack tables, but the more that number drops, the more sense PW> it would make for someone controlling thousands of machines to work on an PW> attack table. Got ten thousand machines? If each one builds tables for PW> about 3400 salts, that's a full year covered. Sure is easier than having each PW> host work on 28 billion salts. PW> I don't know how small the salt universe would need to be before PW> precomputing dictionaries would be worthwhile (vs. having a botnet only work PW> on crypted passwords already captured), but certainly the obviously weak PW> srand(time(NULL)) code only helps the black hats. And with modern OSes PW> providing reasonably good entropy sources, there's little reason not to PW> "do it right". It's not the worst mistake I've seen, by far not the most PW> dangerous. But it's sloppy of the Apache Group to have ignored it for half PW> a decade. PW> One thing that bothers me about this issue is that many developers learn PW> from reading others' code, and since the Apache Group is held in such high PW> esteem by so many, the bad srand() code in htpasswd.c is likely to lead some PW> programmers astray. PW> This reminds me of the incident last year with Simson Garfinkel getting all PW> defensive about an insecure function in some of his source code. Simson didn't PW> need to fix the code -- as he pointed out, it wasn't actually used in the PW> final app -- but he didn't bother removing it, either (it's still there PW> today). Both Simson's behavior then (which I found terribly distasteful -- PW> the demand for a retraction, the smug mocking of the individual who raised the PW> issue[0]) and the Apache Group's inaction now should serve as reminders that PW> 1) everybody makes mistakes PW> and PW> 2) even those with the best reputations sometimes handle mistakes poorly PW> -Peter PW> [0] PW> http://www.securityfocus.com/archive/1/archive/1/467181/100/0/threaded -- ~/ZARAZA http://securityvulns.com/ В расчетах была ошибка. (Лем)
