Re: [Zope-dev] Salt-weakness in zope.app.authentication passwordmanagers?
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] Zope Tests: 6 OK, 2 Failed
Tres Seaver wrote: Zope Tests Summarizer wrote: Summary of messages to the zope-tests list. Period Mon Jan 19 12:00:00 2009 UTC to Tue Jan 20 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Test failures - Subject: FAILED (failures=2) : Zope[2.buildout]-trunk Python-2.4.5 : Linux From: Zope Tests Date: Mon Jan 19 20:57:35 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010893.html Subject: FAILED (failures=2) : Zope[2.buildout]-trunk Python-2.5.2 : Linux From: Zope Tests Date: Mon Jan 19 20:58:35 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010894.html Hmm, both failures in tests related to reSTX: could this be due to upgrading docutils from 0.4 to 0.5? Yes, probably. I reverted to docutils 0.4 now, as I don't have time to follow up on these before the weekend. Hanno ___ 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?
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 )
[Zope-dev] Plans for Zope 2.12
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, based on an earlier Zope 2.12 thread http://mail.zope.org/pipermail/zope-dev/2008-October/033572.html I propose that we get out an alpha version of Zope 2.12 by end of February. http://mail.zope.org/pipermail/zope-dev/2008-October/033572.html Major changes: - - dropping Python 2.4 support officially (Python 2.4 is no longer officially supported by the Python developers so we can not safely support it) - - focus on Python 2.6 support for the final release (although there are still some tests failing - more than with Python 2.5). Possibly focus on Python 2.5 support for the alpha phase. Not sure if we want to support Python 2.5 and 2.6 officially at the same time. With the current classification of Python versions within the configure script I would suggest: TARGET=Python 2.6.X ACCEPTABLE=Python 2.5 Python 2.4.X would be basically not acceptable but could be used at your own risk using the --with-python option. - - complete eggification (apparently pretty much done) - - reducing Zope 3 dependencies (apparently pretty much done) - - removing ZClasses completely - - ship with ZODB 3.9 (currently in alpha stage) Rough edges/open points I encountered so far: - - RestrictedPython security audit: such an audit has been made by Stefan and Sidnei. I am not qualified to speak about the correctness of the audit. I assume they know what they were doing. Unless objections one might consider this issue as resolved - if not, please speak up. - - creation of some skripts e.g. mkzeoinstance when easy_install-ing the Zope 2 source distro does not seem to work or it is still missing - - how do to a traditional SVN checkout of the Zope 2 and the related Zope 3 modules? The Zope2.buildout maintains its dependencies through a KGS - the old-style SVN checkout uses svn:external. I think there is a need for having both and don't know of a save way for keeping the svn:externals and the KGS in sync (without additional manual effort). Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkl3KWoACgkQCJIWIbr9KYyKOwCfVI+gU1AZsIstWies9BVRGr4l +LcAn1MBC0jsed690vpeU2TJzYUz6xQ+ =YZQ/ -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ 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?
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] Plans for Zope 2.12
On Wednesday 21 January 2009, Andreas Jung wrote: - RestrictedPython security audit: such an audit has been made by Stefan and Sidnei. I am not qualified to speak about the correctness of the audit. I assume they know what they were doing. Unless objections one might consider this issue as resolved - if not, please speak up. Note that Jim never explained to me how he does these audits, but I gathered some methods he used in conversations. I think I did a pretty thorough job during the review. - how do to a traditional SVN checkout of the Zope 2 and the related Zope 3 modules? The Zope2.buildout maintains its dependencies through a KGS - the old-style SVN checkout uses svn:external. I think there is a need for having both and don't know of a save way for keeping the svn:externals and the KGS in sync (without additional manual effort). You can write the svn:externals via a script. I did that for the big Zope 3 tree in zope.release. http://svn.zope.org/zope.release/branches/3.4/src/zope/release/tree.py?rev=81907view=auto The documentation is here: http://svn.zope.org/zope.release/branches/3.4/src/zope/release/README.txt?rev=81907view=auto Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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?
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?
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] zope.globalrequest?
Hi Martijn Betreff: Re: [Zope-dev] zope.globalrequest? Hi there, Roger Ineichen wrote: [snip] Why should someone use a global request if he has a request available? This package does nothing else then offer a request if non is available. And if you need a request if non is available there is something wrong with the application design. Or better let's say it's another pattern then we use in zope 3 right now. I don't think that's always true. Let me give you an example. I wrote a library called hurry.resource. This library is framework neutral. You can define a javascript or css resource and express that you need it to be included in the page in a certain code path: yui.datatable.need() I also have a library called hurry.zoperesource. This library provides integration of hurry.resource with Zope 3. When need() is called in a Zope 3 context, I need the request object as I chose the request object as the place to store the list of resources that are needed. So I need to get the request without having it. You could argue my library isn't designed right, and that instead I should require people to pass 'request' to the .need() method. But since hurry.resource is framework-neutral, what request should that be? And in a system like Pylons it makes no sense to have to pass in the request, as it's available globally everywhere. It only seems to put an implementation detail into the API. Besides the framework neutralness argument, which you can argue makes no sense, I think it's simply a nicer API to say '.need()' instead of having to pass the request. That's a weaker argument, however. That said, zc.resourcelibrary does the same strategy, as that's where I took it from. Anyway, I do believe there are cases of APIs that need the request internally but want to abstract it away as an implementation detail. I guess I might've been able to use the interaction directly in Zope 3's case and I shall study that. There are of course drawbacks (as mentioned) with testing and such when taking this approach. But I think one can make a reasonable case for such an API nonetheless, when used in moderation. I see your point. I'm not saying that this is bad in general. Probably when used in moderation is the right concept for this package ;-) Regards Roger Ineichen 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 ) ___ 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 )
