I’m sure everyone has at least one account (most likely a work account) where the password expires every
Often this is every 60-90 days and really, who has the will or time to come up with an actually secure password in the face of being locked out of your account? You just want to get your work done, right? So you just increment the number or perhaps letters (Months in the form of Jan, Feb, Mar are good candidates. ) So how’d this come about? Somehow it got baked into a bunch of compliance bullshit, as we’re about to see.
From what I can find, this came from the DoD in the 1970’s, where they figured they should make passwords expire before their mainframes could crack the (DES?) hashes. There are also a few papers from the 1970’s that reference this. https://www.computer.org/csdl/proceedings/afips/1977/5085/00/50850027.pdf http://csrc.nist.gov/publications/history/ande72.pdf
9.2.3 Management of privileged access rights
h) for generic administration user IDs, the confidentiality of secret authentication information should be maintained when shared (e.g. changing passwords frequently and as soon as possible when a privileged user leaves or changes job, communicating them among privileged users with appropriate mechanisms)
This only applies to shared accounts, which you shouldn’t have. All accounts, even service accounts should be named/audited accounts. If you do have them, they should be changed every single time an employee who has had access to them leaves the company. (This never happens in most companies)
9.4.3 Password management system
A password management system should:
;enforce regular password changes and as needed;
Note the AS NEEDED. This means that upon suspicion or likelihood of compromise a users password will be needed. Note it doesn’t specify a time frame, therefore a regular “1 year” password expiry is sufficient.
ISO27K does NOT mandate forced 90 day password expiry.
I couldn’t find any specific text that says you must specifically expire passwords every (x) days. If anyone knows of this, let me know.
8.2.4 Change user passwords/passphrases at least once every 90 days.
This says: Passwords/phrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase
However, 90 (45) days is plenty for an attacker to crack even strong hashes if I user chooses a weak password as well as plenty of time to get backdoor access that doesn’t depend on legitimate credentials.
8.2.5 Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used.
This requires a reversible encrypted storage of the previous four passwords. If an attack gets their hands on this..
Users will also just find a way around this. A good example is “Cr4pPasswordFeb” then “Cr4pPasswordApr”. This will get around most “incrementing not allowed” rules.
The above is mitigated by: 8.3 Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance).
NOTE: PCI-DSS policy only applies to accounts that view/access cardholder data or access systems with cardholder data. Normal desktop user/admin accounts are NOT required to follow 8.2.4/8.2.5. PCI-DSS is all about scope.
Control Reference: 01.d User Password Management: “vii.” passwords shall be changed at least every 90 days or based on the number of accesses; “viii.” passwords for privileged accounts shall be changed at least every 60 days;” However, you can get a “get out of jail for a bit longer” card here You can use “alternative controls”, where an example given is proposing the extension of password expiration to one year by increasing complexity of the password.
Of course, this brings us to the fact that nowhere does anyone actually explain what 60-90 day password expiry is meant to protect against. Assumedly the reason is to limit the windows of exposure.
The problems with (short) password expiry:
Users will use not very good passwords because they will have to just forget it 60/90 days later.
Why bother trying to create and memorise a good strong password/passphrase if the system just makes you change it in 2-3 months time? Screw that! You’ll come up with the shortest most memorable password you can think of in order to get your work done. Then next time it expires, just increment a number or add an a or something on the end.
One common technique is just jamming a month on the end, then incrementing that. Most “You can’t use your last four passwords” or “No incrementing!” systems will be fooled by that.
Doesn’t protect against poor hashes in regards to offline password cracking.
If you’re talking about AD hashes here, then as far as I can tell AD hashes are just a single round MD5 (or MD4). My video card (An R9 290) can do ~8 BILLION MD5 hashes a SECOND. If an attacker gets your AD hashes, they will blow through those way before most of the passwords expire.
If your password hashing algorithm isn’t bcrypt/scrypt/PBKDF2 or Argon2 then anyone with your password hashes is still going to be able to crack your users passwords before their passwords expire. Even if they don’t, you still have the incrementing problem. Even with bcrypt/etc an attacker with a good dictionary is likely to get a few of them, your password complexity rules be damned.
If they’re really determined, they can just throw more and more hardware at the problem and crack them faster than your users can change them.
Increase in IT help desk load/cost. Decreased productivity. Raises the odds of successful social engineering attacks against the IT help desk.
This is a people problem, where if people actually create decent (hard to remember!) passwords, they’re more likely to forget them than ones that don’t expire or ones they can take time to get right. (Especially if the password change happens on a Friday!)
This increases the load/cost on the IT help desk due to higher amounts of password resets. Decreases (and pisses off) user’s productivity. Also increases the odds of a successful social engineering attack.
Know when someone started at (employer)? Or maybe just get lucky? Call up the help desk, pretend to be a poor frustrated user who really just needs to get their work done, but they’ve forgotten their (newly set) password. IT will more than likely let you do it.
There is also the problem of saved and automated credentials. If you have an app using your credentials for something (subversion or an automated script) then as soon as your user changes their password, the app with the now invalid credentials will trip your account lockout, locking the user out of their account and more load on the IT helpdesk.
SSO vs non SSO accounts.
If you use things like Skype, Hipchat, Join.me and other services that aren’t SSOed, you have a few options. (None of which are good).
You can try to force users to rotate their 3rd party app/website logins the same time they do their main account. Then scapegoat them when a) they just set all those passwords to the same thing or b) they forget to rotate the 3rd party accounts and then one of those 3rd party services gets hacked and oh hey, the attacker now has access to all the other 3rd party services you use if a) or b) Well, they violated policy (and still get fired) but at least the attacker didn’t get their domain creds!
You can try and force them to all be different, but good luck with that. (See the Increase load on help desk when your users forget them all)
Your only good option here is to ONLY use sites/apps that you can federate with your SSO. Anything else will suck for your users. (Of course, if your SSO creds get leaked, you have no not-compromised way to contact your users)
Attackers (if they’re any good) will find a way to establish a backdoor into your system that doesn’t rely on the stolen/cracked credentials.
This could be the attacker setting up their own account on your system, that they will just change the password on if you have a password expiry set.
Otherwise they will establish some kind of backdoor that can call out to systems they control or some other kind of persistence that doesn’t rely on the stolen credentials that you are dutifully rotating every 90 days.
Some attackers may wait a certain time before using the credentials or using them to establish a foothold inside your infrastructure, this will usually happen before passwords expire. If you’re being targeted specifically, they can do this quickly. (Inside of a day or two).
Other attackers will do the damage as soon as they get in.
Users will write down their new (complex but no longer secure) passwords.
Especially if they need access to that resource NOW. What happens to those old post notes? Well, they’ll probably stick around.
You can even have a password policy that says they’re not allowed to do this, but hey, they’re only human. But that’s OK, you can always scapegoat them. (As i’ve heard from a few C levels. Yeah, really.)
Some attacks don’t rely on stealing usernames/passwords.
This includes stuff like phishing, exploits used against software vulnerabilities (Whether they’re 0days or not), pass the hash, social engineering, physical attacks, badly designed network/cryptographic protocols, bad HTTPS, no credentials on API/etcs, default creds. Basically all of the OWASP top 10. None of these necessarily rely on valid credentials, so your 90 day password resets won’t protect you against these.
Persistent keyloggers/Remote Access Trojan’s will just steal the new passwords.
Someone drops a keylogger/RAT on your users box either by drive by’s/malvertising or phishing and if your endpoint management system or IDS/DPI boxes don’t pick that up then they’ll just deliver your users newly changed credentials up to the attackers. You’ve just forced your user to change their password for nothing!
Password expiry does not address password disclosure.
So some how you find out that your users password got leaked or disclosed? You get them to change it! A forced 90 day password expiry does nothing to address this. Infact you’ve just pissed off the user some more, since they’ll just have to change it after 90 days again. (Or the next disclosure, whichever comes next)
2FA mitigates the risk/vulnerability? “addressed” by password expiry.
Use 2FA. Seriously, just roll it out everywhere you can. The newer compliance stuff requires 2FA anyway.
Congratulations, you’ve just addressed the issue password expiry supposedly addresses! Now stop forcing your users to change their passwords every 90 days. You’ve already inconvenienced them with 2FA. (Whether T/HOTP, SMS, U2F, etc).
If an attacker gets your user’s credentials and you have 2FA the attacker will go to use them and hopefully trigger your monitoring system. (You have monitoring right?)
Even though it’s possible to steal 2FA token secrets, you’re still in a way better place than you were without 2FA + password expiry.
Even better, a TOTP changes every 30-60 seconds. Tell that damned auditor that your users login credentials change every 30 seconds.
Do you also force SSH keypairs to be rotated every 90 days? Or just the password protecting them? (Which if you haven’t updated your ssh client will be hashed with single round MD5. Yes, really. You want bcrypt formatted SSH keys
Now, everyone (should) know that you should never use shared accounts. Infact, a bunch of the compliance bullshit requires that you don’t have them. But we all know everyone has service or shared accounts. Does your password expiration policy apply to these too?
If so, you’ve now increased the chance of disclosure or malicious use of these credentials, since you have to communicate the new passwords to all the users that use these accounts.
Not to mention if the new password isn’t communicated to everyone, you’ve just locked out those users.
You have logging and monitor those logs with alerting/dashboards/SIEM/etcetc right? Well all those password changes and password resets are going to clutter up your logs and ping your monitoring systems.
Hope you don’t miss an attacker resetting or other messing with accounts because you thought it was just normal password expiry activity!
Mentioned above, but phishing is a major attack vector and so many users still fall for it. (This isn’t necessarily their fault, email is not and has never been a secure/trustworthy communication medium)
Password expiry won’t protect your users against phishing as the attacker can either drop a RAT on their machine or have systems setup to immediately login with the stolen creds and do whatever they’re going to do.
Even if they don’t use them immediately, the attackers still have plenty of time to use those credentials and establish persistance.
Bad JML (Joiners/Movers/Leavers) processes.
I suppose this is an argument that works for password expiry. When users leave if your JML process is so bad that you don’t immediately expire/lockout/disable their account then they or an attacker can only get into your network/infrastructure until their password expires. Note however that some systems will let you login with your old password, after it has expired, in order to change it, in which case password expiry will not help you here, as the account for the person who has left (If their account is still active) will still have their old password set.
The fix here is to make sure your JML process isn’t bad! Have a document process in place for the return of all your hardware and disable all their accounts by the next day. You should setup alerting for this where possible.
As an alternative, just set an automatic “lock out account of 90 days of inactivity”. This slightly increases your window of exposure, but only by up to 90 days.
What you should be doing instead:
Logging and some kind of monitoring/alerting and user behaviour analysis. An Appliance or tools on their aren’t good enough, you’ll need some good people to watch/use the tools!
Some kind of decent password manager system rolled out company wide.
Setup an internal password strength checker like zxcvbn and gamify setting a strong password.
Don’t scapegoat your users when they get phished or disclose passwords. Doing so discourages them from coming forward when they screw up or something goes wrong and you won’t find out until it’s too late.
Change passwords/credentials if you suspect or have confirmed any kind of breach involving credentials. However, make sure you’ve confirmed that you’ve cleaned up the avenue of attack/credential leakage before you do this.
Sign up for a domain wide (Or just your own personal address) alert for dumps involving your companies email addresses at Have I been pwned Users will use their work email addresses to sign up for crap they have to download as part of their jobs. (The adobe dump is a good example!)
Thanks to @TCFoxtaur, #kiwicon and a few other peeps on the twitters.
https://www.computer.org/csdl/proceedings/afips/1977/5085/00/50850027.pdf 1977. Obviously a whole lot of this no longer applies.
http://csrc.nist.gov/publications/history/ande72.pdf from 1972.
https://www.schneier.com/blog/archives/2010/11/changing_passwo.html https://docs.google.com/viewer?url=http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNoThanks.pdf http://cs.unc.edu/~fabian/papers/PasswordExpire.pdf https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf (password lifetimes chapter, page 572+)
https://www.cl.cam.ac.uk/~rja14/shb10/angela2.pdf http://healthitsecurity.com/2012/12/04/cio-addresses-password-change-frequency-security-innovation/ http://community.hcca-info.org/hcca/communities/community-home/digestviewer/viewthread?GroupId=121&MID=25599 http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf https://www.sans.org/reading-room/whitepapers/basics/password-security-thirty-five-years-35592 https://www.cerias.purdue.edu/site/blog/post/password-change-myths