Disclosure: I am the cofounder https://www.clerk.dev

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).

The important part is that the NIST password advice is meant to be read as a whole. Often I see people quote snippets out of the advice, but unless you read and understand the whole document, you run the risk of reducing your security posture.

But even if you didn't read all of it, and just required longer passwords instead of special characters, you'd be improving things.

That's true, but I've also seen people say that NIST no longer recommend expiring passwords periodically, so we should just let passwords never expire (source: "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)").

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.

> 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.

What's crazy to me is that NIST compliance isn't part of SOC-2 certifications or similar.

A portion of our customers will ask us about NIST, but it's slimmer than I would have expected.

Off-topic, but this is the second time in two days that I've seem someone on HN correctly use "disclosure" when disclosing something, rather than "disclaimer". A sea change?!

It's clueless, I know, but you'd be amazed at the percentage of people that think disclosing something is a disclaimer (sigh!)

I have multiple financial accounts that still insist on using public-knowledge security questions (which of course I've given fake answers saved in my password manager) instead of just letting me set up proper 2FA. It's infuriating.

Treating security questions like passwords and saving them in your password manager is correct, but make sure that your fake answers aren't autogenerated nonsense like ":s^Twd.J;3hzg=Q~". Many password reset flows involve communicating a security question over the phone, and it's easy enough for an attacker to guess "oh, it's just a bunch of random characters lol" and for the phone rep to just laugh and shrug their shoulders and let the person in. Make sure it's a sentence that makes sense (I would even avoid non-sequitur passphrases such as those generated by diceware), while also making sure that it has no relationship whatsoever to the question.

Maybe “:s^Twd.J;3hzg=Q~ if I don’t spell it, it’s not me”?

Will probably work about as well as that time when I was young and decided to spend about a week signing all receipts with a signature that looks nothing like my usual one, just to see if it would ever be challenged.

Many people are, contrary to all pretense, mostly paid to not give any actual fucks.

I once signed STOLEN on a pad at the grocery checkout. They let it ride and ran the charge.

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.

What do you think the signature is for? If a store can provide a signed receipt, the bank eats a chargeback. If they can't, the business pays. No one verifies that it is your signature. It is just an anachronism of how contracts work.

My password generator can make pronounceable nonsense words. It has worked ok so far. Some of them are embarrassing though.

My password generator (or just do it manually) can generate word passwords like correct-horse-battery-staple using real words, which is probably a bit easier to read over the phone.

  grep --perl-regexp '^[a-z]{4,7}$' /usr/share/dict/words | \
    shuf -n 5 | tr '\n' ' '

Although maybe just 2 or 3 words would be best for avoiding a support agent skipping the question.

  bless clench moraine

Nice one there, much simpler than my nearly POSIX one (I think I rely on a GNU sed extension, but it was years since I wrote this):

  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'

Which gives you for example:

  OmegasInsentientPantheons

I only use this for “secret” questions though, not passwords.

  openssl rand -hex 8 | sed 's/..../&-/g;s/-$//'

Or if you like upper-case letters:

  openssl rand -hex 8 | sed 's/..../&-/g;s/-$//;y/abcdef/ABCDEF/

This would still parse as "random letters and numbers" to your typical support agent, no?

Maybe, but it's close to what I use. It's a limited character set and more or less looks like a credit-card which people are used to seeing.

It's either that or pick a random dictionary word.

Citibank is particularly egregious. 8 character MAXIMUM length, lots of special characters not permitted while requiring numbers and letters, forced password changing every few months, I absolutely hate it.

Are you speaking as an employee or a customer? I just checked my password db for a few Citibank accounts and all of them were far longer than 8 characters.

For my CitiBusiness account, not my personal accounts

Yeah, my bank does that too. Asks for my birthday for "security" reasons. They also kill their website's usability by forbidding physical keyboards and forcing users to use a virtual keyboard with randomized key layouts in order to type passwords in a feeble attempt to defeat keyloggers. Some banks even make it extra annoying by generating ambiguous keys like "1 or 7" or "2 or 3".

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 imagine it also disables autofill from password managers (since it's not actually a form field)?

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.

> I imagine it also disables autofill from password managers (since it's not actually a form field)?

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.

My bank used to have a virtual keypad, they now have a normal password field. So they actually saw reason. I think there is reason to be optimistic about bank password security getting better; what is known to be good password policies and interfaces are getting more widespread. It may take some time, but it should get better because it is accidental or ignorant password policies from the past, not deliberate attempts to make their customers trip up (unless someone knows better).

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.

Don't get me started on online bank security. Here in France, most banks have decided that security is best achieved by:

- 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.

Yeah my bank does this. I've been meaning to call around and find a credit union that has 2FA and doesn't require this garbage. I changed my questions to a randomly generated password and put it in my password manager.

Why do basically zero companies seem to follow this?

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.?

Inertia and other standards are a big force here.

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.

I’ve actually raised with a security executive in my large consulting firm - the biggest blocker is apparently that requirements like frequent forced password changes are written in to many contracts signed with clients as boilerplate ‘we promise to do x/y/z practises to keep your data secure’. Newer contracts have much better language and there have been some improvements that way (our reset period duration tripled recently), but it takes time to trickle through.

NIST standards are technical guidance. The issue is downstream where different authorities make policy based on whatever NIST said at one time.

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!

I'd imagine that for at least some of them it has to do with appearance. "Facebook is so secure! It's got ten whole password requirements!"

Big companies have big bureaucracies and third-party auditors that define stuff like this. Getting them to change their requirements is a herculean task.

Interestingly, one of the studies they cite finds that blocking common passwords is one of the most frustrating experiences for users. Even though it's more secure, the user has no idea what's wrong with their password or how to correct it.

I can't say how common this is, but many (most?) online accounts I personally interact with are disposable, represent no sensitive information, and I couldn't care less if they're compromised. They're one-time sign-ups, junk accounts, free trials, free tiers, etc.

> 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?

Passwords often protect things like random niche forum boards from grief more than they protect the user's sensitive information in such cases. 3rd party auth is a great solution but a lot of people don't want to tie their "real" accounts to the low tier sites. MFA is of even greater help for low tier site's pains but if you can't get someone to use a decent password or link their identity how likely are you to set up 2FA for it? In the case of "free" services type signups they want you to onboard your information or link your identity and an account workflow is the easiest way to do that as it's a small percentage that will go through the trouble of burner or temp emails and fake info yet at least you have an easy way to rate limit such users from hijacking your "free" offerings.

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.

Yes every service considers itself critical. But users don't give a shit if some forum they signed up for 3 years ago gets hacked.

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.

> But users don't give a shit if some forum they signed up for 3 years ago gets hacked.

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.)

Link? That sounds like an interesting study.

"These results reflect the fact that dictionary checks appear to contribute heavily to reducing usability by making password creation difficult. To some extent, this may be a result of our harsh check that uses a cracking dictionary and matches words of any length, rather than ignoring words of less than three or four letters, as may be more typical. We believe, however, that what makes any dictionary check valuable - preventing the use of common or predictable letter strings in passwords—also makes it inherently more difficult for users to think of a valid password. An interface that more clearly explains to users why their passwords are being rejected and provides suggestions for avoiding future rejections might help to reduce frustration"

https://users.ece.cmu.edu/~lbauer/papers/2011/chi2011-passwo...

> * Require MFA

Using some kind of OTP authenticator app or device and __NOT__ SMS!

SMS is perfectly good as an additional authentication factor. i.e. When you log in on a new device using your user name and password, you also need to type in the text message code you were sent. It is a convenient way to strictly increase the security of an account.

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.

I guess you don't travel much. it's very common to have internet but not cell service (so no SMS). it's also common to buy a local sim so effectively no SMS or at least not the one you have registered.

So no, SMS is not perfectly good. it's crap and needs to die in a fire.

I used to travel a lot and the exact combination of no signal and internet was not frequent at all.

That heavily depends on where you travel. Even here in Southern California there are populated areas with little to no mobile internet service (like Big Bear Lake, Anza Borrego, or Joshua Tree areas for example)

And they still have internet available to travelers?

I've had wifi at the hotel/motel/lodge but no cell service before.

Depends

The other part was under another mobile system, say in another country. Can calls/texts find your phone today overseas at a reasonable price?

I know that frequencies are different in some parts.

No it isn't. If you lose your phone you are in for a world of hurt, let alone all the various ways there are to intercept/redirect SMS messages and/or entire mobile accounts. To say nothing of the fact that internet access is not yet globally ubiquitous, or if you forget to pay your bill, or all these other possibilities.

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.

The reason companies like Microsoft are basically calling for companies to stop relying on SMS is that it is just way too easy to compromise a phone number or a sim card and there are way too many people that get subjected to identity theft this way. Compared to other second factor options in the market, SMS is probably one of the worst ones precisely because operator security is so flawed.

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.

I think people also worry about the SIM card swap attack. Even if you have multiple ways to authenticate, RSA token, MFA app, and sms auth, the SIM card swap makes it way easier for someone else to have the thing only you should have.

You absolutely should lock your SIM always. SIM duplication is a thing.

Anything requiring my phone number or a binary that runs on my phone is a deal breaker for me. It has massive privacy implications.

We desperately need to have better MFA options if we're going to require it from users.

> or a binary that runs on my phone is a deal breaker

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.

MFA can't require me to run your specific app is a good guideline, though. It still leaves TOTP as fine, as long as I can choose my implementation.

FYI: https://en.wikipedia.org/wiki/Time-based_One-Time_Password

TOTP doesn’t meet the security requirements of higher trust level auth. You’re demonstrating why - storing your MFA with your first factor is pretty dumb.

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.

For average person there’s also the problem of recovering access in case the phone with OTP app is lost.

Every service of course has the option to print backup keys. Maintaining those (in secure offsite location) over years takes some effort.

> * Require more than 8 characters

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.

You’ve read it correctly.

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.

Yup. So many people mess this up, it's infuriating. U.S. banks are the worst.

Even outside of the U.S.

If you require as few as 9 characters, without requiring special characters, the security is poor. The reason is that users do not choose random strings of letters, so the entropy per character is low.

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.

So "fishyidea" has less or equal entropy to "262119"?

Neither fishyidea nor 262119 show up in haveibeenpwned's database, so they're at least uncommon. Neither of them look to have much entropy, though.

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.

I would say it has better entropy, but not by much.

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.

How to practically check for common passwords? Ideal would be to have like the most common 1/1000th of the hibp so that it's not too big for deployment in some clever structure (compressed trie? bloom filter?). I don't trust 3rd party services.

Have you heard about https://haveibeenpwned.com/Passwords ?

Sorry I reread and you said hibp so you know! Why not use the entire set?

Because it's 12.6GB compressed! That's just too large to deploy. I want a much smaller part. And I would prefer the actual passwords because I think they could be compressed much better than the (essentially random) hashes.

I got new worse policy in this November: at least 14 chars, must have all UPPER,lower,number,symbol chars, change every 3 months. Of course no MFA.

It's also interesting because NIST doesn't generally follow these rules, since they don't use passwords (at least for most things).

Ironically, most of the government doesn't adhere to these recommendations

> Require MFA

But allow at least 2 hardware keys and not only SMS.

Eight or more.

I believe in personal responsibility. If someone wants to use 1234 they should be allowed to.

America is strange, any rando nutjob should have access to firearms but US corporations are terrified of being sued.