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

[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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20090118/e10fd08a/attachment.bin