> Why is it "good" to change your password periodically?
That depends on what it's being used for. Changing your password on systems you own (and monitor) might not be necessary if they're 'good enough', although if you can ditch passwords entirely that's much better (e.g. using One Time Pads, Public Key auth etc.)
From a compliance perspective forcing people to periodically change passwords in theory means that while a certain amount of users will have insecure passwords, that over time this will change or rotate at least. In practice it doesn't generally work that way but COBIT tells us to do it anyway so we tick the box.
If you don't own the system then you can't assume that the system hasn't been owned, so periodically changing passwords is seen to be a good thing(tm) as it stops people from having persistent access to your stuff. Again, real world deviates significantly on theory on this, but YMMV.
The frequent changes don't necessarily create weaker passwords, they do disrupt password guessing slightly. For example, imagine organisation foo has a password policy requiring monthly changes. The default password is welcome1, so inevitably people change it to welcome2, welcome10 etc.
Once I've got the hashes I see that I'm pulling off a lot of welcome1s, and welcome2 works as well. I do have to do some work to get the rest of the welcome<nn> and welcome<nnn> but on the whole it's fine, except for the guy that chooses a password that doesn't fit the common password ('that guy' with welcome1welcome2welcome as his password in this case). So it doesn't have a significantly measurable effect for all people, but may have for some. Yeah, it's still a load of rubbish though :)
If the password is sufficiently complex then the keychain solution should work and changing it is unlikely to have any statistical effect unless someone's doing a very slow and long winded sequential brute force (in which case changing a password to earlier in the sequence may help, but that would require a priori knowledge of the sequence and position and is impractical). With the keychain solution the only measurable difference would be that the resulting password would be better, worse or the same in terms of complexity and length tradeoff, but that's down to the algorithm.
>it stops people from having persistent access to your stuff.
I can buy that, but that's far from the most likely danger on the internet. Usually it's the equivalent of a smash-and-grab job; break in, download everything of value within minutes, never go back (unless you can install a trojan, bypassing passwords anyway). Because going back in multiple times raises flags.
And every system with any reasonable need for security should detect questionable access from new locations, and block them until they are verified. Not all of them do, of course.
The must-change-password tradition seems more and more like a blind dogma for proper systems, because it's a slightly-effective bandaid for really crappy ones. I have yet to see a reason why, in an even half-way decent system, it's not actually a detriment due to weakened passwords / people writing them down where others can see.
>Once I've got the hashes...
... you've already got access to all the info in their database, likely in their entire networked system. That's infinitely more destructive - all those passwords can be changed within days, rendering them useless for re-entry. And it's safe to assume that they will do so, as per above in an even half-way decent system with any kind of logging whatsoever.
As a bandaid for systems which need a bandaid, I admit, they do have (minor) advantages. But such systems shouldn't exist in the first place, and are less and less of an option for newer systems, as proper setups are getting easier and easier to create. And I fear that, as long as they're seen as an effective bandaid, the weaker systems will be more likely to be used because there's an effective bandaid to improve their security. And such systems are usually more vulnerable to trojans, which are a far greater and more real danger than someone guessing someone's password.
> Usually it's the equivalent of a smash-and-grab job; break in, download everything of value within minutes
Is that still the case? I was under the impression that these days, account/identity access has black market value. People sell each other lists of accesses. That means there is a certain -- maybe even significant -- amount of time between when somebody has cracked your password and when somebody will make use of that access.
Which is after someone has made a dump of all the user info from a database. Which should be detectable by any logging software. Which means the company should have taken steps within the day to change all passwords.
And again, this is what any company at all interested in security should be doing, and is relatively easy to do. Not what they all do. I'm arguing against the blind following of tradition, not that it isn't an easy way to improve things slightly at horrifyingly insecure locations. And if your security depends on changing your password routinely, you have much larger problems.
All of this makes the passwords useful only for breaking into other sites, as people re-use passwords. It's the personal information that's valuable, not that the password was used at location X. A person's password entirely detached from its source is still valuable, because of that re-use.
But a unique random password means they got nothing but a day's worth of access to the location they got it from, which they apparently already had, likely at a significantly-higher security level than you have. Changing it monthly helps this... how?
Lots of them. SSH supports it natively, for a high-profile example. I see them every couple months as a learn-to-program project, or look-at-this-neat-index-card-trick.
That depends on what it's being used for. Changing your password on systems you own (and monitor) might not be necessary if they're 'good enough', although if you can ditch passwords entirely that's much better (e.g. using One Time Pads, Public Key auth etc.)
From a compliance perspective forcing people to periodically change passwords in theory means that while a certain amount of users will have insecure passwords, that over time this will change or rotate at least. In practice it doesn't generally work that way but COBIT tells us to do it anyway so we tick the box.
If you don't own the system then you can't assume that the system hasn't been owned, so periodically changing passwords is seen to be a good thing(tm) as it stops people from having persistent access to your stuff. Again, real world deviates significantly on theory on this, but YMMV.
The frequent changes don't necessarily create weaker passwords, they do disrupt password guessing slightly. For example, imagine organisation foo has a password policy requiring monthly changes. The default password is welcome1, so inevitably people change it to welcome2, welcome10 etc.
Once I've got the hashes I see that I'm pulling off a lot of welcome1s, and welcome2 works as well. I do have to do some work to get the rest of the welcome<nn> and welcome<nnn> but on the whole it's fine, except for the guy that chooses a password that doesn't fit the common password ('that guy' with welcome1welcome2welcome as his password in this case). So it doesn't have a significantly measurable effect for all people, but may have for some. Yeah, it's still a load of rubbish though :)
If the password is sufficiently complex then the keychain solution should work and changing it is unlikely to have any statistical effect unless someone's doing a very slow and long winded sequential brute force (in which case changing a password to earlier in the sequence may help, but that would require a priori knowledge of the sequence and position and is impractical). With the keychain solution the only measurable difference would be that the resulting password would be better, worse or the same in terms of complexity and length tradeoff, but that's down to the algorithm.