On Dec 27, 2011, at 12:54 PM, Jeffrey Walton wrote:
> Hi All,
>
> 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?
What's your goal? Is it to make passwords really, really unguessable by any
means other than brute force?
If it is, then I agree with Steve Bellovin. A Bloom filter can minimize the
usability of your system and cause the greatest likelihood that your users will
forget their new password and need it reset. After a while, they'll give up and
go somewhere else.
If you want to speed up the process, be sure to track down all the databases of
passwords from hacked web sites and compare the user's new passwords to those.
I also recommend using some regexps in there, too. Be sure to make sure that it
doesn't follow with something like [0-9\-!@#$%^&*,./]{1,12} as well, because
that's easily hacked. Any password in those databases is equivalent to the null
string, for security purposes and they really need a 12-character password for
top-notch security anyway. Be sure also to keep the last hundred used
passwords. With a policy using advanced similarity testing, it will be easier
for someone to change it a half-dozen times than create a new one, and you want
to prevent that.
Be sure also to force a password change for everyone any time there's a
personnel change in your IT organization, because those people could have
walked off with everyone's password.
Do your goals include the user experience at all? Are these people your
customers? Are you in an industry where you have competitors? If so, maybe you
don't want to do any enforced password changes. First of all, every time they
get annoyed, they there's a chance they'll go to a competitor. Second of all,
there are very good reasons that many security people (including me) think that
enforced password changes actually lower security. Whether they do or not, a
change sends the message that the user's own personal security is better than
yours. I suppose one could debate that one, too, but I'm on that side, myself.
On the other hand, if they're your employees, screw them. I mean, they should
just be thankful to have a job at all, and the increased help tickets --
particularly ones that can be quickly resolved, like lost passwords -- make
your metrics better.
Jon
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
