Should Companies Abandon Their Password Expiration Policies? (techcrunch.com) 132
In his TechCrunch column, software engineer/journalist Jon Evans writes that last month "marked a victory for sanity and pragmatism over irrational paranoia."
I'm talking about Microsoft finally -- finally! but credit to them for doing this nonetheless! -- removing the password expiration policies from their Windows 10 security baseline... Many enterprise-scale organizations (including TechCrunch's owner Verizon) require their users to change their passwords regularly. This is a spectacularly counterproductive policy.
To quote Microsoft: "Recent scientific research calls into question the value of many long-standing password-security practices such as password expiration policies, and points instead to better alternatives... If a password is never stolen, there's no need to expire it. And if you have evidence that a password has been stolen, you would presumably act immediately rather than wait for expiration to fix the problem... If an organization has successfully implemented banned-password lists, multi-factor authentication, detection of password-guessing attacks, and detection of anomalous logon attempts, do they need any periodic password expiration? And if they haven't implemented modern mitigations, how much protection will they really gain from password expiration...?"
Perfect security doesn't exist. World-class security is hard. But decent security is generally quite accessible, if you faithfully follow some basic rules. In order to do so, it's best to keep those rules to a minimum, and get rid of the ones that don't make sense. Password expiration is one of those. Goodbye to it, and good riddance.
Instead the column recommends password managing software to avoid password re-use across sites, as well as two-factor authentication. "And please, if you work with code or data repositories, stop checking your passwords and API keys into your repos."
But if your company still has a password expiration policy, he suggests mailing Microsoft's blog post to your sys-admin. "They will ignore you at first, of course, because that's what enterprise administrators do, and because information security (like transportation security) is too often an irrational one-way ratchet because our culture of fear incentivizes security theater rather than actual security -- but they may grudgingly begin to accept that the world has moved on."
To quote Microsoft: "Recent scientific research calls into question the value of many long-standing password-security practices such as password expiration policies, and points instead to better alternatives... If a password is never stolen, there's no need to expire it. And if you have evidence that a password has been stolen, you would presumably act immediately rather than wait for expiration to fix the problem... If an organization has successfully implemented banned-password lists, multi-factor authentication, detection of password-guessing attacks, and detection of anomalous logon attempts, do they need any periodic password expiration? And if they haven't implemented modern mitigations, how much protection will they really gain from password expiration...?"
Perfect security doesn't exist. World-class security is hard. But decent security is generally quite accessible, if you faithfully follow some basic rules. In order to do so, it's best to keep those rules to a minimum, and get rid of the ones that don't make sense. Password expiration is one of those. Goodbye to it, and good riddance.
Instead the column recommends password managing software to avoid password re-use across sites, as well as two-factor authentication. "And please, if you work with code or data repositories, stop checking your passwords and API keys into your repos."
But if your company still has a password expiration policy, he suggests mailing Microsoft's blog post to your sys-admin. "They will ignore you at first, of course, because that's what enterprise administrators do, and because information security (like transportation security) is too often an irrational one-way ratchet because our culture of fear incentivizes security theater rather than actual security -- but they may grudgingly begin to accept that the world has moved on."
Yes (Score:5, Informative)
Next question.
It isn't IT that I must convince. (Score:5, Interesting)
Our clients, and especially our potential clients, audit us. They don't just audit our products, they audit our business practices. They must, because they know quite well that if one of their software vendors has weak security and gets hacked, the hacker can use that to harm them, and they are the ones left holding the bag.
They ask us questions about things like our password management policies, and insist that we use strong practices. Until THEY accept that the mandatory password rotation is a stupid policy, WE will have to continue putting up with it.
I had this conversation with the CEO, in fact, long ago. About how our password policies were so onerous that it was forcing people to do things that weaken security (such as writing passwords down, keeping a list of them in files on their hard drives, etc.). He explained that his hands were tied by client requirements.
Oh well, my password will be expiring soon. Time to increment the number at the end of it by one, just like everybody else does.
Re: (Score:3)
Re: (Score:2)
Just change your password 10 times in a row so you can keep using your original password. I've had the same password for years now despite monthly nagging.
Re: (Score:2)
Re: (Score:2)
Federal standards changed two years ago (Score:5, Informative)
Anyone doing any business with the federal government has to comply with NIST standards. As of mid 2017, the federal mandate is that you do not expire passwords. You force a password change ONLY of you have reason to believe thr password may have been compromised.
https://pages.nist.gov/800-63-... [nist.gov]
Also, it is NOT recommended to tell the bad guys that passwords start with a capital letter and end in with a number followed by one of three punctuation characters. That's what happens when you have a policy of "must have uppercase, lowercase, a number, and punctuation". Most of the passwords end up fitting this template:
Abbbbbb1?
So don't have a policy requiring certain types of characters. Instead, require passphrases be long. 14 characters is strong. NIST allows an 8-character minimum. Also, use MFA.
* Tangent *
What *should* change are session encryption keys. Protocols such as TLS use the long-lived keys only to encrypt a random key generated for a given session.
Re: (Score:1)
Totally. But how come it taken so long to work this out? At my first proper IT job in 1990 we had a sysadmin who was a password nazi, you needed a complex non dictionary password with no matching history which had to change every month. Day one on the job and I saw the password for about 100 of the 200 machines I supported on a sticky note in plain sight. Desktops for everyone was new at the time so I thought it was a teething issue that would last a year at most to iron out, but here we are 29 years la
Re: (Score:2)
BTW, if you know a foreign language like russian or chinese its easy to make complex passwords, can't think of a downside to that strategy....
I doubt that my bank would allow Cyrillic characters in the password.
Re: (Score:2)
Times are a changing. My own company (one of the top 50 in the Fortune list) recently changed it's policy to expire yearly instead of monthly for this very reason.
Re: It isn't IT that I must convince. (Score:1)
Re: (Score:2)
Just get rid of the password history preventing you from using a large number of old password.
The main issue with many companies is that they don't have a good method of detecting when an employment has ended.
Re:Yes (Score:5, Informative)
It's not that hard. SuperSecretWord01 in Jan, SuperSecretWord02 in Feb, SuperSecretWord03 in Mar, and so on works great for me.
Re: (Score:1)
"Your new password is too similar to a previous one. Please chose a different password."
I have had to use password systems which had such a check.
Re: This (Score:1)
This one is the most annoying for me, if they can compare anything other than salted hashes it suggests your old passphrases are reversible i.e. held as plaintext somewhere for comparison.
Re: (Score:3)
They can compare to the previous password as you typically need to enter your previous password when setting a new one... If they can compare any further back then its a problem.
Re: (Score:2)
They can compare to the previous password as you typically need to enter your previous password when setting a new one...
That in itself is a bit of a problem. Ideally you wouldn't send any passwords over the network; the average site operator can't be trusted to handle them securely. Instead a public-private key pair would be generated from the domain, username, and password locally on the client and used to complete a challenge-response authentication request. The server only needs to know the public part of the key to verify the signature.
Brute-forcing at Levenshtein distance 1 (Score:2)
For a password consisting of 16 ASCII printable characters, it takes 16 * (95 * 2 + 1) = 3056 runs of the password hashing function to test your new password with one character added, replaced, or deleted against a previous password hash. If the system saves your previous 24 password hashes, this totals 73,344 tests. Depending on the exact number of PBKDF2 iterations that the authentication system uses, this could prove practical, especially if it tries brute-forcing the last character of the last 3 passwor
Just store the old passwords (Score:2)
Then it is easy to ensure that the new ones are different.
I like to make things easy for my users. So I regularly email them a link which they can click, go to a website and then just enter their old and new passwords.
Let me know if you need help with any other security related questions.
Re: (Score:2)
Storing the old passwords fails if your database gets breached. Requiring entering the old password fails if the user is resetting his or her password.
Re: (Score:2)
Because the administrator requires I change it and I require that I can remember my passwords without having to write them down.
Re: (Score:3)
Periodically changing the passwords don't correct this issue, as it would take just a few more tries to get in.
To me, the only accounts that could be advisable to change passwords regularly are the ones than can do some damage, lik
Re: (Score:2)
I'm on version 'b' of my current work password. Nobody will ever guess what my new one will be when I log back in on Monday, since we just ticked into the 3rd quarter and that means I need to change it.
Meanwhile I've had the same bank password for a decade.
What strikes me is that there doesn't really seem to be a middle ground. Either you have to change it every 30/60/90 days, or you don't ever have to change it. I probably should have changed my bank password sometime in the last decade. But it's a decent
That's f'ed up man (Score:3)
IT Enforce Thy Own Security (Score:2)
OK so I'm an end user and probably missing some important technical detail, but... it seems to me that instead of users having long hard to remember passwords that they have to change about the same time they actually start remembering them, can't IT to a better job of tracking failed password attempts? What I'm thinking is if repeated failed attempts occur with a certain pattern, one or two failed attempts followed immediately by a successful one is just the user fat fingering for example, then IT gets in
Re: (Score:2)
The problem is the management not IT.
Management will not approve of neither the resources or expenditure to allow IT to do it's own damn job the majority of the time. You might feel bad as a user getting shitty service from IT but remember, we enjoy being able to help our users we just get into trouble if we help you too much. Yes, we like to pick on users from time to time but the decent ones among us know that without you needing help many of our jobs would be non-existent.
90% of the problem in IT begin
Re: (Score:2)
There are already throttles and lockouts employed by many IT organizations when attack behavior is detected.
Problem is, this becomes a denial of service vector. An attacker can really screw up an organization by triggering account lockouts.
The answer has to be more machine-generated and curated credentials. When combined with current best practices, you could allow an attacker unlimited guesses and it won't matter.
Re: (Score:2)
As an old "IT" manager, I believe that IT department must stay as away as possible from users' daily mistakes, like mistyped passwords.
What most IT departments and their ISO 2700x, ITIL or other fancily named standards consultants fail to understand is that passwords do not protect against the most important vector att
Re: (Score:2)
What does plugging a USB device into an MS box do that it can't do on another system? Does Linux have super-secure keyboard drivers that detect bad actors and prevent them from logging in?
Re: IT Enforce Thy Own Security (Score:1)
Re: IT Enforce Thy Own Security (Score:2)
There's a 1000x chance that the desktop will be Windows, that's true. There have been plenty of Linux USB security holes too however. Luckily hardly anyone uses it as a desktop so exploits are rare.
Re: IT Enforce Thy Own Security (Score:1)
Re: IT Enforce Thy Own Security (Score:2)
You are absolutely correct. If I stick a USB stick into a Windows machine it will be 100% a Windows machine and 0% a Linux machine. I'm not quite sure what your point is though.
Re: IT Enforce Thy Own Security (Score:1)
Re: IT Enforce Thy Own Security (Score:1)
Re: IT Enforce Thy Own Security (Score:2)
The bugs are not rare but the amount of effort required to write an exploit for the tiny amount of Linux desktops isn't really worth it.
Re: IT Enforce Thy Own Security (Score:1)
Re: IT Enforce Thy Own Security (Score:2)
Learn to read what? Linux's presence on the desktop is very small. That's a fact, whether your religion allows you to admit it or not. Multiple USB vulnerabilities have been found in both Windows and Linux over the years and if Linux had a significant presence on the desktop then there would be exploits for them.
Re: IT Enforce Thy Own Security (Score:1)
Re: IT Enforce Thy Own Security (Score:2)
What is Linux's presence on the desktop and why do you think that there are zero USB exploits for it?
Re: IT Enforce Thy Own Security (Score:1)
Re: IT Enforce Thy Own Security (Score:2)
How many of these bugs do you think would've been exploited had Linux got more than a minuscule presence on the desktop? https://nakedsecurity.sophos.c... [sophos.com]
Re: IT Enforce Thy Own Security (Score:1)
Re: IT Enforce Thy Own Security (Score:2)
Re: (Score:2)
It's a paradox.
The people most likely to be running desktop Linux are the ones least likely to double click on "Q4 Salary Targets.xlsx.vbs"
Re: (Score:3)
That used to work fairly well. Now, the attempts are well spread out. The bad guy gives his password guesser tens of thousands of accounts to work on. The guesser works very slowly, sometimes just a guess or two a day per server. Due to the large number of accounts to guess, they still get a steady stream of successes.
Re: (Score:2)
The issue is someone getting hold of the password hashes. They can then try and find the passwords offline.
As regards disabling accounts for failed logins, let me just DoS your organization. That said I limit the number of new connection attempts on port 22, to slow the script kiddies right down.
Yes (Score:2)
Re: (Score:2)
SOX does not actually require that. But like all other things moronic in the world the auditors made up that rule because no matter how much of a professional you are... you are still very susceptible to the Dunning-Kruger effect and the 5 universal laws of stupidity.
People instinctively know this... it is also one of the reasons so many people have a hard time dealing with or accepting things from the Science community. There are just as many with these problems on inside as there are on the outside.
BIG YES!!! (Score:4, Insightful)
Password change policies are mostly security theater and have been for a long time. What is even worse is that even when you can prove they are bad they still can't get away from them because people resist change like this.
Most people are just more comfortable with the evil they know.
Re: (Score:2)
What is even worse is that even when you can prove they are bad they still can't get away from them because people resist change like this.
Most definitely. Reminds me how, for a long while, doctors resisted washing their hands between patients. Change is hard for some people. (Curiously, more recently, my doctor used hand sanitizer twice during my visit and he only touched his stethoscope, when he didn't have his hands on his lap.)
Re: (Score:2)
I've seen a few sites that prevent you pasting your password in which is ludicrous. I've no idea what the security thinking is behind this but it's really easy to remove the event listener that prevents it via dev tools on Chrome (or any other browser).
Re: (Score:2)
I imagine there will be a browser plugin for this too, disabling cut+paste is extremely annoying.
Re: One of the many stupid policies (Score:2)
What is a real browser, oh wise one?
After staying for a few years... (Score:4, Funny)
Re: (Score:2)
I suspect a lot of people respond that way to obnoxious password policies.
The whole capital / number / symbol thing is terrible. Combined with requirements for regular updates, it means passwords are near impossible to remember, so people either write them down, or use patterns.
Sometimes I suspect the rules are there to let companies blame the employees where there is a breach, not to prevent one.
Re: (Score:3)
As that one XKCD rightly said, we've spent two decades training people to use passwords that are hard to remember but easy to crack.
Re: (Score:2)
The rules are there because at some point someone published documentation saying it was a good idea, and it's spread from there with noone ever questioning it.
Re: (Score:2)
I worked at one place for quite a few years. When I left, my password was Totally_secure_password_$39. Because an uppercase letter and a special character were required. And there were 38 password resets.
To be fair, you could have omitted the underscores if only one special character was required.
Re: (Score:2)
It's not about security. It's about conditioning. One of the root reasons why public schools were setup like little education factories is because those were the types of jobs most were expected to fulfill when they graduated, plus and this is a BIG plus parents got free baby sitting for most of their work days. There is a reason why people need 2 decades of education to be considered useful by business these days. 1 decade of school is all anyone should require to be anything, Doctor, Lawyer, or Scien
Internal websites & basic auth (Score:2)
Will be happy to see password expiration policies expire, but I would also like to see companies not use basic authentication for internal sites. A better solution is some form of single-sign-on. I mention this because any internal website operator can grab your auth password. Better to see a single secure server being the only place of risk.
Updated your password (Score:2)
I don't like forgetting my passwords. The more software you use, the more accounts you have and the more passwords you're required to member. In practice, forgetting my password and getting locked out of something has been a bigger threat to my productivity than having a weak or reused password. I try to make passwords as easy as possible at reset time. I glance around my desk or office and see what...might...be... Ah, my printer is a HP Envy 4500. New password: Envy4500.
I hate resetting shit. I und
Yes, about 10 years ago (Score:2)
Because at that time it was not only clear to anybody with a clue that they are broken, there was also ample research on the topic.
While we're at it (Score:2)
Please don't make me go through extra authentication just because I upgraded my browser from version X.01 to X.012
If you think you need expiring passwords (Score:2)
I'll add another aggravating situation I encountered. A site's password d
Password expiration is obsolete (Score:5, Insightful)
It's obsolete because it protects against an obsolete class of attacks. It originated back when cracking encrypted passwords was feasible but took time, the idea being to make it so by the time a thief had cracked your password it'd expired and been changed. Things are different now. The encryption algorithms are either infeasible to crack or can be cracked in minutes-to-hours, not much middle ground, and almost all attacks aim to bypass having to crack an encrypted password by either using a vulnerability that doesn't require knowing the password or tricking the user into giving the attacker the password. Password expiration doesn't protect against any of those attacks.
And "Well, it doesn't hurt either." isn't a defense, because password expiration does hurt security. The ideal password today can be described as "N random UTF-8 characters" where N is some number in the mid-teens or higher. When the user can't use a password manager for copy-and-paste of the password, as with the Windows logon process, passwords approaching that while still being minimally usable by humans are all but impossible to remember without long-term practice at typing them to commit them to muscle memory. Password expiration guarantees I can't commit them to muscle memory which means I have to drop back to much weaker and less-secure but easier to remember and type passwords, making it more likely those passwords fall into the "crackable in minutes-to-hours" category.
Drop password expiration and replace it with support for 2FA. It'll make it easier for your users and improve your actual security in the process.
Re: (Score:2)
You stopped short in your realization and didn't get as far as 2FA. Sure Julie can give Sharon her password. It won't let Sharon log in, because after the password the system asks Sharon for her 2FA code. Sharon doesn't have Julie's 2FA secret so she can't provide the code. Sharon's attempt to log in fails.
And being paranoid, the system logs not only authentication failures (both password and 2FA) but incomplete login attempts (ones where the password was entered but the 2FA code wasn't). The system also lo
Yes, 2FA, but... (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes /thread (Score:2)
Microsoft have been recommending some very sensible and well thought-out guidelines around passwords for quite some time now.
Microsoft Research published a white paper back in May 2016 that recommended, among other things, to not use password expiration policies any more as the threat model has evolved.
I've presented this white paper to a number of organisational representatives and it's made exactly zero difference to them:
https://www.microsoft.com/en-u... [microsoft.com]
I do use these recommendations for my clients howev
I'm not as worried about passwords being stolen (Score:2)
So - centralized on a single password? (Score:2)
Instead the column recommends password managing software to avoid password re-use across sites, as well as two-factor authentication. "And please, if you work with code or data repositories, stop checking your passwords and API keys into your repos."
So that way if you get my password manager's password, you have everything. Worst case in the "non manager" approach is I use the same password everywhere - and you learn that (it's about the same thing). if I use two or 3 variations, then I'd be considerably better off - safer - than using a password manager.
Yes, but... (Score:2)
...Let's us not forget, changing your password every so often is still a GOOD IDEA.
Especially passwords that access critical systems. These definitely should be changed periodically.
It's just smart security practices.
But end-users forced into doing it on a strict schedule? Not even a security-paranoid goon like me likes this sort of thing. I'll change my password when I'm good and ready.
Besides, forced password change definitely results in poor password selection. So yes, get rid of the forced, but don'
Incentives (Score:2)
And the employee who actually, in good faith, tries to come up with unique passwords on a regular basis, get caught with the stupid lock out the user on three bad password attempts. It takes two or three tries to be sure it's not a typo issue only then do you realize you're using the wrong one out of the 37 or however many passwords you have to keep.
Wells Fargo assholes should (Score:3)
Not only do I have to go to two different web sites to pay my bill (one for a summary, the other to actually pay it), but I have to change my password every 60 days,... WTF? They also keep track of every password I've ever used.
"told ya" (Score:2)
>"Should Companies Abandon Their Password Expiration Policies?"
We have NEVER expired passwords at work. 30+ years now. I knew then, and all along, and now, that it was/is a stupid concept, so I refused to implement it. All it does is encourage users to choose weak/supid passwords, share passwords among different systems, and write them down. 99% of users forced to change passwords add a number to the end that they increment +1 each time. That is, unless the system is smart enough to prevent that....
What about audits and compliance? (Score:2)
I'm on board but I really do wonder about dealing with auditors and industries that have to comply with the likes of PCI, SOX, etc.
In my experience, auditors are not always the most knowledgeable and merely collect responses. Management's fear of failing an audit could drag out adoption. Ideally the auditing organizations should provide clear guidance on new strategies.
I'm lucky (Score:1)
Github practical advice request (Score:2)
I have a small Arduino project on GitHub that requires a WiFi SSID and Password be hardcoded in the source.
I'm using the Arduino IDE and GitHub Desktop on Windows. How do I fix it so I don't have to go manually edit out my SSID/Password before I push that to a git repo?
Just last night my credit card company (Score:2)
I guess it's off to HaveIBeenPwned to see if someth
Diceware (Score:1)
Re: (Score:3)