Markus Werner wrote:
Migration steps.
- Move all auth: MD5-PW to a new md5-pw object and reference them.
- At some day it is possible to say that md5-pw are obsolet and deny creation of new objects. So new users get forced to use a other method.
- After time you can force users to update the auth method everytime they need to edit an object.
Nice. But seems too soft, and it takes a long time to migrate... My view: - Implement md5-pw object in database - Autocreate md5-pw objects for all existing md5 passwords - Autochange hashed passwords with md5-pw objects - Include "remark: see http://... for what's happened" in chaned objects Like it was in person/org objects when russian area phone codes was changed. -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Max et.al. before digging deeper and commenting on more general aspects, do I understand it correctly that ... Max Tulyev wrote: [...]
My view:
- Implement md5-pw object in database - Autocreate md5-pw objects for all existing md5 passwords - Autochange hashed passwords with md5-pw objects - Include "remark: see http://... for what's happened" in chaned objects
Like it was in person/org objects when russian area phone codes was changed.
... you basically propose to align _all_ authentication mechanisms in the sense that the necessary information to check credentials is stored in a _separate_, dedicated object, like it is done already for PGP and X509? Wilfried.
On Jul 25, Max Tulyev <president@ukraine.su> wrote:
My view: When arguing about security vulnerabilities it is a good idea to provide a threat model explaining exactly how much the current system is insecure. I have not seen one, and I object to implementing all this without a clear analisys of why wisely chosen MD5-hashed passwords are not secure enough when the hashes are publically disclosed. Especially considering that people who want an higher level of security can already use PGP or X.509 authentication and are not be vulnerable.
-- ciao, Marco
participants (3)
-
Max Tulyev -
md＠Linux.IT -
Wilfried Woeber, UniVie/ACOnet