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 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-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 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}
  {SHA1}
  {SSHA}

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

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 )


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

> 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
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=94737&view=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 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=94737&view=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 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=94737&view=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-19 Thread Uli Fouquet
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



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-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 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-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
*

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-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 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 It 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 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 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=94737&view=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 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 It 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 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 :
> 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 )


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

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



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 )