* Require more than 8 characters
* Don't require special characters
* Don't force the user to reset their password
* Do check for compromised passwords
* Require MFA
* ...
All very sensible.
https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...
Here's the direct link to NIST 800-63B - it's really a fantastic document with sensible recommendations on every authentication method: https://pages.nist.gov/800-63-3/sp800-63b.html
The tedious part of NIST's password requirements is "Do check for compromised passwords"
HaveIBeenPwned exists, but most open source tools don't leverage it and this requirement goes overlooked.
At Clerk, we follow NIST guidelines by default, including integration with HIBP. In a world with password reuse and "credential stuffing" attacks, this feature is critical to securing your user accounts (unless you go full passwordless, but that has its own tradeoffs).
A portion of our customers will ask us about NIST, but it's slimmer than I would have expected.
While that's technically true, the advice is meant to be taken in the context of the rest of the advice (e.g. longer passwords, checking against compromised passwords, etc...).
If all you did was to change all your passwords to never expire, you'd be reducing security.
Not necessarily. Except in cases of gross negligence, such as storing passwords in plain text, the human is always the weak point in a security system. If you make people less likely to leave their passwords on sticky notes, perhaps by removing password rotation, then you have improved the weakest link of the system, and improved the security of the system as a whole.
It's clueless, I know, but you'd be amazed at the percentage of people that think disclosing something is a disclaimer (sigh!)
openssl rand -hex 8 | sed 's/..../&-/g;s/-$//'
openssl rand -hex 8 | sed 's/..../&-/g;s/-$//;y/abcdef/ABCDEF/It's either that or pick a random dictionary word.
grep --perl-regexp '^[a-z]{4,7}$' /usr/share/dict/words | \
shuf -n 5 | tr '\n' ' '
bless clench moraine shuf /nix/store/ny99jkpl3r9zgkkdv5apprzl18i8rb4m-scowl-2019.10.06/share/dict/wbritish.txt \
| grep '^[A-Za-z]\+$' \
| head -n 3 \
| sed -e 's|\(.\)\(.*\)|\u\1\2|g' \
| tr -d '\n' \
| sed -e 's|$|\n|g'
OmegasInsentientPantheons
Many people are, contrary to all pretense, mostly paid to not give any actual fucks.
But I was relieved to find my CC provider calling me to verify I was just up to shenanigans.
I was also curious how many thieves they had run across that signed for purchases as stolen in large cap letters.
The saddest thing is banks can't be too secure. If they were, then they would be too hard for normal people to use and they would get locked out of their funds.
I would literally close out my account in that very moment if my bank did that. Not only because that's horribly inconvenient and I would never put up with it, but it also shows they have no idea what are sane security measures or not.
Yes.
They also force users to install literal malware into their computers masquerading as a "security module". Not only is it invasive, it slows down everything to a crawl. I tried to reverse engineer one such module and caught it intercepting every single network connection. It also used to force install itself into browsers as an extension, no doubt in order to intercept data.
> I would literally close out my account in that very moment if my bank did that.
That's exactly what I did. Chose a smaller bank that somehow didn't use this malware. The least bad option.
As for the asking birthday for security reasons, relic from the past, getting more useless as time goes by. With so many websites asking for that information, and then they get hacked, sold or leaked. Yes, this said the completely obvious, but it still amazes me that any organisation that I have a financial relationship with asks that for identification over the phone, usually my address as well, but that is almost as public.
- authenticating using a 'client number' (different from your 'account number', sent to you once by a physical mail you lost long ago) combined with a 4-to-6 digit (numeric-only) passcode that you have to input on a virtual keyboard
- confirming web-initiated transactions via their app on your phone... but when it's app-initiated, well, you don't have to confirm anything other than just retype your passcode
- in the end, introducing some awfully long delays between some actions e.g. creating a new beneficiary and being able to send money to her... because 'it's for your own protection that we degrade your client experience'
This just bugs me.
Banks and airlines are of course some of the most egregious offenders, but even tech companies like Apple and FB have complexity requirements on capital letters and numbers. Surely the login security teams at these companies are aware of the NIST recommendations.
Yet a tiny 3 person startup launching a simple crud app is more likely to google the NIST requirements and follow them than any of the biggest billion and trillion dollar market cap companies in the world. Are these companies acting irrationally here? Or is NIST not taking into account the factors that big companies actually care about, like support costs of dealing with account takeovers, etc.?
The NIST standards recommending this (SP 800-63B I believe, under "memorized secrets") came out in around 2017, many years after large companies had settled on prior standards. Prior standards were closer to what banks / other biggies were doing and they just kept on doing it. In addition you may have other non US govt policies (UK for example likes to publish policy docs, see: https://www.ncsc.gov.uk/collection/passwords/updating-your-a... for their slightly different modern take) which the company prefers to use because of either their own HQ location or large customer pull.
Better yet many different countries requirements and a couple industry docs are cobbled together into a frankenstein set of requirements. That requirements docs is then treated as though it came from Mount Sinai and should not be altered without getting the approval of 3 senior VPs, a professor of cryptography, and the head of IT.
If you need to interact with taxpayer data and interact with the IRS, for example, you’re required to comply with fairly prescriptive controls for a variety of things that conflict with current NIST guidance.
The other thing is that changing anything identity is a pain in the ass. If there’s a business process and outsourced support model in place to deal with account issues, it’s actually easier to just deal with the shitshow than to fix stuff. Big dumb organizations make decisions differently!
> one of the most frustrating experiences
I understand this frustration as a mismatch between the user's non-expectation of security and the service's obeyance to industry security best practices.
Placing a cognitive burden of memorizing a new password just to try out your product strikes me as cruel.
Maybe only enforce password rules as progressive enhancement once sensitive information comes into play? After all, what's the point of protecting junk?
For me I just see it as a sign of pretentiousness when you expect me to come up with a 20 character password. Luckily Firefox has a built in password generator now.
It depends on the forum and the hacker. Most hacks won't have a practical implication, but a targeted attack by somebody unhappy with your comments might abuse your identity or information the account reveals.
Or a forum can reveal information you don't want to have revealed (medical help forums, sexual stuff, ...)
And sometimes you are really to leave "child times" behind you, which might reach surface again later. (Say when you get into a political career ten years later and somebody finds your mail address and searches through dumps of leaked data etc.)
Also you're not supposed to be memorizing anything for logins. At the very least you should be letting your browser use the randomly generated password and save it to the browser password store if you're not using a full blown password manager.
https://users.ece.cmu.edu/~lbauer/papers/2011/chi2011-passwo...
Using some kind of OTP authenticator app or device and __NOT__ SMS!
What SMS is terrible for is as a single point of account recovery. This is unfortunately how it is often used. "Multi factor authentication" in practice has become "Use any one of multiple available factors for authentication", which is awful.
So no, SMS is not perfectly good. it's crap and needs to die in a fire.
I know that frequencies are different in some parts.
A proper OTP app works offline, and more than one of them can exist for any given authentication, so you can have backups if your phone is stolen.
It's better than just having "secret" as your password, but not by nearly enough that you should feel particularly secure with it.
The issue with with all multi factor authentication is dealing with the likely situation that one of your users locks themselves out of their account and needs to have the factors reset so they can get back in. The secure way to deal with that would be to go, "Sorry, we don't know you and you've lost all your data. Goodbye!". But of course with important accounts that usually escalates pretty quickly with upset users hogging your helpdesk employees and not giving up that easily. So, most companies have help desks that are easily talked into "helping you". That's what they are incentivized to do. Companies with tight margins are the worst. Like most operators for example.
We desperately need to have better MFA options if we're going to require it from users.
Phone numbers, fair enough, but TOTP is an open standard and there are plenty of open source implementations for the client side. It’s also available in most password managers (I use 1passwords implementation).
“MFA can’t require me to run a binary on my phone” is a bit extreme. TOTP is fine.
Where I work a bunch of people had a cow about having to put a MFA app on their phones, but refused to take a work phone. Our remedy was to issue them PINs to allow after hours access to the building.
Every service of course has the option to print backup keys. Maintaining those (in secure offsite location) over years takes some effort.
If I'm reading this right, it's more than 7 characters. And more than 5 if you don't let users pick the password, which seems surprising.
> 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.
The idea is to mitigate against brute force by account lockout/disable following N failed attempts rather than enforcing greater password length or complexity requirements.
If we assume an entropy of 2 bits per characters (which is generous if the user uses dictionary words), then 9 characters gives us 18 bits.
A 9 character password could easily be as poor as a random 18 bit integer.
If we permit the user to use nothing but lower case characters from the set a to z, we should probably require a password phrase length of at least 30 characters.
Not forcing the user to reset their password means you need a really strong one, in case the user is using the same password. You're giving attackers all the time in the world to crack a leaked hash, so it better require something resembling all the time in the world.
These recommendations are basically relying on the MFA recommendation to make up for all the others. Like, oh, it's okay for the user to have 18 bits of entropy for a password, because we can trust that the attacker won't have the user's phone.
2x211y doesn't look very random to me. 2 and 1 are consecutive, and there are only 4 distinct digits here. Even if it was randomly generated, a good password generator would probably discard it for being akin to passwords that humans tend to generate. (This is especially true when you impose minimum lengths to passwords. "26219 isn't long enough? Fine. 262119.")
Fish and idea are both among the top few thousand most common words. Searching adjective+noun pairs is going to be much more fruitful than searching arbitrary word pairs, and ideas can in fact be fishy, so it makes sense to guess that particular adjective+noun pair before trying metamorphicidea.
The word "idea" appears list of 850 common words:
https://en.wiktionary.org/wiki/Appendix:Basic_English_word_l...
"fish" is ranked #1453 in the list of lemmas linked from here:
https://en.wiktionary.org/wiki/Wiktionary:Frequency_lists#To...
We can arithmetically encode the choice of two words from dictionaries of 1000 and 1500, respectively, using 21 bits.
The two bits estimate is a somewhat pessimistic lower bound.
But allow at least 2 hardware keys and not only SMS.
America is strange, any rando nutjob should have access to firearms but US corporations are terrified of being sued.