11 ms·

NIST best practice recommendations state: * Require more than 8 characters * Don't require special characters * Don't force the user to reset their password

• ben0x539 5y ago
  > * 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.
  • beermonster 5y ago
    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.
• yread 5y ago
  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.
  • quickthrower2 5y ago
    Have you heard about https://haveibeenpwned.com/Passwords https://haveibeenpwned.com/Passwords ?
    • quickthrower2 5y ago
      Sorry I reread and you said hibp so you know! Why not use the entire set?
      • yread 5y ago
        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.
• dheera 5y ago
  > Require MFA But allow at least 2 hardware keys and not only SMS.
• crooked-v 5y ago
  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.
  • stjohnswarts 5y ago
    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.
  • jliptzin 5y ago
    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.
    • ptk 5y ago
      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.
      • jliptzin 5y ago
        For my CitiBusiness account, not my personal accounts
  • kibwen 5y ago
    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.
• bsid 5y ago
  Yup. So many people mess this up, it's infuriating. U.S. banks are the worst.
  • beermonster 5y ago
    Even outside of the U.S.
• 63 5y ago
  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.
  • kylebyproxy 5y ago
    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?
    • MomoXenosaga 5y ago
      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.
      • johannes1234321 5y ago
        > 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.)
• colinclerk 5y ago
  Disclosure: I am the cofounder https://www.clerk.dev 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 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).
  • amanzi 5y ago
    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.
    • colinclerk 5y ago
      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.
    • Jeff_Brown 5y ago
      But even if you didn't read all of it, and just required longer passwords instead of special characters, you'd be improving things.
      • amanzi 5y ago
        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.
• tomc1985 5y ago
  > * Require MFA Using some kind of OTP authenticator app or device and __NOT__ SMS!
  • dahfizz 5y ago
    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.
    • tomc1985 5y ago
      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.
    • klhutchins 5y ago
      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.
    • greggman3 5y ago
      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.
      • 5y ago
• starwind 5y ago
  Ironically, most of the government doesn't adhere to these recommendations
• MomoXenosaga 5y ago
  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.
• cactus2093 5y ago
  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.?
  • jaywalk 5y ago
    Big companies have big bureaucracies and third-party auditors that define stuff like this. Getting them to change their requirements is a herculean task.
  • skeaker 5y ago
    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!"
  • er4hn 5y ago
    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-approach 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.
  • 5y ago
• deleted 5y ago
  [deleted]
• pbreit 5y ago
  Eight or more.
• fomine3 5y ago
  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.
• rkeene2 5y ago
  It's also interesting because NIST doesn't generally follow these rules, since they don't use passwords (at least for most things).
• kazinator 5y ago
  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.
  • genewitch 5y ago
    So "fishyidea" has less or equal entropy to "262119"?
    • thefifthsetpin 5y ago
      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.
    • kazinator 5y ago
      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_list 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#Top_English_words_lists 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.