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

2009-01-22 Thread Uli Fouquet
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



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 )


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

2009-01-21 Thread 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=94737view=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 )


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

2009-01-21 Thread Martijn Faassen
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

___
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 )


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

2009-01-21 Thread Uli Fouquet
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



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 )


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

2009-01-21 Thread Shane Hathaway
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

___
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 )


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

2009-01-21 Thread Shane Hathaway
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
___
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 )


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

2009-01-20 Thread Martijn Faassen
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=94737view=markup
 
 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

___
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 )


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

2009-01-20 Thread Uli Fouquet
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=94737view=markup

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



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 )


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

2009-01-20 Thread Shane Hathaway
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=94737view=markup
 
 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
___
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 )


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

2009-01-20 Thread Shane Hathaway
Uli Fouquet wrote:
 Shane Hathaway wrote:
 http://svn.zope.org/Zope/trunk/lib/python/AccessControl/AuthEncoding.py?rev=94737view=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

___
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 )


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

2009-01-20 Thread Shane Hathaway
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

___
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 )


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

2009-01-19 Thread Martijn Faassen
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

___
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 )


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

2009-01-19 Thread Tres Seaver
-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  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://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-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 

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

2009-01-18 Thread Uli Fouquet
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



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 )


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

2009-01-17 Thread Dan Korostelev
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 u...@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, 0x)
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, 0x)
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
___
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 )


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

2009-01-17 Thread Wichert Akkerman
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 wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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 )


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

2009-01-17 Thread Shane Hathaway
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=94737view=markup

A SHA-256 version of the algorithm would also be useful since 
cryptography experts expect SHA-1 to be vulnerable soon.

Shane

___
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 )


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

2009-01-17 Thread Uli Fouquet
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



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 )


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

2009-01-17 Thread Wichert Akkerman
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 wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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 )