[Zope-dev] Salt-weakness in zope.app.authentication passwordmanagers?

[Shane Hathaway]

Uli Fouquet wrote:
> Shane Hathaway wrote:
>> http://svn.zope.org/Zope/trunk/lib/python/AccessControl/AuthEncoding.py?rev=94737&view=markup
> 
> Is there some recent documentation about SSHA available? The netscape
> links seems to be down.

I'm not sure where to find that documentation now (Mozilla keeps 
breaking URLs, grrr), but the "slapd" package in Ubuntu (probably Debian 
also) provides the simple "slappasswd" utility.  slappasswd hashes 
passwords using SSHA by default.  In theory, the SSHA algorithm in 
AuthEncoding.py matches the SSHA algorithm in slappasswd.  If it 
doesn't, we need an implementation that perfectly matches slappasswd.

> The code looks quite similar to what is done in the current SHA1
> password manager, but if there is a standard we could follow, we might
> should do that and recommend people to switch.

SSHA is much more secure than plain SHA-1 because SSHA is not vulnerable 
to a trivial dictionary attack.  Let's say I'm an attacker and I manage 
to steal a bunch of SHA-1 encrypted passwords.  Now I want to expose 
some of those passwords so I can attack related sites.  I would build a 
database of SHA-1 hashes of dictionary words and common names with some 
variations, then I would see if any of those hashes are in the list I 
stole.  Assuming some of the users are naive, chances are pretty good 
that I'll expose a few passwords in seconds.  This is an O(m * log(n)) 
problem, where m is the number of password hashes I stole and n is the 
number of words in my dictionary.  It might even be O(m) if I first 
apply a perfect hash algorithm to the dictionary.

With SSHA, my work is much more difficult.  Instead of running the 
encrypted passwords through a trivial reverse mapping, now I have to 
encrypt every word in my dictionary using the salt provided for each 
password.  This is an O(m * n) problem, so it could take hours to find a 
common password and years to decipher a well chosen password.

Note that SSHA is in fact more secure than SHA-256 when applied to 
passwords, since a dictionary attack on a scheme with no salt is 
approximately O(m * log(n)) regardless of the hashing algorithm.

> SSHA seems cryptography-wise to be as strong or weak as the used hash
> algorithm (which here was SHA-1), so I wonder whether you would like to
> replace the standard SHA1 manager by an SSHA manager or vote for
> providing a new one.

We can't take away existing password schemes, but we can allow multiple 
schemes to coexist using a curly brace prefix, then change the default 
to the most secure available.

Shane