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

[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

-------------- 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/20090119/c6f63dde/attachment.bin