On 28/12/11 09:48 AM, Solar Designer wrote:
On Tue, Dec 27, 2011 at 03:54:35PM -0500, Jeffrey Walton wrote:
We're bouncing around ways to enforce non-similarity in passwords over
time: password1 is too similar too password2 (and similar to
password3, etc).
I'm not sure its possible with one way functions and block cipher residues.
Has anyone ever implemented a system to enforce non-similarity business rules?
No. It seems to be solving the wrong problem.
Password histories are controversial. They do not obviously improve
security; they may as well make things a lot worse (even if you're just
storing hashes).
Yeah. Scratch an itch, add a risk. http://xkcd.com/936/
I would suggest if you want to do put a filter in place, then give users
a working practice for dealing with the change of passwords.
E.g., 1. write the password down in a known safe place. 2. use
ephemeral words that relate to the moment, like name of today's
appointment. 3. share your password with at least one other person in
your office.
The point being that they will anyway, might as well make it safer:
... After the
contest, they released John the Ripper rules that try to match users'
typical approaches at bypassing password histories - appending the
current year, month name, etc. Apparently, this is what actually
happens when there's a password history and regular password changes are
enforced.
Sounds like a good final year student project, figure out what users do
and create a tolerable practice for meeting them in the middle...
iang
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
