PAS, AuthEncoding and zope.password
I was looking into bcrypt[1] support for PAS I found z3c.bcrypt, which implements zope.password compontents (named utilities). PAS, however, uses Zope2's AccessControl.AuthEncoding module to handle password encryption / hashing schemes. Now, while AuthEncoding certainly supports extending the available schemes, it does need additional glue-code to be able to reuse zope.password components. Moreover, we now have two places to maintain the various hashing and encryption schemes. We should at the very least convert PAS to use zope.password instead of AccessControl.AuthEncoding. With that change it is then at least trivial to support bcrypt as well, you simply install the additional z3c.bcrypt egg and be done with it. But would it make sense to convert Zope2 itself as well? We could make the AuthEncodings module simply a proxy (with deprecation warnings if need be) for zope.password components. Any objections to reworking both AuthEncoding and PAS? -- Martijn Pieters [1] see http://codahale.com/how-to-safely-store-a-password/ and http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/18/2011 04:19 PM, Martijn Pieters wrote:
I was looking into bcrypt[1] support for PAS I found z3c.bcrypt, which implements zope.password compontents (named utilities).
PAS, however, uses Zope2's AccessControl.AuthEncoding module to handle password encryption / hashing schemes. Now, while AuthEncoding certainly supports extending the available schemes, it does need additional glue-code to be able to reuse zope.password components. Moreover, we now have two places to maintain the various hashing and encryption schemes.
We should at the very least convert PAS to use zope.password instead of AccessControl.AuthEncoding. With that change it is then at least trivial to support bcrypt as well, you simply install the additional z3c.bcrypt egg and be done with it. But would it make sense to convert Zope2 itself as well? We could make the AuthEncodings module simply a proxy (with deprecation warnings if need be) for zope.password components.
Any objections to reworking both AuthEncoding and PAS?
- -1 to any deprecation warnings; +0 otherwise. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1e6TUACgkQ+gerLs4ltQ7M6ACgpYmHdAFTuTb8M+aoGQFuIzza waIAn2AHG4xx/0wAe2ZE2Q2izgXPFPrK =7sQ8 -----END PGP SIGNATURE-----
On Fri, Feb 18, 2011 at 22:19, Martijn Pieters <mj@zopatista.com> wrote:
We should at the very least convert PAS to use zope.password instead of AccessControl.AuthEncoding.
There is a snag. The zope.password API doesn't provide any way to detect what scheme was used for a given hash. Say you have a SSHA hash, it'll start with the string "{SSHA}", while a bcrypt encryption starts with "$2a$". Unfortunately, the zope.password IPasswordManager only provides methods to encode the password and check if a given password is correct. The only consumer of the interface, zope.app.authentication.principalfolder only supports one password manager at a time so never had a need to detect schemes. I'll just go ahead and expand then IPasswordManager interface to provide a match method that returns a boolean if a given hash uses the specific encoding scheme. Presumably this'll be zope.password 4.0.0. What does this mean for the versioning of AccessControl however? Will that'll be a 2.14 release? What version of Zope2 can start using the new AccessControl package with a "zope.password >= 4.0.0" dependency? Zope2 primarily uses the ZTK, so a version pin would be needed there until the new zope.password release makes it into the ZTK. -- Martijn Pieters
Hi. On Sun, Feb 20, 2011 at 11:41 AM, Martijn Pieters <mj@zopatista.com> wrote:
On Fri, Feb 18, 2011 at 22:19, Martijn Pieters <mj@zopatista.com> wrote:
We should at the very least convert PAS to use zope.password instead of AccessControl.AuthEncoding.
I'll just go ahead and expand then IPasswordManager interface to provide a match method that returns a boolean if a given hash uses the specific encoding scheme. Presumably this'll be zope.password 4.0.0.
Yes, changing the existing interface would require a 4.0. If you'd add a new interface extending the IPasswordManager one, we could do it in a 3.x release. A new zope.password 3.x release could go into both ZTK 1.1 and 1.0, a backwards incompatible 4.0 would have to wait for ZTK 1.2.
What does this mean for the versioning of AccessControl however? Will that'll be a 2.14 release?
Introducing a new dependency on zope.password will mean a 2.14 release.
What version of Zope2 can start using the new AccessControl package with a "zope.password >= 4.0.0" dependency?
This depends on the changes in AccessControl and how backwards compatible they are. If backwards compatibility is preserved, this can go into Zope 2.13 and trunk, since we allow minor feature additions in the stable series. Zope 2.12 is at a 2.12.15 release now and at the end of its lifecycle - it'll only see bugfixes. Hanno
On Sun, Feb 20, 2011 at 11:56, Hanno Schlichting <hanno@hannosch.eu> wrote:
Yes, changing the existing interface would require a 4.0. If you'd add a new interface extending the IPasswordManager one, we could do it in a 3.x release.
A new zope.password 3.x release could go into both ZTK 1.1 and 1.0, a backwards incompatible 4.0 would have to wait for ZTK 1.2.
Right. What would be a suitable name for the extended interface? IMatchingPasswordManager? I've committed a revision that implements this as an extension to the existing interface: http://zope3.pov.lt/trac/changeset/120458/zope.password/trunk but that's easy enough to change. I've also found that the SHA1 scheme in zope.password uses the {SHA1} prefix, which is incompatible with LDAP and AccessControl.AuthEncoding, which both use {SHA} instead. I'll change zope.password to support {SHA} as well, defaulting to that prefix.
What version of Zope2 can start using the new AccessControl package with a "zope.password >= 4.0.0" dependency?
This depends on the changes in AccessControl and how backwards compatible they are.
If backwards compatibility is preserved, this can go into Zope 2.13 and trunk, since we allow minor feature additions in the stable series. Zope 2.12 is at a 2.12.15 release now and at the end of its lifecycle - it'll only see bugfixes.
It'll be backwards compatible. I'm planning to keep supporting legacy schemes registered with registerScheme, with listSchemes listing zope.password managers as well. The only thing that could perhaps be removed are the SSHADigestScheme and SHADigestSCheme classes, as these will be completely redundant with zope.password support. -- Martijn Pieters
On Sun, Feb 20, 2011 at 12:39, Martijn Pieters <mj@zopatista.com> wrote:
Yes, changing the existing interface would require a 4.0. If you'd add a new interface extending the IPasswordManager one, we could do it in a 3.x release.
A new zope.password 3.x release could go into both ZTK 1.1 and 1.0, a backwards incompatible 4.0 would have to wait for ZTK 1.2.
Right. What would be a suitable name for the extended interface? IMatchingPasswordManager?
I've committed a revision that implements this as an extension to the existing interface:
http://zope3.pov.lt/trac/changeset/120458/zope.password/trunk
but that's easy enough to change.
I've also found that the SHA1 scheme in zope.password uses the {SHA1} prefix, which is incompatible with LDAP and AccessControl.AuthEncoding, which both use {SHA} instead. I'll change zope.password to support {SHA} as well, defaulting to that prefix.
I've implemented the {SHA} prefix change, as well as implement {CRYPT} support, making zope.password useful for all schemes explicitly named in RFC 2307, except the MD5 scheme. The latter uses a salt by default, making it incompatible with LDAP {MD5}. Open LDAP implements a salted MD5 scheme ({SMD5}) but places the salt at the end of the hash, not at the beginning as the zope.password manager implements it. I think I can keep that one backwards compatible but disable support for generating hashes with a salt, and add a SMD5 manager to implement a compatible scheme. With all the new password managers, this will be at least a 3.7 release, with a separate extended interface. -- Martijn Pieters
participants (3)
-
Hanno Schlichting -
Martijn Pieters -
Tres Seaver