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". -- Steven -- https://mail.python.org/mailman/listinfo/python-list
