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
Possibly simply register 2 new names then, one without fallback and one
> 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
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -