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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )