Salt-weakness in zope.app.authentication passwordmanagers?
Hi there, while working on a password manager tool (commandline) for Grok I stumbled over the usage of salts in the password managers of `zope.app.authentication`. In short, they seem to generate (and store) a salt number but do not make any use of it when it comes to creating the hashes (SHA1, MD5, whatever). As a result, same passwords lead always to same hashes, only the leading salt number is different. This could be exploited by dictionary attacks. The zope.app.authentication implementation for SHA1-encoding looks roughly like this (other hash-encodings have the same problem, if this is a valid problem):: def encodePassword(password, salt=None): if salt is None: salt = "%08x" % randint(0, 0xffffffff) return salt + sha.new(password).hexdigest() It looks to me that this way `salt` is only an arbitrary string that gets stored in front of the real hash value. The hash value itself will not change with the salt. When I run the following code (`checkPassword` like in `zope.app.authentication.password`):: def checkPassword(storedPassword, password): salt = storedPassword[:-40] return storedPassword == encodePassword(password, salt) for i in range(0,3): enc = encodePassword('asd') print 'Encode "asd"', enc print 'Check: ', checkPassword(enc, 'asd') I get:: Encode "asd" 81bde2dbf10e2821bbbea527ea02200352313bc059445190 Check: True Encode "asd" c96cfabdf10e2821bbbea527ea02200352313bc059445190 Check: True Encode "asd" bdba5b69f10e2821bbbea527ea02200352313bc059445190 Check: True As you can see, only the first eight letters change. And they are cleartext part of the encoded password. Not a problem for an dictionary-attacker: if one of the hashes in his/her dictionary are equal to ``f10e2821bbbea527ea02200352313bc059445190``, then the password is cracked. Salts do not improve the security level here, I think. What I assume to be correct, would be to build the hash from the salt plus password (instead of only the password):: def encodePassword(password, salt=None): if salt is None: salt = "%08x" % randint(0, 0xffffffff) return salt + sha.new(salt + password).hexdigest() Using this modified function, I get:: Encode "asd" 11ac348fe526cc38813fca0e5bd0a59ec3a16686bfa42502 Check: True Encode "asd" 08de8fa19212d743867f8867adee55a9efbe566a8ec56731 Check: True Encode "asd" d454b892224b0cf5b41767acfa80a3732b82c52fc2ee5e9f Check: True Now it is harder for an attacker. His dictionary has not only to provide the pure hashes for every entry in the dictionary, but also 16**8 variants for _each_ of the entries. That's it, I think, what salt is used for. As I am not a computer scientist nor a mathematician, I am not sure, whether these are valid concerns. But I would like to know, what others think about this. Maybe you can correct me here. Best regards, -- Uli
Yeah, that's definetely a mistake! The hash needs to be generated using both salt and password. Also, I saw a technique when you generate a hash using double hashing, like this: sha(sha(password) + salt).hexdigest(). It looks even more secure :) BTW, to fix it, we need to remember about migration of already stored hashes. I guess zope.app.generations will do the job. 2009/1/17 Uli Fouquet <uli@gnufix.de>:
Hi there,
while working on a password manager tool (commandline) for Grok I stumbled over the usage of salts in the password managers of `zope.app.authentication`.
In short, they seem to generate (and store) a salt number but do not make any use of it when it comes to creating the hashes (SHA1, MD5, whatever). As a result, same passwords lead always to same hashes, only the leading salt number is different. This could be exploited by dictionary attacks.
The zope.app.authentication implementation for SHA1-encoding looks roughly like this (other hash-encodings have the same problem, if this is a valid problem)::
def encodePassword(password, salt=None): if salt is None: salt = "%08x" % randint(0, 0xffffffff) return salt + sha.new(password).hexdigest()
It looks to me that this way `salt` is only an arbitrary string that gets stored in front of the real hash value. The hash value itself will not change with the salt.
When I run the following code (`checkPassword` like in `zope.app.authentication.password`)::
def checkPassword(storedPassword, password): salt = storedPassword[:-40] return storedPassword == encodePassword(password, salt)
for i in range(0,3): enc = encodePassword('asd') print 'Encode "asd"', enc print 'Check: ', checkPassword(enc, 'asd')
I get::
Encode "asd" 81bde2dbf10e2821bbbea527ea02200352313bc059445190 Check: True Encode "asd" c96cfabdf10e2821bbbea527ea02200352313bc059445190 Check: True Encode "asd" bdba5b69f10e2821bbbea527ea02200352313bc059445190 Check: True
As you can see, only the first eight letters change. And they are cleartext part of the encoded password. Not a problem for an dictionary-attacker: if one of the hashes in his/her dictionary are equal to ``f10e2821bbbea527ea02200352313bc059445190``, then the password is cracked. Salts do not improve the security level here, I think.
What I assume to be correct, would be to build the hash from the salt plus password (instead of only the password)::
def encodePassword(password, salt=None): if salt is None: salt = "%08x" % randint(0, 0xffffffff) return salt + sha.new(salt + password).hexdigest()
Using this modified function, I get::
Encode "asd" 11ac348fe526cc38813fca0e5bd0a59ec3a16686bfa42502 Check: True Encode "asd" 08de8fa19212d743867f8867adee55a9efbe566a8ec56731 Check: True Encode "asd" d454b892224b0cf5b41767acfa80a3732b82c52fc2ee5e9f Check: True
Now it is harder for an attacker. His dictionary has not only to provide the pure hashes for every entry in the dictionary, but also 16**8 variants for _each_ of the entries. That's it, I think, what salt is used for.
As I am not a computer scientist nor a mathematician, I am not sure, whether these are valid concerns. But I would like to know, what others think about this. Maybe you can correct me here.
Best regards,
-- Uli
_______________________________________________ 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 )
-- WBR, Dan Korostelev
Previously Dan Korostelev wrote:
Yeah, that's definetely a mistake! The hash needs to be generated using both salt and password.
Also, I saw a technique when you generate a hash using double hashing, like this: sha(sha(password) + salt).hexdigest(). It looks even more secure :)
Why would it make things more secure? Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Hi Dan, thanks for your quick response. Dan Korostelev wrote:
Yeah, that's definetely a mistake! The hash needs to be generated using both salt and password.
Also, I saw a technique when you generate a hash using double hashing, like this: sha(sha(password) + salt).hexdigest(). It looks even more secure :)
Hm, not sure. Building the hash of a hash doesn't give a more equal distribution, does it? Therefore it doesn't look 'more secure' to me. A dictionary-attacker could simply generate the list of hashes by using hash(hash(dict_entry)) instead of hash(dict_entry). That wouldn't cost much. A brute force-attacker would also have no extra-work, because a hashed 'password' is as difficult to crack as hashed 'hash(password)' in brute-force-attacks. I might be wrong here. Using a better hash-algorithm instead, as Shane proposed, could really improve security IMHO. At least it should be supported by the standard password managers in zope.app.authentication.
BTW, to fix it, we need to remember about migration of already stored hashes. I guess zope.app.generations will do the job.
Yep, that's important and could cause trouble. Already stored passwords could become invalid if we don't care for them and this could also be a problem with generations, as here not only pure code would be concerned but also data stored in the configuration. Best regards, -- Uli
Previously Uli Fouquet wrote:
Hi Dan,
thanks for your quick response.
Dan Korostelev wrote:
Yeah, that's definetely a mistake! The hash needs to be generated using both salt and password.
Also, I saw a technique when you generate a hash using double hashing, like this: sha(sha(password) + salt).hexdigest(). It looks even more secure :)
Hm, not sure. Building the hash of a hash doesn't give a more equal distribution, does it? Therefore it doesn't look 'more secure' to me.
It would not surprise me if it would in fact not be considerably weaker. The cleartext space for the second hash is a lot smaller and very predictable (you know the exact string length and that is only consists of digits and lowercase letters), making an attack simpler. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Hi there, to answer myself ;-) Uli Fouquet wrote:
Dan Korostelev wrote:
Yeah, that's definetely a mistake! The hash needs to be generated using both salt and password.
[snip]
BTW, to fix it, we need to remember about migration of already stored hashes. I guess zope.app.generations will do the job.
Yep, that's important and could cause trouble. Already stored passwords could become invalid if we don't care for them and this could also be a problem with generations, as here not only pure code would be concerned but also data stored in the configuration.
This problem is more serious than I thought in the beginning. We could update existing encrypted passwords, but we cannot say, where and how they are stored. Just think of SHA1 passwords mass-stored in some LDAP, RDBMS or a password file. The risk is, that no users from such databases could authenticate themselves anymore after an upgrade. I'd be glad to provide a fix for this, but I am undecided how we could support administrators best to upgrade their password bases. Currently, three (not mutual exclusive) approaches come to my mind: 1) the fixed password managers could be registered under different names. Support of the old ones could slowly run out and users could be warned, if they still use the old password managers. The old password managers then could be used as a fallback. This would weaken security (as two different hashes would allow one to authenticate with the same password), but not very much (you get a chance of 2:8**20 instead of 1:8**20 in worst case). Paranoid folks should be able to disable the fallback and expect complaints from their users. Default policy might be to disable fallback. 2) A commandline tool should be available, that can at least get old (encrypted) passwords and tell how they look hashed proper. Administrators had to take care for storing them in site.zcml, their LDAP or wherever they store passwords. 3) A commandline tool could also update existing ZCML files. This might fix the problems for most users. There might be smarter approaches. Any hints are very welcome. Best regards, -- Uli
Hi there, Uli Fouquet wrote:
I'd be glad to provide a fix for this, but I am undecided how we could support administrators best to upgrade their password bases.
I'm speaking here mostly from a position of ignorance of these affairs, but is it possible to upgrade the current passwords to a more secure version without knowing those passwords?
Currently, three (not mutual exclusive) approaches come to my mind:
1) the fixed password managers could be registered under different names. Support of the old ones could slowly run out and users could be warned, if they still use the old password managers.
If we were to fix the old password managers, would the old passwords break? If not, that would at least provide better security for newly stored passwords right away without having to change applications.
The old password managers then could be used as a fallback. This would weaken security (as two different hashes would allow one to authenticate with the same password), but not very much (you get a chance of 2:8**20 instead of 1:8**20 in worst case).
If it's not possible to update the existing password managers to the new behavior a new name + fallback sounds like the best way to go.
Paranoid folks should be able to disable the fallback and expect complaints from their users. Default policy might be to disable fallback.
Possibly simply register 2 new names then, one without fallback and one with.
2) A commandline tool should be available, that can at least get old (encrypted) passwords and tell how they look hashed proper. Administrators had to take care for storing them in site.zcml, their LDAP or wherever they store passwords.
Why a commandline tool? Wouldn't it be better to just have an API to help upgrade passwords?
3) A commandline tool could also update existing ZCML files. This might fix the problems for most users.
I don't think that would fix it for most users. In fact I think those few hashes that are stored in ZCML are not a great security risk; if malicious people can read those the risk to the application is far greater already. The risk is bigger for larger password databases that fall into the wrong hands, as far as I understand it.
There might be smarter approaches. Any hints are very welcome.
The most important part I think is to document well what people should be doing. I.e. use the new password managers (or tell them to upgrade and their old ones will be fine), and how they should go about upgrading existing passwords. I think we should ask people to write their own upgrade code as we do not know where these passwords are stored. I'm storing them in a relational database in some cases, for instance. We could provide upgrade code for some common scenarios, but I'd be fine if we had a good document with instructions instead. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hi there,
Uli Fouquet wrote:
I'd be glad to provide a fix for this, but I am undecided how we could support administrators best to upgrade their password bases.
I'm speaking here mostly from a position of ignorance of these affairs, but is it possible to upgrade the current passwords to a more secure version without knowing those passwords?
If that is possible, then we have a worse problem on hand. :) Passwords aren't meant to be stored in a reversible / recoverable manner.
Currently, three (not mutual exclusive) approaches come to my mind:
1) the fixed password managers could be registered under different names. Support of the old ones could slowly run out and users could be warned, if they still use the old password managers.
If we were to fix the old password managers, would the old passwords break? If not, that would at least provide better security for newly stored passwords right away without having to change applications.
In a PAS environment, the way to do this is to add a new authentication plugin, which imposes the new scheme, and be williing to fall back to the old one. You also need to replace the plugin which is responsible for the "update credentials" bit, so that when the user updates her password, it gets stored in the new way. Finally, the admin might want to ask all users to change passwords in order to clear out the weaker set. There isn't going to be any easy way to automate this kind of upgrade.
The old password managers then could be used as a fallback. This would weaken security (as two different hashes would allow one to authenticate with the same password), but not very much (you get a chance of 2:8**20 instead of 1:8**20 in worst case).
If it's not possible to update the existing password managers to the new behavior a new name + fallback sounds like the best way to go.
Paranoid folks should be able to disable the fallback and expect complaints from their users. Default policy might be to disable fallback.
Possibly simply register 2 new names then, one without fallback and one with.
2) A commandline tool should be available, that can at least get old (encrypted) passwords and tell how they look hashed proper. Administrators had to take care for storing them in site.zcml, their LDAP or wherever they store passwords.
Why a commandline tool? Wouldn't it be better to just have an API to help upgrade passwords?
3) A commandline tool could also update existing ZCML files. This might fix the problems for most users.
I don't think that would fix it for most users. In fact I think those few hashes that are stored in ZCML are not a great security risk; if malicious people can read those the risk to the application is far greater already. The risk is bigger for larger password databases that fall into the wrong hands, as far as I understand it.
An attacker who can get to your password database is already well past our "ordinary" security measures: given filesystem access, he can steal, or even modify, any of the data those passwords are aimed at protecting. Because many users reuse passwords across systems, there is a second-order effect: being able to crack the Phred's password on one system might give access to Phred's accounts on *other* systems. Making the hash stronger really only defends against this second-order attack.
There might be smarter approaches. Any hints are very welcome.
The most important part I think is to document well what people should be doing. I.e. use the new password managers (or tell them to upgrade and their old ones will be fine), and how they should go about upgrading existing passwords.
I think we should ask people to write their own upgrade code as we do not know where these passwords are stored. I'm storing them in a relational database in some cases, for instance. We could provide upgrade code for some common scenarios, but I'd be fine if we had a good document with instructions instead.
Agreed: no general solution seems possible. I wouldn't suggest anything more than a code snippet: anything shipped as actual software is likely to be an "attractive nuisance." Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJdLje+gerLs4ltQ4RAhEvAJ4gmbqOegwWs/nnshG2ZdXI07AzwQCfQaD7 cSN7/TxRxXTjuYwiuUROaxE= =CpNh -----END PGP SIGNATURE-----
Hi there, Martijn Faassen wrote:
Uli Fouquet wrote:
I'd be glad to provide a fix for this, but I am undecided how we could support administrators best to upgrade their password bases.
I'm speaking here mostly from a position of ignorance of these affairs, but is it possible to upgrade the current passwords to a more secure version without knowing those passwords?
Sorry, my mistake. No, this is not possible. One needs the clear-text password to update. At least I cannot see a methods to update encrypted passwords.
Currently, three (not mutual exclusive) approaches come to my mind:
1) the fixed password managers could be registered under different names. Support of the old ones could slowly run out and users could be warned, if they still use the old password managers.
If we were to fix the old password managers, would the old passwords break? If not, that would at least provide better security for newly stored passwords right away without having to change applications.
Unfortunately they would break: sha(pw) != sha(salt+pw). If they do not break, you just successfully performed a collision-attack ;-) The fixed password managers cannot see from the stored password, whether the string was generated using salt or not. Wait, if we start to store proper encoded passwords with a marker, say '{SHA1}', '{MD5}' or similar in front of it (like done in other password databases like htaccess files), this could help. Roughly:: def encodePassword(self, password, salt=None, use_old=False): if use_old: return salt + sha(password) return '{SHA1}' + salt + sha(salt + password) def checkPassword(self, storedPassword, password): ... use_old = not storedPassword.startswith('{SHA1}') return storedPassword == self.encodePassword(password, salt, use_old = use_old) or something similar. An ecrypted pw would then look like: '{SHA1}6dee7ba6f10e2821bbbea527ea02200352313bc059445190' This way, old passwords could still be used, but setting a new one would result in a proper encoded password, just as you said. [snip]
Paranoid folks should be able to disable the fallback and expect complaints from their users. Default policy might be to disable fallback.
Possibly simply register 2 new names then, one without fallback and one with.
The above snippet would provide a 'fallback-manager' intergrated. It might however be nice for paranoid people to have also a password manager available that simply does not accept old encoded passwords. [snip]
Why a commandline tool? Wouldn't it be better to just have an API to help upgrade passwords?
Agreed, but as we cannot simply update without the clear-text password, this seems not to be a topic anymore anyway.
3) A commandline tool could also update existing ZCML files. This might fix the problems for most users.
I don't think that would fix it for most users. In fact I think those few hashes that are stored in ZCML are not a great security risk; if malicious people can read those the risk to the application is far greater already. The risk is bigger for larger password databases that fall into the wrong hands, as far as I understand it.
Yep, that's true. The ZCML-stored passwords, however, are often manager accounts, that provide access to the whole system. So I would consider them also as pretty security-sensitive.
The most important part I think is to document well what people should be doing. I.e. use the new password managers (or tell them to upgrade and their old ones will be fine), and how they should go about upgrading existing passwords.
Agreed.
I think we should ask people to write their own upgrade code as we do not know where these passwords are stored. I'm storing them in a relational database in some cases, for instance. We could provide upgrade code for some common scenarios, but I'd be fine if we had a good document with instructions instead.
Sounds good to me. Looks like it would come down to upgrading zope.app.authentication and setting the passwords again. How this is done, might differ from system to system, but could be explained at least for some common scenarios. Best regards, -- Uli
Uli Fouquet wrote:
while working on a password manager tool (commandline) for Grok I stumbled over the usage of salts in the password managers of `zope.app.authentication`.
In short, they seem to generate (and store) a salt number but do not make any use of it when it comes to creating the hashes (SHA1, MD5, whatever). As a result, same passwords lead always to same hashes, only the leading salt number is different. This could be exploited by dictionary attacks.
We should really be using the SSHA standard (as defined by LDAP) as a minimum. SSHA was the default in Zope 2, but someone forgot to bring this code over to Zope 3. http://svn.zope.org/Zope/trunk/lib/python/AccessControl/AuthEncoding.py?rev=... A SHA-256 version of the algorithm would also be useful since cryptography experts expect SHA-1 to be vulnerable soon. Shane
Shane Hathaway wrote:
Uli Fouquet wrote:
while working on a password manager tool (commandline) for Grok I stumbled over the usage of salts in the password managers of `zope.app.authentication`.
In short, they seem to generate (and store) a salt number but do not make any use of it when it comes to creating the hashes (SHA1, MD5, whatever). As a result, same passwords lead always to same hashes, only the leading salt number is different. This could be exploited by dictionary attacks.
We should really be using the SSHA standard (as defined by LDAP) as a minimum. SSHA was the default in Zope 2, but someone forgot to bring this code over to Zope 3.
http://svn.zope.org/Zope/trunk/lib/python/AccessControl/AuthEncoding.py?rev=...
A SHA-256 version of the algorithm would also be useful since cryptography experts expect SHA-1 to be vulnerable soon.
So perhaps this should be ported over and we should do an announcement that we ask people to use that instead? Regards, Martijn
Martijn Faassen wrote:
Shane Hathaway wrote:
We should really be using the SSHA standard (as defined by LDAP) as a minimum. SSHA was the default in Zope 2, but someone forgot to bring this code over to Zope 3.
http://svn.zope.org/Zope/trunk/lib/python/AccessControl/AuthEncoding.py?rev=...
So perhaps this should be ported over and we should do an announcement that we ask people to use that instead?
Yes. The first volunteer to change "we should do it" into "I have done it" will earn recognition, glory, and a permanent place in Zope's Subversion history! Also, every encrypted password should have a scheme name prefix in curly braces, such as "{SSHA}", as discussed earlier in this thread. That makes it possible to support multiple schemes in a single database, which is essential for migration to new schemes. Shane
Shane Hathaway wrote: [snip]
Also, every encrypted password should have a scheme name prefix in curly braces, such as "{SSHA}", as discussed earlier in this thread. That makes it possible to support multiple schemes in a single database, which is essential for migration to new schemes.
+1 Regards, Martijn
Hi there, thanks for all input so far :-) Martijn Faassen wrote:
Shane Hathaway wrote: [snip]
Also, every encrypted password should have a scheme name prefix in curly braces, such as "{SSHA}", as discussed earlier in this thread. That makes it possible to support multiple schemes in a single database, which is essential for migration to new schemes.
+1
Such a fix can now be found in the ``ulif-saltfix`` branch of `zope.app.authentication`. _New_ passwords are now stored as {MD5}<LONG-HEX-NUMBER> {SHA1}<LONGER-HEX-NUMBER> {SSHA}<BASE64-STRING> respectively. Old passwords, however, are still accepted and correctly verified by the respective `checkPassword` methods. I didn't change the faulty salt handling of the SHA1 and MD5 password manager. Only the prefix is added now. Whoever wants more security, could use SSHA. Setting a new password (which can in fact be the old one) should update any old SHA1/MD5 passwords. Note, that these won't be more secure than the old ones! Only a prefix is added! Oh, yes, and an SSHA password manager now also exists. Implementation is based on Reed O'Briens sample on http://www.openldap.org/faq/data/cache/347.html. Some checks against passwords generated by `slappasswd` showed, that this SSHA password manager should be compatible with at least slapd-(SSHA-)passwords. Do we need a SMD5-manager as well (same as SSHA, only with MD5 instead of SHA1 as hash algorithm)? Any reviews by the more competent gurus in the list are highly appreciated. Best regards, -- Uli
Uli Fouquet wrote:
Do we need a SMD5-manager as well (same as SSHA, only with MD5 instead of SHA1 as hash algorithm)?
I doubt it.
Any reviews by the more competent gurus in the list are highly appreciated.
Your implementation and docs look fine to me. The only comment I have is I wonder why this is zope.app.authentication instead of zope.authentication, but that's a different discussion for another day. Shae
Hi there, Shane Hathaway wrote:
Uli Fouquet wrote: [snip]
Any reviews by the more competent gurus in the list are highly appreciated.
Your implementation and docs look fine to me.
Thanks for reviewing! It's all in trunk now.
The only comment I have is I wonder why this is zope.app.authentication instead of zope.authentication, but that's a different discussion for another day.
Good question. Why is there no `zope.authentication`? Best regards, -- Uli
Hi there, Shane Hathaway wrote:
We should really be using the SSHA standard (as defined by LDAP) as a minimum. SSHA was the default in Zope 2, but someone forgot to bring this code over to Zope 3.
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. 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 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.
A SHA-256 version of the algorithm would also be useful since cryptography experts expect SHA-1 to be vulnerable soon.
Yes, indeed. All that SHA-2 stuff (SHA-224, SHA-256, SHA384 and SHA-512) might be the choice for future. Unfortunately we have no out-of-the-box support for these in Python 2.4. They were introduced in Python 2.5 IIRC. Best regards, -- Uli
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.
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
Uli Fouquet wrote:
Is there some recent documentation about SSHA available? The netscape links seems to be down.
I finally found a good source. Look at the Python code at the bottom of this page: http://www.openldap.org/faq/data/cache/347.html Shane
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
Uli Fouquet wrote:
Ok. I'll put something into the zope.app.authentication branches for review.
Great!
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?
Well, the Linux man page for "urandom" says that /dev/urandom never blocks, while /dev/random can block if the entropy pool runs out. I assume os.urandom uses /dev/urandom.
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?
Let's not implement the SHA-2 version yet. SSHA, based on SHA-1, is sufficient for now. Shane
participants (6)
-
Dan Korostelev -
Martijn Faassen -
Shane Hathaway -
Tres Seaver -
Uli Fouquet -
Wichert Akkerman