Adding a salt to .htpasswd?

Question

Is it possible to add a salt to passwords in .hpasswd files? I assume not since the server would need the salt for each user in order to verify the password and I can't think of how it would get them, but otherwise if the list was to be obtained it would be rather vulnerable. Is there a solution?

Many thanks for your help, Ben

Koester

What's so bad about SHA encryption (may be specified as an option with htpasswd) that you would want to salt the hash? Isn't Auth Digest an option for you where the user's password is sent being rehashed with nonces? – Adjacent

See my (updated) answer - the SHA digests generated by htpasswd are trivial to reverse. – Conciliar

Answer 1

By default htpasswd uses the standard crypt function and thus passwords are already salted - note in this example that both users have the same password yet the hashes are different:

simon@diablo:~$ htpasswd -b -c htpasswd simon abcd
Adding password for user simon
simon@diablo:~$ htpasswd -b htpasswd simon2 abcd
Adding password for user simon2
simon@diablo:~$ cat htpasswd 
simon:NWvm/LCCxQ64E
simon2:2I.LBzsRqULN6

(note: the -b flag is normally discouraged because other users can see your command line arguments and hence the password)

The first two characters of the hash are the salt; passwords are verified by calling crypt() again. Entering the wrong password produces a string that's unequal to the hashed password:

>>> from crypt import crypt
>>> crypt("wrongpass", "NWvm/LCCxQ64E")
'NWbxQgX1unvso'

whereas the correct password produces the expected hash:

>>> crypt("abcd", "NWvm/LCCxQ64E")
'NWvm/LCCxQ64E'

htpasswd -m uses a different algorithm that's MD5-based and uses a longer salt:

simon@diablo:~$ htpasswd -m -b -c htpasswd simon abcd
Adding password for user simon
simon@diablo:~$ cat htpasswd
simon:$apr1$mfvnBVmG$iIHIHOaH9vcImG5G.8eVa/

Here, the salt is the 8 characters between the second and third $.

htpasswd -s stores a SHA-1 digest with no salt; this appears to be for compatibility with Netscape/LDIF:

simon@diablo:~$ htpasswd -s -b -c htpasswd simon abcd
Adding password for user simon
simon@diablo:~$ htpasswd -s -b htpasswd simon2 abcd
Adding password for user simon2
simon@diablo:~$ cat htpasswd 
simon:{SHA}gf6L/odXbD7LIkJvjleEc4KRes8=
simon2:{SHA}gf6L/odXbD7LIkJvjleEc4KRes8=

These can easily be reversed - convert into a hex digest:

>>> "".join("%02x" % ord(c)
...      for c in "gf6L/odXbD7LIkJvjleEc4KRes8=".decode("base64"))
'81fe8bfe87576c3ecb22426f8e57847382917acf'

then use an online hash database.

Conciliar

Thanks! I'm using SHA-1 to encrypt the passwords. What you've said seems to suggest then that MD5 is more secure for this than SHA-1? But it also has its weaknesses. I'm encoding and writing the data to the file with PHP, so I don't know how easy it is to add salts to MD5 hashes. – Koester

Another point in its favour is that the MD5-based algorithm repeats the hashing 1000 times ("key strengthening"), which makes brute force cracking more time consuming. This question has code claiming to implement the algorithm: #1039291 – Conciliar

That is absolutely brilliant! I learned a lot there, and the PHP code works perfectly. Thanks! – Koester

Obligatory comments: 1) Hash functions (SHA1, MD5, crypt) do not encrypt. Their job is to throw away information creatively. 2) SHA1 cannot (to date) be reversed. That said, people have forwarded (hashed using SHA1) an incredibly large number of possible passwords, and can search the results very quickly (rainbow tables). Since there is no salt, it is very likely that any short or insecure password is in a rainbow table and that it is possible to determine one of those passwords from the hash. – Continual

@Conciliar online hash database link is dead, this is a good replacement: hashkiller.co.uk/sha1-decrypter.aspx – Waterless

Answer 2

The htpasswd utility already does use salts in most cases:

The crypt() and MD5 formats permute the representation by prepending a random salt string, to make dictionary attacks against the passwords more difficult.

And that's (sort of) the purpose of salts in password files. While salts have to be included in the server's .htpasswd file for the server to be able to check passwords, it is the numerous different possibilities of what a salt could be that defends against such attack techniques as rainbow tables.

However, if your users pick weak or common passwords, password cracking is a problem anyways, since the attacker (presumed to have access to the password file) will try those first, very quickly in fact (not limited by the speed of the server and Internet connection), by guessing in the normal way. The best advice I can give is that users should always pick strong passwords.

Cannular