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

[Martijn Faassen]

Hi there,

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?

> 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.

>    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).

If it's not possible to update the existing password managers to the new 
behavior a new name + fallback sounds like the best way to go.

>    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.

> 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.

Why a commandline tool? Wouldn't it be better to just have an API to 
help upgrade passwords?

> 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.

> There might be smarter approaches. Any hints are very welcome.

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.

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.

Regards,

Martijn