what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New


Posted Feb 14, 2008
Authored by Peter Watkins

htpasswd as included with Apache version 2.2 suffers from a predictable salt weakness.

tags | advisory
SHA-256 | 6c9a7044d2c0e0377bd8e98119d57a652f6b5d750e9a81bfa995cf432492f75a


Change Mirror Download

This is not the first time this issue has been discussed. Andreas
Steinmetz posted about the problem for an Apache httpd release in 2003.
Philipp Krammer reported that he notifed the vendor over five years
ago, in January 2003. http://www.securityfocus.com/archive/1/339163

What's new is
1) The vendor has released another major version of the
affected software, Apache web server 2.2, with the same flaw.
2) While no official patch is available (due to the vendor's inaction),
an unofficial patch is now available.



Apache web server supports three different algorithms for
"encrypted" passwords for HTTP Basic authentication:
- Unix-style crypt() passwords: uses a 12 bit salt (4096
possible values) and only the first 8 characters of the
cleartext password are used
- SHA hashes: no salt; any given password can have only one
{SHA} representation
- MD5 passwords: based on the BSD MD5 crypt routine, this
provides for 48 bits of salt, for a theoretical 281 trillion
(281,474,976,710,656) possible representations of any password

Apache web server includes a command-line utility called 'htpasswd'
for managing the files used for HTTP Basic authentication. It can be
used (depending on the host OS) to create encrypted passwords with
any of the supported algorithms.


The htpasswd utility uses predictable salts for the salted algoritms
(Unix-style "CRYPT" and MD5). htpasswd uses the standard C rand()
function to generate "random" salts. In order to use rand(), htpasswd
seeds the random number generator with the srand() function. And that's
where the Apache developers made a critical mistake -- htpasswd
merely uses the time of day (seconds since the Epoch, time(NULL)) to
seed the random number generator.

As a result:
- Salts created by htpasswd are very predictable.
- The universe of salts for htpasswd is far less than the MD5 algorithm
provides for -- 29 bits vs. 48, or 0.000191 percent of the range that
should be used for MD5.
- Any passwords encrypted by htpasswd within the same second of
system clock time will have the same salt, e.g.
$ htpasswd -nbm user1 pass1; htpasswd -nbm user2 pass2; \
htpasswd -nbm user3 pass2
All three users have the same salt, "7jv93/..", and user2 and user3
have the same encrypted password representation.

Clearly, this is not good.

Furthermore, as you can see in that example, and as Andreas Krennmair
reported to the Apache Group in 2004, the htpasswd utility does not
use the full 48 bits of salt for the MD5 algorithm -- the last two
characters are always "..". So htpasswd tries creates 36-bit salt strings.
Given that the srand() problem both reduces the universe to something
like 29 bits[0] *and* makes the salt highly predictable, this 36-vs-48
distinction is a moot point -- as long as the srand() seeding is bad.

The problem appears completely contained within the htpasswd utility;
Apache web server handles all properly encrypted passwords as it should.


1) If you are concerned about the possibilty of the vastly reduced
salt space making your password tables vulnerable to pre-computed
dictionary attacks, use an updated htpasswd utility to re-encrypt
all MD5 or CRYPT passwords.

2) Use an alternate tool for generating your password hashes.
Implementations of the CRYPT and "apr1" MD5 algorithms are available
for various programming languages and platforms -- you don't need to
use the inferior tool from the Apache project.


htpasswd should at least use a more random seed for the srand() calls
so that rand() can produce less predictable salts. It should also, as
Andreas Krennmair noted, make full use of the 48-bit-wide salt capability
of its "apr1" MD5 algorithm.


Patches are available in Apache's "issues" database that correct both the
weak seeding of srand() and, thanks to Andreas, the 36/48 bit salt size
for MD5:

Here's sample output from a patched htpasswd utility:

$ htpasswd -nbm user1 pass1; htpasswd -nbm user2 pass2; \
htpasswd -nbm user3 pass2

The patch I submitted to the Apache group
1) by default makes use of the /dev/urandom device that is available
on most modern open systems OSes
2) allows the user to specify another seed source (such as /dev/random)
via an environment variable
3) prints a warning if it has to fall back to using time()

Users of Microsoft Windows or other target platforms that lack /dev/urandom
might want to improve on this approach with appropriate APIS such as
RtlGenRandom on Windows. Also, the patch provides no updates to the htpasswd
man page documentation.


Vulnerability reported via vendor's bug tracking database, and source
code patch made available, on 25 January 2008.

Vendor security contact notified via email on 4 February 2008.

Vendor response:

None, as of 13 February 2008.

[0] For any given PRNG. In theory, different machines could have
different PRNG algorithms, providing some additional security. But in
my tests, most common Linux flavors (Linux being perhaps the most
popular platfor for Apache web server) use the same PRNG and physically
different systems produce the same output from htpasswd for any given
clock time / time() value. 29 bits are enough to represent every time()
value since before the first release of Apache web server. As noted in
Bugzilla, the narrower the timeframe an attacker is interesetd in, the
smaller the list of possible salts.
Login or Register to add favorites

File Archive:

February 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Feb 1st
    16 Files
  • 2
    Feb 2nd
    19 Files
  • 3
    Feb 3rd
    0 Files
  • 4
    Feb 4th
    0 Files
  • 5
    Feb 5th
    24 Files
  • 6
    Feb 6th
    2 Files
  • 7
    Feb 7th
    10 Files
  • 8
    Feb 8th
    25 Files
  • 9
    Feb 9th
    37 Files
  • 10
    Feb 10th
    0 Files
  • 11
    Feb 11th
    0 Files
  • 12
    Feb 12th
    17 Files
  • 13
    Feb 13th
    20 Files
  • 14
    Feb 14th
    25 Files
  • 15
    Feb 15th
    15 Files
  • 16
    Feb 16th
    6 Files
  • 17
    Feb 17th
    0 Files
  • 18
    Feb 18th
    0 Files
  • 19
    Feb 19th
    35 Files
  • 20
    Feb 20th
    25 Files
  • 21
    Feb 21st
    18 Files
  • 22
    Feb 22nd
    15 Files
  • 23
    Feb 23rd
    0 Files
  • 24
    Feb 24th
    10 Files
  • 25
    Feb 25th
    0 Files
  • 26
    Feb 26th
    0 Files
  • 27
    Feb 27th
    0 Files
  • 28
    Feb 28th
    0 Files
  • 29
    Feb 29th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By