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
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )