steve+comp.lang.python at pearwood.info
Sun Jan 18 00:46:10 CET 2015
Mark Lawrence wrote:
> Bah humbug, this has reminded me of doing secure work whereby each
> individual had two passwords, both of which had to be changed every
> thirty days, and rules were enforced so you couldn't just increment the
> number at the end of a word or similar.
I hate and despise systems that force you to arbitrarily change a good
strong password after N days for no good reason.
The utterly bad reason often given by people who don't understand
probability is that if hackers try to guess your password by brute-force,
changing the password regularly will make it harder for them. That's simply
wrong, and is based on a misunderstanding of probability.
The merely poor reason given by the more thoughtful sys admins is, if the
password hashes get stolen, the hacker has a maximum of N days (and
possibly less) to crack the hashes and recover the passwords before they
get changed. That's okay as far as it goes, but it's the wrong solution for
the problem. The right solution is to salt the passwords, and to secure the
hashes from theft. Users should only be forced to change their password if
the hashes are stolen, not at arbitrary intervals.
The problem with regular password changes is that it makes it significantly
harder remember passwords, especially one that you might only use rarely.
It encourages users to pick weak, trivial passwords that can be trivially
incremented each time the computer insists they change it, "blahblah-JAN"
or "blahblahblah1", or to simply write the password down or a Post-it note
on their computer. In isolation, regular password changes seems like a good
idea, but in practice they are not.
Password management is hard enough without having to throw away perfectly
good, strong, memorable passwords every N days "just in case".
More information about the Python-list