In the b2b world it's basically impossible to improve password policies. Most of the onerous examples only exist because some other entity (a customer, insurance company, parent company, etc) has demanded them. The problem is that the demand isn't being made by security professionals, it's being made by risk management people who are only interested in a simple way to mitigate risk - it's simply much easier for them to reach for an obvious and easily testable policy with character counts, expiry, no autocomplete, etc.
Even if you manage to convince one of them to accept something a little more forward-thinking and less user-hostile, it's only a matter of time before Big Customer X comes along with their antiquated requirements and you have to choose between doing what they want or losing that business.
We had a credit reporting agency (big US one, suffered a large data breach a few years ago) try and insist that we require password expiration for our employees.
After pointing to the NIST standards (and two other references) saying that that reduced security and saying "we're not prepared to reduce our security" they backed off.
> After pointing to the NIST standards (and two other references) saying that that reduced security and saying "we're not prepared to reduce our security"...
Tip for those in settings with compliance reviews and cybersecurity insurance: get your PCI DSS, SOX, and other auditors, and cybersecurity insurance underwriter on board with these standards as well, with written statements. Then if Big Customer Co. pushes back after you say, "we're not prepared to reduce our security", ask them in a friendly way to hold an N-way meeting between their auditors and insurance underwriter, and your auditors and insurance underwriter.
This gets them to switch off their demand. Every. Time. If they don't back off on their own, their auditors and/or insurance underwriter makes them back off. I've yet to have such a Big Customer Co. push it to the point of asking more than one of their own auditors, though. Usually it is someone not in auditing and insurance underwriting blithely following outdated policies written in the Stone Age that still need updating, and most are grateful for the updated clarification.
You have to get out ahead of the business risk though for this to work: you need to properly socialize the delay this puts on the deal "while auditors and insurers sort out the risk". This is where soft skills shine.
This approach will also take care of the response user patrakov gave ("NIST is an American institute, and we are a Japanese company, we have our own standards that differ, and must follow them"), once it gets to the insurance underwriters talking it over on how to divvy up the risk and amend their policies if necessary.
The only PCI DSS requirement I couldn’t quickly align to NIST and others has been the 90 day expiration. My go-to has been to convince the insurance underwriters first of the primacy of SANS, NIST, Microsoft and so on. Then put them in a locked cage match with the PCI DSS auditors and accept the result when they walk out. PCI DSS auditors can’t accept liability shifting onto them, and cybersecurity insurance underwriters are getting more savvy on current standards and can often twist auditor arms enough to carve out exceptions and still obtain the audit certification.
It’s still messy at this time, but if it is important enough to you, then sometimes it can be obtained. Most of my clients aren’t that doctrinaire over the expiration part though and are still comfortable making everyone change every 90 days, and with some enterprises they don’t care because they have FIDO2/U2F or similar authN infrastructures and corresponding authZ improvements on their roadmaps within the next 3-5 years anyways that do away with most passwords in their environments.
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Sure! I used NIST[0] (which has already been posted here), along with Microsoft[1] and the UK National Cyber Security Centre[2] (we're in the UK as well as the US).
For context, I remember the contract first came back, and we redlined it saying we're not gonna do password expiration and explained why. It then came back with another draft and they said "no, this is our policy, you definitely need to do password expiration" so I threw these references together and expanded my explanation. It was a bunch of business/lawyer types, so I threw microsoft in there as I assume they're better known to non-technical people and the other two references are obviously more salient to technical people.
As a side-note I think this was _after_ they had their very well publicized security breach, and I would have hoped that they had taken a look at their security and updated their policies but I guess that wasn't the case. I don't know whether they ended up removing it from their contracts going forward or just made an exception for our one. The cynical part of me says the latter (it's a big firm, and we're not a particularly big one) but I can hope.
I also recently read an audit for another third party we were evaluating to work with. I raised it as a non-blocking concern saying they're not following modern password standards, and I think if everyone does that these companies will start to update their policies but for now it's fairly common at least in my industry.
[EDIT] I went looking for what I actually said to them, and it was "as per UK/US government and Microsoft password guidelines, we will not agree to this, and would prefer if you didn't do it as well.". So I guess I was a bit exasperated with them at the time :)
This is likely the best way to deal with the inertia exerted by antiquated requirements: Most (keyword being 'most') businesses tend to follow the rules laid out by authorities, so an appeal to authority works in this regard.
Agreed, huge thanks to NIST for the sane password policy recommendations. While it is still an uphill fight to bring sanity into this mess, being able to quote NIST and say we're following their recommendation has been very helpful.
The appendix, “Strength of Memorized Secrets” is informative rather than a guideline, but I would recommend quoting it too in such discussions:
> composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought… although the impact on usability and memorability is severe
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).
There’s other great stuff in there as well like that you should allow users to “paste” passwords and potential passwords should be checked against a list of known bad ones.
Expiring passwords are the bane of my existence. My current job does that. It was originally a requirement by Microsoft and they've been recommending against it, but it catches up slowly.
Expiring passwords are the bane of my existence when the period is short. I can live with changing a password once a year, but every three months is only encouraging me to pick weak passwords.
Why can I accept it? I constantly see colleagues sharing passwords and constantly have to say "please don't" when they try to share their password with me. While forcing people to change their passwords doesn't eliminate the underlying problem, it does limit the scope of the damage.
My old man's work used to make them change their passwords once a month.
For the next 10 years, his password was a particular insulting phrase directed at the IT guys, followed by a number that would increment each time he had to change it. Got into the hundreds before he left the company.
I had a coworker that would type in something random as his new password, then immediately fail to login three times in a row so his account would get locked. To fix this the sysadmin would reset the password, and allow you to choose a new password... and on the no-repeated-passwords policy did not apply to the magical reset dialog. So he would then reset it to his old password.
I was doing the same at one point, albeit it only lasted 5 years before I changed employers. Didnt even had to rotate the numbers, I could always come up with new and colorful insults for the nameless IT group. Which ironically I remember perfectly.
Changing the password opens it to compromise when it's being changed. Capture of that account is possible and easy at that point.
It also interferes with password managers and secure keys.
Opens a phishing vector. Generally I could enumerate how bad it is and run out of ink here. (And it's a screen.)
My former company required not to use one of the last 10 passwords. So every 3 months, employees did the 11-password dance, setting the password back to the original one.
I know passphrases are better. But, the problem is there's much more to type every time you want to unlock your computer. And thus also many more chances to make a typo.
Of course there's TouchID and Windows hello but they don't work if your laptop is closed in a dock. Or in my case a Mac mini at home.
This is why I still stick to the truly random sorry password, I have no issues remembering arbitrary strings for some reason :)
Typing a passphrase is so much easier. You already have muscle memory for typing English (or whatever your first language) words. I can type probably type a 60 character passphrase consisting of real words at least as quickly as than I can type a 15 character password with special characters, if not faster.
For you maybe, not for me. I'm pretty good with arbitary strings. And I'd only use specials that don't require shift :) It's really much faster and I have RSI so I don't want to type too much.
Luckily my work still allows 10-char with specials or passphrases of 16 and longer without. And don't forget passphrases only benefit in very specific situations such as hash brute forcing. Online attacks already block after a handful of attempts.
Also, the incessant screen locking really annoys me, every time I step away for a coffee my PC is locked again, and this is also at home where my environment is completely secure and I'm the only one living there. I actually work in security but sometimes there is just no reason and it becomes just a barrier.
In the past I used an app to jiggle the mouse every once in a while but that doesn't work anymore. I now made a digispark that does the same in hardware. :) I only use it at home though and it auto-locks my desktop when I leave the house (all my personal ones do too)
If they'd just allow us to use our yubikey + pin it would be so much easier and more secure...
I type my arbitrary 12 character password for my laptop as quickly as I’d type two 6 letter common words, due to muscle memory, as I don’t have to change it every few months.
In all serious, my point is roughly that typing Sp3c1al_(h4racTer_p@ssw0rd$ is like O(n) whereas typing passphrases is like O(log n). Once you hit a certain length, pass phrases start pulling ahead in ease-of-use.
We're already constantly maintaining muscle memory just by typing normal words every day. With muscle memory for special character passwords, you have to start over from scratch every time you have to change one.
In other words, imagine I flipped over a flashcard with a new passphrase on it consisting of lowercase English words, and asked you to type it. Now imagine I flip over a flashcard with a new, special character password. How many more times do you think you'd have to reference the flashcard with the special character password while typing it out and developing the muscle memory over the flashcard with the passphrase?
Windows allows you to use a PIN for regular device logon - so you have a longer, more secure password for general use of the account, but an eg 8 digit numeric PIN _only_ for that device.
> Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Across the pond, there is also the NCSC password guidance. It's better than linking to some obscure paragraph in a standards document; it's written in plain English, aimed at the layman, and explains exactly why the old doctrines are bad:
I work for an insuretech startup and have been through a number of compliance gauntlets with large enterprise insurance companies. Appealing to NIST recommendations for why we don't auto-expire passwords every x days and don't require anything more complicated than at least 10 characters has worked on every occasion.
The topic of "what should we do about our password policies" sometimes comes up with our customers as well. Pointing to NIST and if pressed giving my opinions on good passwords and the use of 2FA (which is largely paraphrasing NIST recommendations anyway) made every customer happy so far :)
B2B is worse because EVERYONE shares business accounts with other people at the business. And so the usernames passwords and even two factor setups are passed around like coffee.
“Oh use bobs login for that, the standard password but add a ! for reasons”
We setup bitwarden at work, and it was absolutely fantastic for these sorts o shared accounts. You could have all the password be telling random strings, and control who had access to them with a convenient UI. Password rotation became a lot easier too, because all you had to do was update the password in the password manager and everyone would have the new one.
I hadn't realised how many of these logins we had.
The request for a company-recommended password manager came from every department except IT, I think because the companys IT deal with are generally better at supporting multiple accounts.
I was in charge of password policy for a healthcare app. We tried to use phrases, often cited as more secure than character/length requirements.
The doctors hated it. They didn't understand what a phrase was, it was too different from every other system they interacted with, and it was extra cog load in their already busy days.
> it was too different from every other system they interacted with
Translation: they couldn't use the same standard password they use for their banking, their email (also used for 2fa), Facebook, and this porn site they found by clicking on a pop-up ad.
Why not just have a length requirement and recommend a phrase? “Passphrase” isn’t that common a word, so it merits an explanation. But “your password has to be long, but you don’t need to use special characters, and can use regular english word if you want” is surely easy enough to understand.
My company requires us to change our password every 90 days due to such externally imposed demands so mine ends in two digits which have been counting up for almost ten years now.
It’s much easier than ever before. You centralize identity to an IDP and require SAML or OAuth for applications.
Then you manage it once. Typically you can get rid of most of the password bullshit by adding MFA, with some exceptions. Unless you’re a DoD contractor or handling taxpayer data the came from the IRS on behalf of a client, MFA should meet or exceed compliance requirements.
I’m a small company and the problem with SAML is that it requires the “enterprise” plan for each app. Slack goes from 0 to $11.75/month/user, Miro goes from $8 to $16. Then you have to pay for Okta (Isn’t it $15/u/m?) For a 5-person business it’s $1185 difference + $900 for Okta, and that doesn’t make me SOC2 compliant (There is a bunch of other requirements, secure access to physical offices, logs, etc.).
Usually it makes sense to use Google or Microsoft as an IDP vs Okta.
Totally hear you re the cost, it depends on the risks you face. I’m in a bigger enterprise, but for me, no SSO, it is out in 95% of situations. In the exceptions we have, we require vaulted passwords.
A breach would put me out of business, and identity is a key security control for many risks.
Some customers require that your employees have to comply with their password requirements. Using an IdP means there is just one password to worry about, but you still might have to periodically change your password because some big customer has it in their contract.
And then there are customers who have requirements about passwords, even though they are only going to be using an IDP anyway. It is probably because they have the same standard list of requirements that they give to everyone, and probably was copied from somewhere else, and you can usually contest it. But it is still a waste of time for everyone.
> The problem is that the demand isn't being made by security professionals, it's being made by risk management people
I'm actually not sure how true this is. There is a huge "security checklist" industry backed by persons with some fancy Security title that provide security analysis checklists for companies to follow, often citing very interesting interpretations of best practices from actual security orgs. These checklists are pushed on regulators who likely lack any ability to assess the validity of such requirements, rubber stamp the checklists into regulations, and now you have a series of unenforceable or ridiculous security policies and practices that basically serve to frustrate the user while failing to prevent actual attacks.
I've been at companies where there were rather interesting policies like
- Three factor authentication (because a single method isn't enough for some reason)
- No password managers allowed (how this is enforced is completely unknown)
- 6 week password lifetime
- Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious)
- Random character requirements/limitations (you must use non-letter characters from set X, but not from set Y, and absolutely only latin letters)
And those are just some of the bangers surrounding password policies; the less said about the network security policies and antivirus policies the better.
And these requirements don't come from some regulation/risk assessment group; they're enforced by such groups, but the actual requirements come from some security firm that sell lists and a stamp of approval once you have every box checked.
It's difficult to not look at such firms as swindlers with a guaranteed paycheck from a captive audience; they sell their services to regulators as a benchmark to meet, and then in turn they sell implementation services to companies that are forced to meet said regulations.
And the end result is just extremely frustrated users who still end up falling for "Hey Bob check this out" phishing emails which is plenty for an attacker to get in and jump around your network until they compromise enough of the environment to take the business down. But hey! The business followed the checklist, so they can't be held liable for exfiltrated data!
> Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious)
Most systems that allow you to change your password require the current password as a verification. This means the software performing the validation of the new password also has access to your old password and could perform a comparison of the two to see how many characters differ or the overall edit distance.
If only the new password is available, it’s still possible to perform this analysis against older password hashes by simply manipulating the new password and checking if it validates against the old hashes. Possible transformations are replacing any numbers with other digits, e.g. “foobar2” would check “foobar1” through “foobar9”.
If the system asks for the old password before allowing the user to enter a new password, it could then simply save the old password in plaintext, so that the saved password can be used for similarity checks in the future. In the same way, the system could easily store e.g. 10 previous passwords in plaintext.
It's not that easy, normally having function have a big avalanche factor - even one bit changes the whole hash. There are some malleable having algorithms but they're necessarily less secure.
If you're sending multiple hashes to check nobody is stopping the user from sending garbage, except their lack of JS/browser skill.
If you're sending the plaintext password, what are you doing using a hash? When your backend is compromised, attacker will just grab all the password when they're getting changed.
No, I think you misunderstood the post I responded to a bit.
In the case where the current password is captured on the password change, you have two plaintext values that aren't stored yet and you can just do some text analysis and understand how close they are.
With past passwords, you just take the current input and transform it with common transformations (adding numbers, incrementing/decrementing numbers, etc), hash it, and see if it matches a previous password hash. If so, then you know that they're using a very similar password pattern repeatedly.
> - Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious)
Same way you verify the current password: hash it and compare to what you have on file. If you use salted hashes and the salt changes, you'll have to keep enough of those around, too.
If they’re using some special hash algorithm that retains most of the information of the original password and allows them to determine that “password1” and “password2” are similar and “blahblah7” is not, their approach is hopelessly broken too.
Technically you could tokenize and dictionary plus edit distance check the password in the client if you have the plaintext, or use malleable hashing. Check entropy while at it. Of course that will not stop a determined policy ignorant.
Requiring a plaintext password storage somewhere is an instant regulatory fail in ISO 27002 and PCI DSS standard. You can technically store the passwords encrypted, but attacker is liable to steal your salt/key, and protecting the passwords in transit strictly requires strong PKI. We know users cannot determine that anyway and get phished/MITMed.
Plus it's kind of mean. If your users are determined to ignore your policy, maybe it's a bad policy or you need to tell them to stop doing that.
Checking for x latest passwords requires just storing their hashes.
Oh god! I made the same mistake. I thought you just meant password reuse. Past password similarity?
That's literally impossible without plaintext passwords isn't it. That is insane.
The hashing has to happen serverside, which means the server will temporarily have the plaintext in memory. While there, you can mutate the string by adding/removing/chanigng characters, to get a bunch of strings that are similar. Then you compare all of those to the old hashes you have stored. It will catch people doing common stuff like incrementing a number at the end on every reset.
> That's literally impossible without plaintext passwords
No, it’s not. It’s called locality-sensitive hashing. You’d store the last 10 LSH hashes in a database next to the SHA-256 hashes. Compare those LSH hashes to the LSH hash of the new password. Match? Reject the new password.
It’s also used to identify photos that are similar:
Surely even having an LSH stored is a potential compromise - e.g. if my password happens to have the same LSH as somebody else because I've used "Secret-123" and they've used "Secret123", then you've presumably got a better chance of guessing what my password is than if the LSHes weren't stored (if you can't get from me directly, you can try to get it from others who have the same LHS).
You’re assuming an attacker can access this database somehow? And that the LSH of “somebody else” is reversible? I’ve don’t understand the vulnerability you’re describing.
Yes, obviously, I'm just saying it's a potential vulnerability that doesn't exist if you don't store the LSH. The LSH doesn't need to be reversible - I'm just saying that you now have a situation where if you can find multiple people with the same LSH, if one their passwords becomes known to an attacker for any reason (the attacker could be one of those people!), the other passwords are now much easier to guess.
Hopefully the B2B at least makes the password rules configurable per customer. Big Customer X can have what they ask for without hurting all the other customers.
Even if you manage to convince one of them to accept something a little more forward-thinking and less user-hostile, it's only a matter of time before Big Customer X comes along with their antiquated requirements and you have to choose between doing what they want or losing that business.