On 2012/1/2 lodewijk andré de la porte <[email protected]>: > The reason for regular change is very good. It's that the low-intensity > brute forcing of a password requires a certain stretch of time. Put the > change interval low enough and you're safer from them.
This may make sense in specific cases, but in the general case, say for web sites that have a large # of public users, there are other things that this has to be weighed against. Specifically consider cases where users might only login once a month to pay a bill. If you require those users to change their passwords every 30, 60, or 90 days, they probably will never actually have time to learn it. And since we've tried to teach people not to write down their passwords on PostIt notes, etc. many of these users don't write them down at all. So the end result is that many of these types of users frequently forget their passwords, because they only use them 2 or 3 times before they have to change them again. So that has the undesirable effect of increasing calls to the helpdesk to have users' passwords reset. To drive this additional helpdesk cost down, IT then decides to implement a "I forgot my password" mechanism that is generally based one some set of trivial Q & A such as "What is your favorite sports team?" or "Where did you attend elementary school?", etc. thus causing over major security issues. So I would conjecture, at least in cases like this where users only login infrequently, that the password change policy every N days be done away with, or at the very least, we make N something reasonably long, like 365 or more days. That's why I've said and will say again, that your security policies should be driven by your specific threat model. Unfortunately, most companies don't do this. Instead that they just perpetuate the myth that everyone should be required to change their password every N days because this is obviously best security practice for everyone. It may be for your specific threat model, but it also might not be. > We've had someone talk on-list about a significant amount of failed remote > ssh login attempts. Should he chose not to force user to change their > passwords they wouldn't. And the likelyhood of a successfull login > would improve with the years (given coordination) to somewhere above the > admin's comfort zone. > > The timeframe in which a password has to change also limits the maximum time > exposed once someone has cracked it. This is relevant when the adversary > needs multiple opportunity's to coincide. The amount of time it'll have > access without triggering resource-counting or other "suspicious behavior" > alarms becomes limited, as changing a password would either lock him or the > legitimate user out. Although requiring the use of SSH public/private keys probably would be better way to go here. The big problem here is for *nix systems at least, even if you remember your password and could change it, trying to remember 20+ ferent passwords for 20+ different servers, all which expire at different times is, at a minimum, a major pain in the ass, and generally will cost you in terms of requiring a password having to be reset by some system administrator plus all the helpdesk overhead. > For most systems though, it's a complete waste of time. Agree. -kevin -- Blog: http://off-the-wall-security.blogspot.com/ "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents." -- Nathaniel Borenstein _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
