Hi there, Shane Hathaway wrote:
Uli Fouquet wrote:
Shane Hathaway wrote:
http://svn.zope.org/Zope/trunk/lib/python/AccessControl/AuthEncoding.py?rev=...
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/lda... 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