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.
> There's no technical reason for restricting any character from appearing in any password. The usual approach for handling a password is:
> - encode with a specific, well-defined encoding (e.g. utf-8)
Heads up – this is not enough for reliable operation. The same character from an end-user’s perspective can be encoded in multiple ways in UTF-8. So they might register with one platform and then a while later log in with a different platform, and you might receive different string data for their password even though they typed the same thing in both cases.
You might want to consider following RFC 5198 which has more specific requirements, such as encoding to normalisation form C to eliminate issues like this:
Likewise the hex of a 128bit key is unbreakable but will fail almost every password policy becuse of repeated characters and lack of upper case/special characters.
Though for accentuated characters, I can think of some scenarios where it is not a good idea. Say your users may have to travel / use some terminals. If the keyboard doesn't have those characters, you locked them out of the system. That's why I think non ascii characters aren't a good idea. Also you make yourself more exposed to developers doing something silly like mixing string encoding between different interfaces.
That’s correct. It’s quite a detail in this case, though; this high level description tries to explain why you should never forbid some “special” chars.
Please note that it’s not the same char; it’s actually a different set of code points which happen to have the same representation.
> Or maybe the keyboard layout isn't yet set when the password is entered (example: full disk encryption password at boot) and you risk that a user is entering a password at install time, but what they write at boot is actually different.
This is a very good point, which already made me struggle when setting up new computers. For instance, the Ubuntu installer runs in a Gnome environment with my keyboard layout active. The disk encryption prompt runs shortly after the BIOS screen and will likely have some US keyboard layout. If you choose anything special for your password, you'll have a hard time figuring out how to type it in a different keyboard layout.
I work for a German company. You bet that I know to find most symbols on a German keyboard layout. Thankfully the base letters contain only one swap.
For extra fun, one colleague in particular likes to set excessively long passwords of like 50 characters when it is not expected that anyone will ever have to type them. The number of times I had to type one of these because this sysadmin works remotely and I'm the hands in the office when needed...
It's just another thing to remember to set. The keyboard layout CAN be set at boot (I do it), but it's separate from the keyboard layout in a graphical session.
There are only really two types of passwords: Passwords for online accounts and passwords used to encrypt things.
Imagine the password for my Gmail is Watermelon45. Theory says that's super weak, but I'm not a watermelon farmer and I wasn't born in 1945 so nobody who knows me is ever going to guess it. I trust Google will effectively block against brute force attacks by rate limiting login attempts, and if Google is breached and the password cracked as long as I'm not reusing it somewhere else it doesn't matter.
Now if I encrypt my portable SSD with the same password that is a problem. It would be trivial to brute force. So external storage, computer logins, ssh keys are perhaps examples of the very few situations where high entropy passwords are actually useful. For everything else which is 95% of passwords, easy to remember but unique is fine.
> Now if I encrypt my portable SSD with the same password that is a problem. It would be trivial to brute force.
Probably not so trivial. It's very likely (disclosure: I'd need to check, but I'd expect that to be true in 2022) that the actual encryption key of your storage is a randomly-generated key, which is then protected with your password and a very slow decryption algorithm, so that bruteforcing is not so fast. Still, single dictionary word + two ciphers won't be terribly hard to decrypt for a really interested party.
But the point is that such attack requires physical access to your device (unless some other network hack is performed), which is a kind of 2FA.
I have accepted that these sites aren’t going to change their ways. What I’d like though is direct integration with my password manager. Communicate whatever Byzantine password requirements you have via some standard hidden fields or meta tags so my password manager will generate only compliant passwords.
The article is correct, most password policies are dumb. But it's arguing about one tree while standing in a forest.
The real problem with passwords is not individual policies, but rather their shere volume. In my password manager I noticed I have got literally hundreds of the things.
Clearly reusing a password on multiple systems is bad. Clearly memorizing more than a handful is impossible. Since I therefore am using a password manager anyway, I simply get it to generate long, random, strings. Which inevitably contain enough to satisfy most daft policies.
There are some I still type. Basically the ones I use everyday, like machine login, but 99% are generated.
I get the article, and for those everyday passwords I advocate the same - make it long, make it easy to type, don't change it.
But if a Web-site wanted to be really secure, require a password manager. (how? I've no idea...)
> I really hope that passwordless login will make some steps forward in the next years
But, in the meantime I wouldn't despise passwords THAT much, if the policies were not stupid. Using any kind of SSO (e.g. login via Google or MS or Apple) puts multiple accounts under the umbrella of some internet giants; if at any time they revoke your account, you risk losing access to multiple other unrelated sites (not to mention the fact they'll know even more usage patterns).
Honestly I'm surprised we're still using user names and passwords for authentication and identification in 2022. We have come up with many better ways to do this, and just completely failed to adopt any of them as the new normal. The closest we get is when we can use Google or Facebook to log into Joe Blow's Bullshit site instead of a bespoke account.
Passkeys, which are getting closer and closer to prime time. If you think about it, key-based auth is already highly recommended and utilized in many scenarios (like SSH, signing data, certificates, token authentication for use between servers, etc.)… this just makes that accessible to users.
The vast majority of people don’t even use a password manager, and use variations of the same password everywhere. That’s really unsafe. Passkeys are always unique.
Another thing is phishing. The big issue with phishing is how easy it is to make a website or popup look identical to a different service. And if it’s believable enough and the domain is hidden, you’ll put in your real password. Passkeys fix that because they only work on the site in question. No danger of leaking it to someone else!
So this will make some huge improvements in security. Basically taking care of the very basic things most people don’t do. Password managers solve many of the same problems, but are potentially less convenient in some scenarios. (Obtuse password requirements, password field not working with paste, etc. it’s just a 3rd party workaround.)
But like you said, the social aspect is still a huge problem.
Passkeys aren't immune to phishing. And they are susceptible to being lost. I say that as someone with two.
Worse, they aren't accepted everywhere. And often places only let you have one registered. :(
So, yes, I agree that they are a solution. I don't know that I feel much safer using one, though. And, at large, I can see how they are not much different to passwords. Just ones that you can't speak others easily.
Are you sure you’re referring to passkeys like passkeys.dev? The new Web standard?
It builds upon WebAuthn and physical keys but is slightly different and on track to be supported by major platforms.
Sounds like you’re referring to something like YubiKey, it’s hard to lose device associated passkeys.
How would you phish it? The challenge response mechanism contains the requesting origin so it’s berry difficult to phish it out given up to date browser.
You are correct I meant yubikeys. I'll have to look a bit more at this new thing.
I confess right now it isn't impressing me. Is sounding too magical in a "it just works" way. With no real explanation of how.
It hurts that it sounds tied to a device. I stopped using some authenticator apps after I lost access to a ton of stuff when my phone broke.
As for phishing, this seems like a mitm would still work better than you'd expect. Folks get really good at ignoring warnings and such. Especially under duress.
For example, asymmetric key pairs. Give sites a public key and auth by signing something with your private key. You can use the same key on as many sites as you want, but you can also use different keys for different sites. No need for a third party even.
No it isn't, because unlike passwords you can reuse a key pair indefinitely without suffering any greater risk.
If we only ever had to remember a handful of passwords you would be right about them being easier, but we have hundreds of them which necessitates a password manager anyway which has all the same manageability problems of the asymmetric key pair without any of the benefits.
You still have to remember what it is that you signed. Unless you are saying it is a challenge/response thing. In which case you have to know what public key they have.
And if it is challenge/response, you need to have different public keys, or a compromised private key is complete game over, just like a shared password.
Thinking on it more, I'm not sure why I think auditing is harder. Is hard regardless, but I don't think this makes it tougher. If you are reusing public keys on N sites, it is now N places to check for use per key. Though, you always had N places to audit. They could be independent without reuse, but still not easy.
> You still have to remember what it is that you signed. Unless you are saying it is a challenge/response thing. In which case you have to know what public key they have.
You say that like it is a problem? Like I said, you could easily and securely get away with a single private key, so there isn't really any guesswork here. Certainly remembering usernames for hundreds of sites would be worse.
And if you want a different key pair for your porn, you can do that and it is on you to remember which one to use, same as usernames and passwords.
> a compromised private key is complete game over
Yeah, just like a compromised password manager is. Can't really do much about that.
Some countries solved it with physical security keys, now large vendors are pushing Passkeys. Both work for this purpose, albeit the first one also has an identity behind it.
If it is copiable, how would you know if it had been compromised?
My understanding is that backup keys should not be identical for that reason. Let's you revoke and audit use.
As such, having a backup has to be accessible so that you can register it places. There are tricks, but they only work in certain scenarios. Mostly not in the fido use cases.
So that the friend, or someone who steals from the friend can impersonate me?
Proving your identity when you lost your proof of identity is still an unsolved problem if you ask me. At least in general, it seems that there is no one solution that works for everyone.
Then you are going to know that the friend was messing with your hardware key. Better that than finding out they are willing to betray you by stealing from you.
An early version of TBBS didn't require usernames and the passwords had to be unique over all accounts. If you signed up for a new account and selected a password someone else already had, it would tell you so. You could then use that password to login as the other user. Obviously that wasn't very secure but probably was created with a small number of closely affiliated people using the system in mind.
Old password detection isn't necessarily a sign of weak security, if they are doing it right, they are just comparing a hash of the new password to saved previous password hashes. It is probably debatable if it is better security to not save old passwords hashes at all to perform this check, or to let users re-use old passwords that may have been disabled since they are known to have been cracked.
It can also be done securely if you have a flag that, when a password reset link is redeemed, the password must be reset in order to log in. There’s a couple of steps needed to make that happen cleanly (such modification should not be done on the GET of the password reset, but on a POST after the password reset link, prior to testing the passwords against old passwords and other security mechanisms).
yep, all true... this is a solved problem on how to do it right. The fact that the OP finds this interaction funny leads me to believe they don't understand how it can be done correctly, which is scary.
The point isn't that this is not secure. It's just that it isn't more secure, when it prevents setting the current, active password. An attacker could already just log in with that password.
Does it not let you log in with your old password after requesting a password change? That seems even more problematic, since anyone can request you password be changed.
would be a nicer UX if instead of "sorry" it was "great, your password hasn't changed as this was your old password. ps. you're now logged in, go do whatever you were hoping to do you rascal!"
It's not preventing you from changing it to the current password, it's preventing you from changing it to any of the previous N passwords where N is usually 3-10.
Depends on the reason the user could not login. If they really just forgot, then maybe that would nice UX... maybe. It could also be concerning to an unaware user that that somehow the site knew my old password (even though _we_ know they are just comparing hashes).
If the login was disabled due to the site knowing the hash of the old password appeared in a rainbow table somewhere, it would be a terrible idea to just let them use it again.
Unknown entropy - known entropy = password strength
Where "unknown" entropy is known only to the user and service and "known" entropy is any entropy known by a third party. Since this is an information problem, it should be treated with the tools of information theory, where security is measured by "unknown" entropy. Services have no way to know if a provided string is entropic, since it may be 100% "known" by others. The only way for a service to verify that a password is secure is for the password to include entropy provided by the service. If the user also wanted to validate entropy, it too could provide entropy for mixing in.
This is just a special case of Kolmogorov complexity, and the highest algorithmic entropy for this problem is a random number.
It's worth getting a list of the most common passwords and rejecting them, regardless of whether the passwords are generated by machine or by the user.
For four digit numbers there's barely any variation in what people use. Even 1234, the most common, is only twice as likely as hundreds of other PINs. Maybe block the top half a percent of most-guessed pins.
I recall a talk at passwordcon by Per Thorsheim where he pointed out that not only does the password: "Password2022" meet most "strict" criteria (three different character classes, longer than eight characters) - and -it's amenable to yearly demands for changing (increase the year) - but in large organizations you're actually very likely to find a user or two with this password (as seen in audits that ran simple brute force against the user directory).
PS: in the rare case it's not "secure" enough, add an exclamation point: "Password2022!"
I often get irritated by formulaic instructions for "strong" passwords when creating an account. I use a respectable password manager, so everything is unique and at least 10-15 characters with some numbers and symbols mixed in. Occasionally I use DiceWare. God forbid I don't include a number or use upper case, lower case, one of five symbols, but not th#t one! The worst is when I cannot copy and paste in both text fields. I don't even know what the assumption is there about end user behavior, but it's quite frustrating.
I know these practices must be reduced to the lowest common denominator, but perhaps websites need to allow minimum entropy and not force rules unless the minimum entropy isn't met. I don't know much about implementing, but people are so lazy that all these different rules and schemes are turn offs from better security practices.
Slightly related (funny, for me) thing I came across recently. I was looking into why some orgs prevent you from changing the Windows domain password if it has been changed less than 24h ago.
Turns out there's a reason for this: "Setting the number of days to 0 allows immediate password changes. This setting isn't recommended. Combining immediate password changes with password history allows someone to change a password repeatedly until the password history requirement is met and re-establish the original password again." [1]
For judging complexity I always thought large businesses should just set aside some compute to try to brute force passwords with the hash. If they get yours, you have to change it and get a talking to. If they can't get it, they give you $X where X is big enough to be a pleasant surprise.
> A short password is easy to bruteforce. But, a website should aim at password strength, not at password length.
If it is "easy to bruteforce" (guess without any prior knowledge), then it is not "strong".
> If I use four unicode code points outside the [multi-language characters table], my password is probably very safe already.
Security through obscurity. This is safe until everyone does it. It's not a strong password by virtue of being short, it's strong because this is impossible to input and so nobody uses it and so it doesn't make sense to guess. But you bet that if you ever log into a compromised system, use a phishing page, or a site stores and loses your password in plain text, the gig is up and it's known that cracking u/alanfranz's passwords is a matter of trying a few random unicode characters instead of letters.
> You cannot show or copy this field [...] My verdict: Security through obscurity
Security through obscurity is it being secure by being rare. It's not about it being literally invisible. I agree with the point but this is not what obscurity means.
Most of this post makes sense (password expiry, maximum length, requiring special symbols, disallowing other symbols) but we've known these things for decades now. We keep putting it in reports and customers are slowly catching up. Recently saw the first customer who, in a retest, used a reasonably sized deny list of common passwords on an embedded device! I was definitely impressed. We're getting there, ever so slowly.
> Security through obscurity. This is safe until everyone does it.
If he's actually randomly selecting from the entire set of valid Unicode characters, then theoretically his four character password has orders of magnitude more entropy than an eight character alphanumeric password.
The problem is that from the website's perspective there's no way to know what set of characters the user is choosing between. They could be dealing with someone who's picking truly at random, but more likely someone just thought they'd be cute and throw a few popular emoji at it. By just looking at a single password I can't tell the difference, so it's safer just to impose a minimum length requirement.
> If he's actually randomly selecting from the entire set of valid Unicode characters, then theoretically his four character password has orders of magnitude more entropy than an eight character alphanumeric password.
Exactly.
> but more likely someone just thought they'd be cute and throw a few popular emoji at it
The author's point is not that you should use a short unicode password, but that the key thing to focus on is password strength, not length. That is, use a lib that enforces password strength -- he is arguing -- instead of focusing on arbitrary and possibly wrong constraints such as "password too short". Strength is going to take care of it if it really is too short, anyway.
The author is also aware that we've known these things for a long time now -- he opens his article by complaining about this and how slow some websites and apps are at catching up, in fact.
So what's the proposal, switching to requiring a different length when a unicode character is present? How do you know from what set of possible values (like thousands of possible unicode chars versus a-z) the user chose each character?
While 68 bits entropy are secure in a case of good hashing, I think the statement is misleading. Anyone who uses a random generator will just use 16+ random alphanumerics (optionally with symbols) and call it a day; users aren't going to be able to input a unicode snowman with combination marker with orange skin on every keyboard without using the clipboard or other software. It's not more secure, it's just asking for trouble. A software tester can do this, but there is no practical reason to lower the length requirement to 4 characters because an ẍ might be entered.
The author doesn't end up proposing such a thing, but the argument in this paragraph still doesn't sound practical to me.
I think the argument, aimed at the people making the website/app (but not the login, which should be a third party), is that they should ditch ad-hoc and ill-advised password constraints and instead go with a well vetted third party lib that just measures password "strength".
A variant of "don't roll your own crypto (unless you work in the crypto space)".
> > If I use four unicode code points outside the [multi-language characters table], my password is probably very safe already.
> Security through obscurity. This is safe until everyone does it. It's not a strong password by virtue of being short, it's strong because this is impossible to input and so nobody uses it and so it doesn't make sense to guess. But you bet that if you ever log into a compromised system, use a phishing page, or a site stores and loses your password in plain text, the gig is up and it's known that cracking u/alanfranz's passwords is a matter of trying a few random unicode characters instead of letters.
This is plain wrong. The Basic Multilingual Plane consists of 65536 most commonly used codepoints. If your password contains a character outside of the BMP (e.g. an emoji), the attacker has to be bruteforcing over at least one other plane in addition to the BMP, which is 2*65536 characters = 17 bits of entropy per character. 4*17 = 68 bits of entropy is plenty. Even if everyone included an emoji in their passwords, this won't become any weaker.
Correct, but the recommendation in the article is still wrong. If I get a password that has four Unicode characters in it, it's possible that it's a strong password that chose truly randomly from the available Unicode characters, but it's much more likely that someone just picked four that they like. In the latter case, the bits per character is going to be much lower, but I can't tell the difference just looking at the password.
The only good solution I can think of is to assume low bits per character and require a minimum password length.
> but it's much more likely that someone just picked four that they like
Or as I would call it, the fallacy of uniformity. The author assumes that hackers would only try a dictionary attack using lower case letters, but this is no longer true since mid-2010s. Some dictionaries geared for international services also have non-Latin characters since not all countries restrict passwords to alphanumerics.
The same problem can happen with eight-char passwords. I could pick the same eight chars I like all the time and reuse passwords. You cannot fix password reuse that way.
I'm not advocating for emoji passwords, it was just a discussion about password strength vs length.
Right, you can't force people to use good passwords, but you can set up requirements that try to maximize the chances that that's what you get.
As others have mentioned, there's no way to fully evaluate password strength short of providing your own entropy, so while the distribution is an important one to know about there's not much we can do to apply it while retaining a traditional password model.
NIST has some recommendations[0] that can detect when a password is not strong, such as checking a list of cracked passwords, but we can't prove that it is.
It was a kind of joke. If you don't show the password, then it seems more secure because nobody can see it. I was in doubt whether to retain that naming.
I came across the most humorous password entry view blocking scenario on a firestick trying to login to netflix the other day.
You are visually moving the cursor around a graphically displayed keyboard... pressing enter when you are on the letter or number desired, at which point the hidden password entry form immediately increases by 1 in length.
> You are visually moving the cursor around a graphically displayed keyboard
A bank in France, "Societe Generale de Banque" still shows me a little visual keyboard (with digits only). The digits are shuffled. Then it's similar: I need to hover the digit I want to pick, click, it blinks, then the hidden password entry increase by one. Repeat 5 more times.
I can then wire up to 100 K EUR if I want. Insanity.
Now, to be honest, all my other banks in Europe are using an actual hardware 2FA which they sent me.
It’s a very old banner, I didn’t mean for it to be patronizing, just to mock the absurd cookie law which had just passed.
I’m trying to go cookieless, actually, I hope to finish someday, Google Analytics was removed already. I’ll need to ask for explicit authorization for disqus commenting only.
The best solution to password requirements is to eliminate passwords altogether. Passwords are the most problematic and weakest authentication factor we have.
I lead Security in a quite large bank. I love this article, I’ve been advocating for this line of thoughts for more time that I can remember.
I have spoken to regulators hundreds of times, over this and a bunch other security topics that are definitely obsolete. Security policies that just don’t make sense…
The most important thing for this kind of things to advance is to have the correct people in the correct places, and usually in this positions you have dinosaurs…
In most of my banks in Europe, all but one, I cannot log without using an actual physical 2FA device the bank sent me. One of them, Deutsche Bank, sent me a specific hardware 2FA which works "by itself" (and is protected by a PIN). No password to log in: only the user account ID and that 2FA device.
The others require my Java SmartCard / national ID card to be inserted in a 2FA reader they sent me (it's a standalone reader with its own display: it is not a Java SmartCard reader hooked to the computer).
Do you guys hand out your customers physical 2FA devices?
Not anymore, we used to do that and maybe a bunch of customers still have that device to log in, but we have been replacing them (the “hard token”) with a “soft token”, kind of a Google Authenticator linked to your mobile.
It is interesting how “yubi”things have moved in the opposite direction (back to the physical device) and it has its value, after all, leaving your home with all your savings in your pocket is a risk we need to address.
> A short password is easy to bruteforce. But, a website should aim at password strength, not at password length.
Is there a standard metric for “strength” though? I built my own random password generator and considered adding a strength meter but all of the functions I could find online seemed like they had pretty arbitrary logic. Length is probably the most objective proxy for strength.
NIST standard suggests checking a list of leaked passwords, and setting a length requirement:
> Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.
Password strength cannot reliably be measured by looking at a password.
To take one common trick: is VpttrvyJptdrNsyyrtu a strong password? It looks pretty okay, definitely less of a pattern than CatName1985, and an estimator like zxcvbn might also not know that it's just CorrectHorseBattery offset by one character on a qwerty keyboard. Now that you know this, you can start to guess my other passwords. Would you still say it is strong now? What if I'm not the only person on the planet using this trick, does that affect it?
The strength calculator you're looking for is (technically) the method of generating the password. If you generate 6 random words on a dictionary size of 15'000, that's log(15e3⁶, 2)≃83 bits of entropy. You can only know this by asking the user how they came up with the password, or by telling them to do it a certain way. The rest is just guessing, though I will say that something like zxcvbn does a surprisingly good job at it.
The caveat is that the generating method should not have any plausible chance of overlapping with other (insecure) in-use methods. E.g., if you roll a die between zero and a hundred quadrillion and use that as password, most of the time you'll roll a really long number. But if you roll 123123 or 12345678 and use that as password, you can expect it to be cracked. Technically, by excluding "weak" choices from the list of possible values, you are reducing the strength of the password because there are fewer remaining valid guesses, but given how attacks actually work, it makes sense to do this.
There is no way to tell if a password is strong since it may be reused.
Instead services should provide a random password so the strength can be known.
For example, this is a 128 bit password: CR4EOJ5ZYQRKCGQV4OLN2ZRFS.
Since that is a random number provided by the service it has a guaranteed strength of 128 bits.
Some in this thread seem to gloss over a vital point: security is measured in bits.
The whole character set stuff, "this many characters, special character, must include a number" is meaningless. Instead, a target strength in terms of bits should be specified. That can be represented in whatever base or alphabet as desired. This tool help makes that point: https://convert.zamicol.com/#?inAlph=0123456789ABCDEFGHIJKLM...
> There is no way to tell if a password is strong since it may be reused.
Very good point. From that perspective any reported strength can be extremely misleading.
As far as bits go, this is where I get a bit lost. Calculating the number of bits only makes sense if the attacker knows what your character set is. Otherwise they will need to iterate over the full set of characters.
So a 20 character password of Xs and Ys is just as strong as a 20 character password with lowercase, uppercase, digits, and 10 symbols (72 options) as far as I can tell.
The other issue is, even if I have the entropy of the password I don’t know what “strong” really means. Presumably something like logarithm > some value, but that value also seems completely arbitrary.
If a service didn't want to store 124 _bytes_ in a database to represent the above base 2 password, it can use a hashing algorithm to like SHA256 to reduce the storage requirements to 32 bytes. The password still has 124 _bits_ of entropy even though 256 bits are stored.
>Calculating the number of bits only makes sense if the attacker knows what your character set is.
Assume that the attacker knows the character set in both cases, as this is the worse case scenario. The equivalence is then apparent.
I was looking, last week, what to recommend to a customer and ended up at https://github.com/zxcvbn-ts/zxcvbn because the one from Dropbox seems to be completely abandoned and does not recognize e.g. 2020 as a year.
Other alternatives are also welcome if there is an even better one I missed! This was the best password strength estimator I could find.
kinda. you can calculate the number of bits of entropy in the password
8 character long alphanumeric lowercase password: (26+10)**8 = 208827064576 possible passwords. 11000010011111000100000010000100000000 in binary = 38 bits of entropy
20 character long upper+lower+numeric+other ASCII password: (26+26+10+32)**20 = 2901062411314618233730627546741369470976. 132 bits of entropy
128 bits of entropy is considered to be enough for all purposes
Sure, but given a password I have no idea what character set it pulled from. I could have an alphanumeric character set and still randomly generate “aaaaaaaaaa” which is obviously insecure.
I only said check it out, there is a lot of content there useful to the wider topic and the page clearly states what it is and isn't.
>>> IMPORTANT!!! What this calculator is NOT . . .
It is NOT a “Password Strength Meter.”
Since it could be easily confused for one, it is very important for you to understand what it is, and what it isn't:
The #1 most commonly used password is “123456”, and the 4th most common is “Password.” So any password attacker and cracker would try those two passwords immediately. Yet the Search Space Calculator above shows the time to search for those two passwords online (assuming a very fast online rate of 1,000 guesses per second) as 18.52 minutes and 17.33 centuries respectively! If “123456” is the first password that's guessed, that wouldn't take 18.52 minutes. And no password cracker would wait 17.33 centuries before checking to see whether “Password” is the magic phrase.
Okay. So what IS the “Search Space Calculator” ?
This calculator is designed to help users understand how many passwords can be created from different combinations of character sets (lowercase only, mixed case, with or without digits and special characters, etc.) and password lengths. The calculator then puts the resulting large numbers (with lots of digits or large powers of ten) into a real world context of the time that would be required (assuming differing search speeds) to exhaustively search every password up through that length, assuming the use of the chosen alphabet.
How can I apply this to my daily life?
Answering that question is the reason this page exists. The whole point of using padded passwords is to adopt a much more you-friendly approach to password design. On June 1st, Leo Laporte and I recorded our weekly Security Now! podcast as part of Leo's TWiT.tv (This Week in Tech) audio and video podcasting network. You may download a shortened, 37-minute, excerpted version presenting the padded password and Haystack calculator concepts:
My point is that a "search space calculator" isn't useful. The only thing it will ever achieve is misleading people. Especially as that definition is also wrong, because the search space of a dictionary is achieved by counting words, not letters.
I guess this post made an impact on me. Earlier I was using the policy of Upper, lower, special characters but now using zxcvbn. https://zxcvbn-ts.github.io/zxcvbn/ Much thanks to the creators and maintainers.
> You cannot enter a password with more than X chars
I've seen this from banks, for access to my money & credit...
Both FirstDirect and HSBC used to have a 9 character password for their "digital secure key"s (basically their apps on my phone, in the direct use use-case). 9. Just 9. Though at least alpha-numeric & case-sensitive, so some room for reasonable entropy.
Worse: for some reason HSBC recently changed theirs to 6 numeric characters. 6. Numeric only. And while forcing me to change, they repeatedly assured me that this was just as secure as before… Luckily for me all I have with them currently is a mortgage that I'll be paying off in (checks calendar) a week and a half, at which point the whole lot gets closed and they can make it a two digit PIN for all it'll affect my financial security!
(UK here, not sure if they have different restrictions in different territories but I suspect not)
>Worse: for some reason HSBC recently changed theirs to 6 numeric characters. 6. Numeric only. And while forcing me to change, they repeatedly assured me that this was just as secure as before… Luckily for me all I have with them currently is a mortgage that I'll be paying off in (checks calendar) a week and a half, at which point the whole lot gets closed and they can make it a two digit PIN for all it'll affect my financial security!
I'll one-up you: Nationwide requires six numeric characters, which you have to enter via one 0-9 dropdown menu per digit, and you only have to enter three per login.
i.e. if your "passcode" is 987654, then it will randomly choose only three of those for you to enter, like
_?_??_
where you'd only have to put in 8, 6, and 5. So it's clearly stored in plaintext. And they have 2FA, but as you might expect, it's SMS only.
And their online banking site is garbage, some links just always timeout and log me out.
Is there a single UK bank that has the following two features: 1) lets me pick a sane password and has non-SMS 2FA, 2) has an online banking interface that works on desktop browsers.
The second one is important to me because I never want to do banking on my phone. Last time I checked, the "challenger banks" like Monzo only have phone options.
I'm absolutely sure banks store passwords in plaintext more often than not. But then one particular bank takes the cake. There, I have:
- The usual login + password, the password length is limited of course
- The "secret questions" to confirm some actions. In reality these are just three extra passwords
- The code generator in the mobile app to confirm some other actions, for access to which you need a 4-digit pin code
Another bank is much more sensible in this regard but requires me to change my password every year. I hate it with a burning passion when there's any time component at all in user authentication.
> You cannot use whitespace, accented letters, hyphens, [...] in your password
When test-installing Fedora I use a password which contains some shift number key characters with my UK keyboard. It's a very good test of whether the keyboard encoding is set up correctly in all the places that take passwords. Usually at least one place is set to US keyboard, whatever the user preference.
A password containing, for example @, could cause weird log-in issues later, assuming you're not using a password manager which of course you should be.
Your passwords are safe as long as you have done your part, i.e. followed best practice on how to set up your passphrase for accessing your information. LastPass implemented a system that is durable, as long as your HW is not compromised or you are somehow duped into giving away your password you should expect your passwords to be safe. If you are worried, change your passphrase in accordance with best practice and you should be fine. Breaches will happen, their architecture saves your data - but that means we have to do our part and follow recommended process/practice.
Password managers are "obviously" the solution - in my experience they generate good passwords that are accepted almost all the time now days.
However, I still think 3rd-party password managers are too complex for many people, and those people are the ones who need them most. OS-level password management is a bit easier but not great. Browser native password managers are a terrible idea IMO, for people who can't handle a 3rd party manager, imagine their confusion when only a specific browser knows their password, and only when they signed into their browser vendor account.
The interoperability boat has sailed. macOS has had an open Keychain for decades and Google eventually dropped support for it. I don't see them suddenly going back, sharing efforts and allowing cross compatibility.
What we need is just passwords to come front and center anywhere they are: We need a Password.app that I can open and access all I need. Keychain Access was exactly that but its UI is stuck in 2000.
My company recently switched to something probably inspired by the NIST standard. We are supposed to have a unique password, that never expires. The "problem" is that we are now required to use 2-factor basically every time we sign in instead, which is annoying, and the login also times out way too fast of course. Previously I could be logged in for days? Now its hours and I need to then use my phone to log in. (I only work remotely, but being a firm of contractors its what most of us do.)
> The usual approach for handling a password is: take the password as a string, as the user typed it.
Ah. That usual approach, where any rogue employee or anyone really snooping on either side of the connection before/after the TLS gets to see the plaintext password.
Makes me wonder: is salted challenge response authentication (RFC5802 and 7804) getting any traction?
Couchbase is (was?) using that. Is there a list of websites that went past what's basically the nineties' "plaintext password over SSL"?
there is also a disconnect between password requirements and automatically generated passwords, where often the auto-generated password contains prohibited characters.
> when trying to login, the "enter your password" field isn't got the same limitations, and you cannot login because you're using the wrong (too-long) password
> please allow long passwords at least 64 chars long; even 256 should pose no DoS risk whatsoever
With a very large user database, a 256 char entry field would really start to add up, wouldn't it? iirc the DB takes up that room whether it's fully used or not. Size affects not just disk but also bandwidth, memory, cpu, and has an overall effect on system performance
> You cannot enter a password with more than X chars
And this is the most infuriating thing, especially when the lowest limit is say 8 chars and the highest is something like 12. I get the point that there should be some limit - 64 chars for instance - but limiting the password length to anything less than that is just dumb.
I thought the one capital, one strange character, at least 8 characters, etc. policies were mainly so that whoever programs the web page can later claim to have taken proper measures when the site gets hacked.
Where this came from is stuff like the DES crypt implementation where passwords were truncated at 8 characters and then 7 bits were extracted to form a 56 bit DES key. You simply couldn't have long passwords back then. The first widespread crypt implementation that could handle long passwords was probably PHKs MD5 based scheme in 1995 -- contemporaneously around the release of Netscape Navigator.
If you only had 8 characters then you needed to include multiple different character types and needed to not use dictionary words. So for the early internet those became the standard recommendation until long-password-supporting crypt()s became standard in operating systems.
Having gone through a decade-ish of those password standards in the 90s by the time all the operating systems had updated their crypt() standards a lot of people didn't really notice until the xkcd comic in 2010. And now you've just got to fight 30-ish years of inertia of those being considered the standard.
Password manager password generators have a simple UI you can click to select the password format required by the form. Or just click 'generate' again and try each until one works.
I stopped reading at the password length isn’t password strength part. This goes against NIST guidelines and is opinion. Just follow NIST password guidelines guys.
This is an explanation and reasoning. It’s designed to make people think about policies and scenarios, and not to blindly apply random suggestions.
What is against NIST guidelines?
The length argument works both ways: just as a purely lowercase alphabetic password, if long enough, is safe, a very short (in term of code points) password with full unicode spectrum can be safe as well.
Passwords should just be random numbers, and services should provide a suggested password on the sign up pages. Here's a 128 bit password: CR4EOJ5ZYQRKCGQV4OLN2ZRFS.
Better than all that is public key authentication.
Unfortunately there are so many ideas that will "never" gain ground. People are still stuck with the user/password paradigm and it will take some serious push to move to something like Passkeys, which is obviously the best if implemented correctly (i.e. provide a fallback when using a non-own device)
We need a push like it happened for HTTPS, which became widespread in less than a decade, but that basically means Google has to push for it.
Rotating passwords is an old idea but mathematically it does reduce the probability of bring compromised. Otherwise I can know for certain when something is not your password each time I get it wrong.
> Rotating passwords is an old idea but mathematically it does reduce the probability of bring compromised.
Please can you show your work.
Most websites limit the attempts per user per time, which should make direct request break-ins unrealistic to mathematically impossible. So now we move the needle to "Your user database has been stolen, someone is trying to break hashed + salted passwords" which is such a problematic scenario for so many other reasons (e.g. unencrypted password recovery information stolen, PII stolen, and social engineering information verification info stolen) that rotating user's passwords weeks-months later is such wishful thinking.
Like, I legitimately don't get it. It was created in the late 1980s by people who just did what sounded right, and we've been stuck with it for over thirty years because change it hard.
Your assumption is that there's zero time between a leak and the abuse. If my password reaches the abuser after it expires, then I have been saved by the rotation.
Also rotation + "no reuse" policy essentially guarantees that eventually the password will be unique and not reused across services.
Side note: I despise rotation as much as the next guy, but I can see the value in it. If users used password managers, generated passwords and not reused passwords, then we wouldn't need such rules. But alas 1234567890 is a common password.
> Your assumption is that there's zero time between a leak and the abuse. If my password reaches the abuser after it expires, then I have been saved by the rotation.
Nope, that wasn't my assumption. What I said above applies there equally.
> Also rotation + "no reuse" policy essentially guarantees that eventually the password will be unique and not reused across services.
No it doesn't, in fact it increases password reuse and results in pattern-style passwords.
That’s only true if people keep making similarly strong passwords every time.
The first password may be secure, but I can practically guarantee that the security will have degraded significantly by the 4th time you change your password that year.
I hate that HN users downvote concepts they disagree with.
One can agree that rotation is good in theory and bad/annoying in practice (due to laziness). We can only argue about how much of an impact it makes, but it certainly does not reduce the security.
We all deal with "password rotation" in real life and it's inescapable: credit cards expire. And to be fair I'm perfectly fine with that because I know a leak from 10 years ago can no longer affect me. I almost wish they expired earlier.
Yes it does. The more often you have to pick passwords, the more likely you are to pick weaker ones.
> We all deal with "password rotation" in real life and it's inescapable: credit cards expire. And to be fair I'm perfectly fine with that because I know a leak from 10 years ago can no longer affect me. I almost wish they expired earlier.
When a credit card is about to expire, doesn't the new one the bank sends you usually have the same number?
> doesn't the new one the bank sends you usually have the same number?
Never happened to me using several European banks. Either way the date and CVV change so that's part of the new password.
> Yes it does. The more often you have to pick passwords, the more likely you are to pick weaker ones.
I don’t think so. People will just change the number at the end, it's not like they will stop using aDgTGdE and start using 11111112 simply because of rotation. It's more likely that they will append a ! or change helloworld to helloworld2. It's not a downgrade by any mean.
Plus such rotation even "guarantees" that the password isn't shared across services, unless they're all rotating with the same frequency and they all start with helloworld2
yep, most of the discussion about passwords completely miss the point. a random word, like "dog" or "pingpong" is fine if the pqsswords are salted and hashed appropriately. how often have your accounts been hacked this way? if an adversary is really banging on the hash, and they want it, any password under around 50 characters is as good as "dog", and no "complexity" meter is gona cut it. that xkcd comic that says 550 years? no, that password its owned a lot a faster than that. all this talk of entropy and security but so obviously clueless about modern brute force techniques
> most of the discussion about passwords completely miss the point. [...] any password under around 50 characters is as good as "dog"
I think you've completely missed the point.
After how long do you start to get annoyed when logging in? Most people probably at 2-5 seconds, but let's say ten full seconds of waiting for the computer to do the hashing. A word like dog is among the top few thousand words, let's say ten thousand, so after 10k×10s/(3600 seconds per hour) = ~28 hours your password is cracked on a single cpu. Probably more like 28 minutes on a couple GPUs, and this is using a complexity setting that literally nobody is going to use (I bet even the NSA isn't paranoid enough to wait 10 seconds for every login). Now compare that to "any other password under around 50 characters".
If you want to use a passphrase, pick random words (at least five when using complex words; the number depends on your dictionary size). Not a single word that is also very common. That completely misses the point.
This strategy would work if literally everyone uses a random words generator and yours, against all odds, comes up with a single common word. Then attackers would have no reason to crack in order of commonness and start with a single word. But that is not the reality we live in and attackers do start with simple passwords before complex ones. (Source: one of the things we do at work is crack passwords, most commonly when we get our hands on Windows password hashes.)
if its that "dog" is a weak password, i thought that was evident. but many people seem confused that "horseloverwhatever" is more secure, similarly that "dog23!Wog" is more secure. my point is they are equally trash so leave the user alone
> if its that "dog" is a weak password, i thought that was evident
You're confusing me. First you say that "dog" is just as strong as any other password, now you say that it should have been evident that it's a weak password. Which is it?
> my point is they are equally trash
This again sounds contradictory, but this time within one comment. First you say that horseloverwhatever is stronger than dog, but then that they are equally "trash".
i meant others commonly assume horseloverwhatever is more secure.
to be more clear,
1. dog is weak
2. horseloverwhatever is weak
3. 8randoms! is weak
4. therefore, dog is as good as horseloverwhatever or 8randoms!
5. most account compromises do not even require a brute force (shoddy practices on the backend) making the complexity requirements pointlessly burdensome on the user
6. in cases where you want a password to resist a legitimate brute force, we need to talk about passphrases (ie > 50 chars) or passwordless
i agree. but most sites that enforce a policy (8 chars, symbols, etc) are bruted just as easily. we need to take a step, away from passwords, to secure against brute force in 2022
well the gp's point is that it literally is not 'just as easy' because the space of possible passwords increases greatly with each character, such that 'dog' is much, much easier to bruteforce than 'doggie12'.
To be fair, I'd probably crack doggie12 sooner than dog because who has ever seen a website with a password length requirement below 6. But technically, yep you're 100% right.
The length of the password only somewhat matters for rainbow tables -- they're not limited to dog-sized passwords -- but also, I rarely come across implementations these days that do not use a salt of some kind, which defeats existing rainbow tables. Generating one-off tables is about as expensive as just cracking the hashes directly.
(Then again, the implementations I see are mostly from well-known projects or customers that care enough about security to hire us. It's biased, but I do think word has gotten round about hashing and salting.)
a random word, like "dog" or "pingpong" is fine if the pqsswords are salted and hashed appropriately. how often have your accounts been hacked this way? if an adversary is really banging on the hash, and they want it, any password under around 50 characters is as good as "dog", and no "complexity" meter is gona cut it.
You really need to provide some sources for this claim; it's outlandish and unreasonable because it varies so wildly depending on what you mean by "appropriately". This isn't magic, it's math, and we know how fast computers can do specific kinds of math under specific conditions.
> yep, most of the discussion about passwords completely miss the point. a random word, like "dog" or "pingpong" is fine if the pqsswords are salted and hashed appropriately. how often have your accounts been hacked this way?
A word like "dog" or "pingpong" is favored in a rainbow-table type of attack. Nobody pre-hashes "109231oijoasdfnaisdfabatteryhorse123".
And yes many passwords have been hacked this way [0].
So it's hard to understand the point you are tried to make. Why don't you try again and expand on "modern brute force techniques" that could crack a password 50 characters long? More productive endeavor and benefits the board.
how does a rainbow table crack "dog" with the salt "109231oijoasdfnaisdfabatteryhorse123"?
rainbow tables are as old as time and indeed still work on passwords with poor salting. for more complex (but not complex enough) passwords there are more modern approaches, like probabilistic candidate generation
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.