bugtraq - Re: Apache web server 2.2: htpasswd predictable salt weakness

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080215160710.A30917@gwyn.tux.org>
Date: Fri, 15 Feb 2008 16:07:10 -0500
From: Peter Watkins <peterw@....net>
To: 3APA3A <3APA3A@...URITY.NNOV.RU>
Cc: bugtraq@...urityfocus.com
Subject: Re: Apache web server 2.2: htpasswd predictable salt weakness

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?

A naive attacker might look at the Apache APR1 MD5 spec and decide not to
bother precomputing tables for 2^48 salts. But with the htpasswd weakness,
fewer than 2^25 salts are used in an entire year; fewer than 2^21 in a given
month. I can't imagine anybody wasting a botnet's computing resources now on 
building 2^48 attack tables, but the more that number drops, the more sense
it would make for someone controlling thousands of machines to work on an
attack table. Got ten thousand machines? If each one builds tables for
about 3400 salts, that's a full year covered. Sure is easier than having each 
host work on 28 billion salts. 

I don't know how small the salt universe would need to be before 
precomputing dictionaries would be worthwhile (vs. having a botnet only work 
on crypted passwords already captured), but certainly the obviously weak 
srand(time(NULL)) code only helps the black hats. And with modern OSes 
providing reasonably good entropy sources, there's little reason not to 
"do it right". It's not the worst mistake I've seen, by far not the most 
dangerous. But it's sloppy of the Apache Group to have ignored it for half 
a decade.

One thing that bothers me about this issue is that many developers learn 
from reading others' code, and since the Apache Group is held in such high 
esteem by so many, the bad srand() code in htpasswd.c is likely to lead some 
programmers astray. 

This reminds me of the incident last year with Simson Garfinkel getting all 
defensive about an insecure function in some of his source code. Simson didn't
need to fix the code -- as he pointed out, it wasn't actually used in the
final app -- but he didn't bother removing it, either (it's still there
today). Both Simson's behavior then (which I found terribly distasteful --
the demand for a retraction, the smug mocking of the individual who raised the 
issue[0]) and the Apache Group's inaction now should serve as reminders that 
 1) everybody makes mistakes 
and 
 2) even those with the best reputations sometimes handle mistakes poorly

-Peter

[0] http://www.securityfocus.com/archive/1/archive/1/467181/100/0/threaded