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

[Uli Fouquet]

Hi there,

Shane Hathaway wrote:
> 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.

Just found an old copy of the page in the wayback-machine:

http://web.archive.org/web/*/http://developer.netscape.com/docs/technote/ldap/pass_sha.html

Someone should create a wikepedia-article for that.

> > 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.

Fully agreed. That was my problem with the salt not used in the
currently used implementation but you correctly explained it in terms of
complexity :-) What I meant is: if the current SHA manager would
implement seeding with salt properly, _then_ the difference would be:

  '{SSHA}' + base64_encode(sha(pw + four_bytes_salt))

compared to:

    bin2hex(sha(four_bytes_salt + pw))

which looks really similar to me in terms of security.

But this seems not be worth discussing, as SSHA is a standard.

> > 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.

Ok. I'll put something into the zope.app.authentication branches for
review.

Two remaining questions: I would like to use `os.urandom` instead of
`random.randint` to create the salt, because this is recommended in
cryptographic contexts. There was, however, a problem with this module
in former times: sometimes it stopped until enough entropy was
available, which could make threads and processes hang. Is this still an
issue?

Last question: How should we handle lack of SHA-2 hashes in the Python
standard lib of 2.4? Self-implementing sounds too error-prone to me
while existing Python ports of the reference implementation in PyCryto
etc. are implemented in C which would make `zope.app.authentication` a
binary package. Something I would like to avoid. Or is support for
Python 2.4 running out anyway?

Best regards,

-- 
Uli

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20090121/e313b70b/attachment.bin