Re: [Zope-dev] zope.globalrequest?
Martin Aspeli wrote at 2009-1-17 11:36 +: >Dieter Maurer wrote: >> Christian Theune wrote at 2009-1-16 09:06 +0100: >>> I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder >>> about it. IMHO this implements an anti-pattern in an official way >>> without a warning that this needs to be handled with care. >> >> IMHO, it is not an anti-pattern: >> >>We have a global "site" why should we not have a global request? >> >>When Zope is used as a Web Application Server, it is quite >>natural to expect a request. > >+1 > >However, there is a definite risk with it as well of encouraging poor >separation of concerns. If code is dependent on a request it's not >re-usable outside the web container. For views or web app controllers, >that's certainly fine, but if you're writing something more generic, >then it may be better to have the discipline to pass objects around that >properly abstract your data, rather than assume you can access the >request willy-nilly. We are in Python land -- and accustomed that using our freedoms occationally has a price :-) -- Dieter ___ 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] SVN: Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py Hhm, pdb?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > Log message for revision 94810: > Hhm, pdb?!? > > Changed: > U Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py > > -=- > Modified: Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py > === > --- Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py > 2009-01-17 20:01:44 UTC (rev 94809) > +++ Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py > 2009-01-17 20:41:54 UTC (rev 94810) > @@ -53,7 +53,6 @@ > for i in range( len( zipped ) ) > if zipped[i][0] != zipped[i][1] > ] > -import pdb; pdb.set_trace() > > print 'Found:' > print fxml That breakpoint was inside an if block guarded by 'if debug:', which shouldn't be set by any "real" test. 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 iD8DBQFJcrke+gerLs4ltQ4RAjWsAJ9WZErodZw4kACPvfEfKqWep5spGQCfQAqS NDOhvmIvdID8+kxl40QzssM= =g6P0 -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 - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 7 OK, 1 Unknown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan H.Holek wrote: >> That test seems to be timing out both yesterday and today trying to >> download docutils: do you think having the buildout use a >> download_cache would help? >> >> >> Tres. > > It certainly would. I am however reluctant to enable the download > cache because it may mask incomplete buildout configurations. > > When a suitable find-links location is missing in buildout.cfg, but > the requested egg is already in the download cache, buildout will > happily use it and not flag the broken configuration. OK, that is reason enough to endure the spurious errors from SF timeouts. 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 iD8DBQFJcrUP+gerLs4ltQ4RAmrPAKCrOUntF4rWlYUpJbYNn7iANYf5xwCeI5DQ 6cy0ZpmjvE44LiktilQPGq0= =f9rY -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 - 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?
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] Zope Tests: 7 OK, 1 Unknown
> > That test seems to be timing out both yesterday and today trying to > download docutils: do you think having the buildout use a > download_cache would help? > > > Tres. It certainly would. I am however reluctant to enable the download cache because it may mask incomplete buildout configurations. When a suitable find-links location is missing in buildout.cfg, but the requested egg is already in the download cache, buildout will happily use it and not flag the broken configuration. Stefan ___ 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 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?
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?
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] zope.globalrequest?
Hi, Am Samstag, den 17.01.2009, 11:36 + schrieb Martin Aspeli: > Dieter Maurer wrote: > > Christian Theune wrote at 2009-1-16 09:06 +0100: > >> I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder > >> about it. IMHO this implements an anti-pattern in an official way > >> without a warning that this needs to be handled with care. > > > > IMHO, it is not an anti-pattern: > > > >We have a global "site" why should we not have a global request? > > > >When Zope is used as a Web Application Server, it is quite > >natural to expect a request. > > +1 +1 as well > > However, there is a definite risk with it as well of encouraging poor > separation of concerns. If code is dependent on a request it's not > re-usable outside the web container. For views or web app controllers, > that's certainly fine, but if you're writing something more generic, > then it may be better to have the discipline to pass objects around that > properly abstract your data, rather than assume you can access the > request willy-nilly. Isn't there always the risk that people design software the "wrong" way? > > This is a documentation issue, though. > > Martin > Robert ___ 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?
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?
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 )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Fri Jan 16 12:00:00 2009 UTC to Sat Jan 17 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Fri Jan 16 20:53:04 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010863.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Fri Jan 16 20:54:34 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010864.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Fri Jan 16 20:56:04 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010865.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Fri Jan 16 20:57:34 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010866.html Subject: OK : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Fri Jan 16 20:59:04 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010867.html Subject: OK : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Fri Jan 16 21:00:35 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010868.html Subject: OK : Zope[2.buildout]-trunk Python-2.4.5 : Linux From: Zope Tests Date: Fri Jan 16 21:02:06 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010869.html Subject: OK : Zope[2.buildout]-trunk Python-2.5.2 : Linux From: Zope Tests Date: Fri Jan 16 21:03:36 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010870.html ___ 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?
Dieter Maurer wrote: > Christian Theune wrote at 2009-1-16 09:06 +0100: >> I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder >> about it. IMHO this implements an anti-pattern in an official way >> without a warning that this needs to be handled with care. > > IMHO, it is not an anti-pattern: > >We have a global "site" why should we not have a global request? > >When Zope is used as a Web Application Server, it is quite >natural to expect a request. +1 However, there is a definite risk with it as well of encouraging poor separation of concerns. If code is dependent on a request it's not re-usable outside the web container. For views or web app controllers, that's certainly fine, but if you're writing something more generic, then it may be better to have the discipline to pass objects around that properly abstract your data, rather than assume you can access the request willy-nilly. This is a documentation issue, though. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
