20 ms·

NIST’s new password rules – what you need to know

• dbg31415 10y ago
  8 characters seems very short. I like asking people to pick 4 words and a number. Satisfies the length issues. But... I love emojis and other things being possibilities. Cool.
  • fryguy 10y ago
    They shouldn't pick 4 words, it should be randomly chosen for them.
    • syntheticnature 10y ago
      At which point, they hit reset password (either on that page, or on successive logins) until they get four words that stick trivially... because they're a normal sentence.
      • DenisM 10y ago
        Slow them down?
        • syntheticnature 10y ago
          To bend a cliche, users interpret things in their way as damage and route around it.
• lucaspiller 10y ago
  Recommending not expiring based on time is probably my favourite. I've worked at two places where that's been a requirement and my password has always been a passphrase combined with a sequencial number.
  • adrr 10y ago
    PCI compliance requires quarterly rotation of passwords and keys.
    • ddlatham 10y ago
      This recommendation may perhaps be a step to getting those compliance rules changed.
    • sib 10y ago
      Nothing better than rules based on bad data and security theater.
      • sp332 10y ago
        If your password is compromised, it will only work until the next reset. That's better than having one that works for years.
        • nitrogen 10y ago
          If your password is compromised, you've already lost. Since password rotation policies incentivize weak passwords, they are more likely to result in a compromised password. Thus, password rotation with weak passwords is not better than a single strong password that is never rotated.
          • phire 10y ago
            Now that I think about it "Don't worry about detecting attackers, they will get kicked out when we next rotate passwords" is not an attitude you want anyone to develop.
            • nitrogen 10y ago
              Plus, chances are pretty good that if they compromised one password undetected, they can compromise the next one in the same way (spear phishing, malware, etc.).
• rgaffpalm 10y ago
  Alas, Google forces me to use ASCII only passwords: https://support.google.com/a/answer/33386 https://support.google.com/a/answer/33386
• mylesm 10y ago
  Looks like some good suggestions: - Glad they're recommending a stop to the pointless "password must be no longer than (16, 20, ...) characters". Aren't you storing a constant-length hash anyway? - Why do some logins restrict which ASCII characters can be used? When I see that I can use any symbol from '%!#&' or whatever list they provide, I can only imagine it's a really naive SQL-injection defense. Is there any valid reason for this? - And glad to see they're recommending against "security challenges". Half the time I'm forced to pick a security question, either none of them apply, a bunch of them are ambiguous ("what's your favorite movie?" - uhh, I'll give you a different answer depending on my mood, etc.), or they're easily searchable ("where did you go to high school?") Unfortunately I doubt the bad actors will pay too much attention to this. I know Google is planning on dinging sites that don't use HTTPS, is it possible they could ding sites for poor password policies?
  • derefr 10y ago
    > Is there any valid reason for this? If they know that at some point they'll have to ask you to enter your password over a restricted input-method (e.g. on a DTMF keypad.)
    • Molomby 10y ago
      Real world example of this "limited input" problem: http://apple.stackexchange.com/questions/202143/i-included-emoji-in-my-password-and-now-i-cant-log-in-to-my-account-on-yosemite http://apple.stackexchange.com/questions/202143/i-included-e... Pre-Touch Bar, of course...
    • colanderman 10y ago
      Yep. FastMail restricts spaces in passwords due to mail clients that do not allow them.
      • kibwen 10y ago
        Which clients specifically?
      • 10y ago
• rdiddly 10y ago
  I'm no security expert, but I'm pleased to see several things being forbidden that in the back of my mind, I always thought were a little fishy.
• deleted 10y ago
  [deleted]
• alkonaut 10y ago
  If SMS isn't a recommended 2FA, do they recommend some other means of 2FA?
  • niftich 10y ago
    Many [1]. Some examples, my comments in parentheses: - Out-of-Band Authenticators (mobile app over secure channel) - Single Factor OTP Device (like an OATH push-button, enter 6-digit code TOTP device) - Single Factor Cryptographic Devices (insert into computer) (among others) [1] https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 https://pages.nist.gov/800-63-3/sp800-63b.html#sec5
    • tveita 10y ago
      Also "Single Factor Cryptographic Software", which I think means client certificates.
    • freehunter 10y ago
      Which is a real shame. SMS might not be perfect, but it's a real help when I don't have a better means handy. Its better than no 2FA, and it's saved my butt a few times when I get a text message saying "Here is your login code" and I'm out walking in the park. I get a new phone every year, and Google Authenticator sucks for that, but it's by far the second most common 2FA provider. I just got a new phone today, and had to go disable 2FA on all my accounts then re-enable it to generate a new code. SMS is always a good fallback in my experience.
      • JoshTriplett 10y ago
        > SMS might not be perfect, but it's a real help when I don't have a better means handy. Its better than no 2FA If used exclusively as a second factor, yes, it's better than nothing. However, many systems also allow you to use a phone as a password recovery system, which makes it much worse than no 2FA. Many people have had every account they own broken into, starting with a social-engineering call to their cell service to get their number moved to a new SIM/phone, followed by a reset of their email, followed by a reset of everything else.
• tveita 10y ago
  In addition to the standard salting and hashing, they recommend using an additional key stored separately from the data. > A keyed hash function (e.g., HMAC), with the key stored separately from the hashed authenticators (e.g., in a hardware security module) SHOULD be used to further resist dictionary attacks against the stored hashed authenticators. I guess using a pepper is a better-than-nothing measure, if you don't have a hardware security module.
• mschuster91 10y ago
  > and should accept all UNICODE characters, too, including emoji Hell no. This WILL lead to disaster, especially if people store their passwords in managers that may or may not mess up Unicode. UTF-8, for example, allows to encode the character "ä" as \xc3\xa4 OR \x61\xcc\x88. They look visually identical, yet fail any string comparison. Not to mention the support calls "I'm in $random_foreign_country and don't have $random_char on my keyboard, cannot login"... good luck trying to match the kitty emoticon on your Android phone to the random font on a website to whatever input system iPhone uses. Or when they're used a German Windows keyboard and suddenly have to use a German Mac - basic stuff like the tilde symbol ~, pipe symbol | or the (square) brackets {[]} are not marked out on the keyboard. I believe that it makes sense to display a warning "Your password may be impossible to type in another country/using a non-$current_platform keyboard" when such characters are encountered.
  • kibwen 10y ago
    > UTF-8, for example, allows to encode the character "ä" > [...] > I believe that it makes sense to display a warning Both of these are addressed in section 5.1.1.2: "If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply the Normalization Process for Stabilized Strings defined in Section 12.1 of Unicode Standard Annex 15 [UAX 15] using either the NFKC or NFKD normalization. Subscribers choosing memorized secrets containing Unicode characters SHOULD be advised that some characters may be represented differently by some endpoints, which can affect their ability to authenticate successfully." https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html
  • silverwind 10y ago
    > They look visually identical, yet fail any string comparison. That's a non-issue. You should normalize unicode strings to a common form (preferably NFC) before any comparision.
  • userbinator 10y ago
    Personally, I think passwords should be opaque sequences of bytes that just happen to be mostly easily input on a keyboard, but I agree with the warning: some might even consider such a warning a good thing.
• bahmboo 10y ago
  Password strength is meaningless when the password can be reset via an email provider that allows weak passwords.
  • foxylad 10y ago
    True. Google does a good job here - they support U2F (and other password hardening techniques), and additionally report any access from a new device. You do have to opt in to these measures, but at least they are available.
• ipunchghosts 10y ago
  How the f@@@ on the year 2016 we have a 64 character max length password requirement!!
  • kibwen 10y ago
    That's a minimum maximum requirement. It says that the password must be allowed to be at least 64 characters long, not that they be at most 64 characters long. Combined with the forbidding of composition rules and the demand that all ASCII and Unicode be allowed, 64 characters is more than enough.
  • elchief 10y ago
    If you allow unlimited length, that a DoS attack. Ask the devs at Django
    • sbuttgereit 10y ago
      For which they set a 4K limit on password length. I think even the commenter you replied to would find that satisfactory, being much more than 64 characters.
      • flukus 10y ago
        But what if I want the complete contents of war and peace to be my password?
        • sbuttgereit 10y ago
          You can't always get what you want But if you try sometimes well you might find You get what you need
      • oneeyedpigeon 10y ago
        It's pretty arbitrary when you get to 64, IMO. If a site enforces a maximum below that, I'll feel suspicious and treat the site as if it's storing my password in plain text; that maximum or higher reassures me that they probably know what they're doing. Of course, one day, a 64-character password will be brute-forceable in milliseconds, but we hopefully won't still be having this discussion by then!
• serge2k 10y ago
  The don'ts list is pretty much a christmas present from NIST. I hate all of those things. Worst is the stupid security questions.
  • cmurf 10y ago
    Apple still uses those and it annoys me. Yes, others still use them too, but I give Apple extra crap because I think they should know better by now but either they don't or don't care.
    • whyagaindavid 10y ago
      You can't change your existing password in apple if you forget your secret question/answer. I gave gibberish to these secret pet/school. Now I am unable to change my password ;-)
• mrmagooey 10y ago
  Aren't passphrases kind of a bad choice for passwords? If all you are ever really guessing is the symbols that make up someones password, and you know that for example they have 4 words that make the passphrase, then you effectively only have to iterate 4 symbols with a known list of possibilities for each symbol (i.e. the dictionary). If you compare the permutation space of a short passwords (length 7) with random characters (say ~80 potential symbols), with a long(er) password made up of 4 english words (say ~3000 potential symbols, the most commonly used english words). character_symbols = 80 word_symbols = 3000 number_of_character_password_symbols = 7 number_of_word_password_symbols = 4 permutation_space_characters = character_symbols**number_of_character_password_symbols permutation_space_words = word_symbols**number_of_word_password_symbols print('%.2E' % permutation_space_characters, '%.2E' % permutation_space_words) ('2.10E+13', '8.10E+13') The words space is four times bigger, but in the same magnitude as the short (bad) password. I'm not an expert here, so I might have stuffed it up, but it seems like passphrases shouldn't really be encouraged? I do love the recommendation to remove time-based password expiry though.
  • mark-r 10y ago
    How do you know how many words are in the passphrase?
    • mrmagooey 10y ago
      You don't I guess, I'm just using 4 as an example (it's also the number of words used in xkcd's password strength comic).
      • mark-r 10y ago
        I only ask because a different answer will change the math drastically.
        • paulmd 10y ago
          No it doesn't. Your password has as much entropy as it has, and no more. If you want to follow that train of thought to its logical conclusion, your attacker not only doesn't know the length of the password, they don't know what character sets make up the password either, and so you could claim that a 4-character numeric password is equally secure to a 64-character Unicode password. In fact by inductive reasoning 4-digit password could be said to have pretty much any finite amount of entropy, because how does the attacker know that it's not actually length N+1? Yes, the attacker not knowing exactly what the password class is (words/character set/length) does help somewhat in a practical sense. But it doesn't "change the math" at all, if you have 3000 symbols (words) and your password is 4 of them then you have 3000^4 possible passwords. You don't get to count passwords that are not in your password class as part of your entropy.
• yellow_postit 10y ago
  Glad to see the knowledge based questions are being phased out, many are sadly answerable with a cursory search query or leaked in previous breaches. I didn't see anything in there about security images/indicators, which have also been shown to be ineffective: "was this bank the image of the man snowboarding, or the woman skiing...?"
• riskable 10y ago
  The importance of this NIST standard cannot be understated. It has a requirement that passwords be hashed with a random salt! Microsoft Active Directory does not use salts! I am trying to imagine the consequences to all the businesses and agencies that must adhere to these standards suddenly coming to the realization that they must replace their Active Directory installations and what that will mean for administering all their Windows systems. It's not going to be pretty. You might be thinking, "but these are just guidelines!" Yes, but actually there's loads of existing business contracts with wording that states the business must adhere to all NIST (security) guidelines. Also, you can bet that once this gets finalized other standards will follow suit. It will be interesting to see what Microsoft does because salts were expressly not added to AD because so much functionality cannot work with random salts in place. They're going to have to break backwards compatibility with a lot of functionality and many 3rd party products that synchronize with AD. Entirely new APIs are going to need to be written. It will also become seriously annoying to create keytabs at large organizations since only domain admins will have that power once random salts are in place; making automation very difficult.
  • helper 10y ago
    Will requiring salts break ms-chap-v2?
  • jrochkind1 10y ago
    Presumably Microsoft would add a salt before losing all that business. Perhaps only if you turn on special NIST-mode, in the way of microsoft and backwards compatibility. It might break some functionality, but probably not as much as moving to an entirely different product if you have things written against MS APIs.
    • ckozlowski 10y ago
      This is a great example of how smart standards can leverage incredible pressure against vendors to adopt best practices. What will happen is that if the new standard is accepted as is, every single implimentation will have to craft a Plan of Action and Milestones (POAM), and every security officer is going to write in "Waiting for vendor fix". That's a lot of pressure on Microsoft to change this. Will it take time? Certainly. Years in fact. But if you want massive change, this is how you start. I'm a big fan of Active Directory. But I applaud this move. I'm even more excited to see if this will filter down to banks. Probably not as quickly, but one can hope.
• elchief 10y ago
  Seeing as NIST recommends PBKDF2 over bcrypt and scrypt should we assume that means NSA can crack PBKDF2 faster / more cheaply?
  • nerdy 10y ago
    This is the first thing I thought too. I've consistently heard the opposite but am not a cryptographer. The article Sophos links with regards to an explanation for choosing PBKDF2 over bcrypt or scrypt goes over numerous obviously bad practices like cleartext storage, then states the following, without further detail: We’ll recommend PBKDF2 here because it is based on hashing primitives that satisfy many national and international standards. This seems like a vague and probably misguided line of reasoning. What specifically would make that recommendation rational? bcrypt wasn't new in 2010 when NIST published the article recommending PBKDF2, and they haven't made the switch since. Dual_EC_DRBG was recommended by NIST in 2006 which makes me deeply skeptical of anything they say. If anyone could provide the motivation for choosing PBKDF2 in reasonably terms I'd appreciate it.
    • grangerg 10y ago
      The best motivation I've heard is here: http://security.stackexchange.com/a/17088/77002 http://security.stackexchange.com/a/17088/77002 Essentially, blowfish (Bcrypt) doesn't appear to be FIPS-compliant, so if you have to be FIPS-compliant, you use PBKDF2. And, considering the rest of the comments about why Bcrypt is preferred over PBKDF2, it appears it's all about how a GPU gives a significant speed-up for PBKDF2 but not Bcrypt. But now there are FPGAs that significantly speed up Bcrypt in similar fashion, so it could all be a wash depending on who you talk to.
• jrochkind1 10y ago
  > Applications must allow all printable ASCII characters, including spaces, and should accept all UNICODE characters, too, including emoji! Man, I predict a world of hurt here. Maybe it'll be okay if the standards also very prominently tell you you've got to unicode normalize before hashing, and tell you what normalization form to use (NFC I think?). Too many platforms/environments still don't have handy access to unicode normalization though.
  • TJSomething 10y ago
    It actually does: https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-verifiers https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-sec...
  • oneeyedpigeon 10y ago
    I can't wait until we all start using emojis in security answers: "What's your mother's maiden name?" "Smiley face - no, the one with the really big grin - man wearing turban - with the same skin colour as Obama - pile of poo, ..."
• ryanar 10y ago
  I love this. I despise the fact that my bank restricts passwords lengths to max 16 chars, hash lengths are constant, it is ridiculous. It is a BANK, if anything they should be more secure. Instead they force me to make passwords that easily fit a password mask by restricting special characters and forcing at least one number, uppercase letter, etc. They are actually weakening the security in a vain attempt to get people to make stronger passwords. All they do is make it P@$$w0rd instead, no increased security, it is so predictable I think disallowing SMS for 2FA will make it harder to get people to use it, if they finally decide to signup then they are informed they need an authenticator program. Also there have been times my phone was dead and I didnt have a backup plan.
  • danielpatrick 10y ago
    > there have been times my phone was dead and I didnt have a backup plan. This. Just recently this happened to me when I needed to get into my Gmail and I was shit out of luck. Didn't have my phone on me. The best Gmail would do was some sort of account reset that would take 2+ days (for good reason). I was entirely locked out, no solution short of returning home to get my phone. Anyone recommend a solid backup plan?
    • binarycrusader 10y ago
      In the Google case you can print a set of backup codes. See the security page under your account.
• koolba 10y ago
  What's the only thing worse / stupider / more annoying than secret questions? Secret questions that don't even have a free form text box for the answer! That means you can't even put random text in them. You have to select from a pre-canned list of 5-10 options. Good riddance!
• huilee 10y ago
  FAL3 is not used in LOA- seems like it won't be used much.
• known 10y ago
  I use passwords from https://www.random.org/passwords/?num=4&len=8&format=html&rnd=new https://www.random.org/passwords/?num=4&len=8&format=html&rn...
• dcosson 10y ago
  I've written into several companies in the past saying "your password policy are bad for __ reason", and they always of course write back saying basically "our security team doesn't care, shut up". There've been quite a few times I've cancelled accounts right after signing up because of just how absurd they were (for instance I believe Trade King forces you to click type your password with the mouse on an on-screen keyboard just in case you have a keylogger malware). It's great that there's now a "right answer", and it seems to be based on some solid research about what actually helps and what doesn't. In a similar vein I wish there were somehow a standard for http login and change password requests. Right now password managers are pretty hit or miss about whether they can actually fill a form and log you in, sometimes it just can't find the right field, sometimes there's a javascript field check of some sort so you have to click into the field after the password manager fills it before you can submit, etc. Having some kind of a standard would let you more reliably be able to automate logging in, rotating all passwords (at least on accounts without MFA), etc.
  • tjbiddle 10y ago
    There's not "Now a 'right answer'" NIST standards have been around for a while; the companies you've mentioned are just even more arrogant idiots than you originally thought :-)
  • vbezhenar 10y ago
    Given that password autofill built in all browsers, it should be part of HTML, IMO. Something like <form login><input type="text" name="username" username><input type="password" name="password" password></form>
• brownbat 10y ago
  > Knowledge-based authentication (KBA) is out. All the rules are great, but this one might be my favorite. Every time I faced a list of KBAs I felt like I was trapped in UCB's comedy sketch: https://www.youtube.com/watch?v=tMEjpXJZgIA https://www.youtube.com/watch?v=tMEjpXJZgIA (If a common security device is bad enough for a comedy troupe to have a bit on it, maybe it could use some work.) The worst KBAs I've seen are for United's frequent flyer program. Almost every question is of the form "What is your favorite X?" X includes items like "vegetable" or "summer sport." Maybe most people have strong opinions about the superiority of broccoli and tubing, but I was always just scratching my head. (The questions were mandatory and you could not write your own.)
  • Freak_NL 10y ago
    Yes, my mother's maiden name is Een3oquu+P_a9oez0queiPhaeChaijoh, why do you ask? Ironically, you usually can enter a string as answer to those questions that is more secure than the allowed password.
    • brownbat 10y ago
      You'd think. United gives you a drop down with around ten common answers to choose from. If you happen to have a favorite vegetable, but it's, say, the daikon, you're out of luck.
    • TorKlingberg 10y ago
      And then you call phone support and they ask you for it.
      • chris_wot 10y ago
        Amazing how we don't allow support to know the password, but the security question answers that allow access - that' fine! If I had to break in to an account, I'd choose one that used recovery questions. That'S far easier than cracking a password.
      • pluma 10y ago
        "I just entered a string of random characters." "That is correct. Thank you."
• mightybyte 10y ago
  > Knowledge-based authentication (KBA) is out Finally! This is my biggest beef. I've taken to generating long random strings as answers to these questions but in some cases that's insecure too because they present you with a multiple choice set of answers and then it's obvious. Also glad they're getting rid of ridiculous composition rules, hints, and password expiration.
• selljamhere 10y ago
  Relevant xkcd: https://xkcd.com/936/ https://xkcd.com/936/
• ipsin 10y ago
  I would love to see an explicit recommendation of "no disabling paste" in the NIST standard... so that I can contact companies that do so and drive me nuts. The article implies that disabling paste would run afoul of the NIST standards, but is there actual language I could point to?
  • pluma 10y ago
    I would sure hope so. I managed to convince a company to allow paste in their login form by tweeting them this article: https://www.troyhunt.com/the-cobra-effect-that-is-disabling/ https://www.troyhunt.com/the-cobra-effect-that-is-disabling/ But I doubt most companies would be this reasonable if they have this level of stupid in their password handling.
• esseti 10y ago
  Question: how do you store data encryption key for each user? because: - you get the password form the user - compute the PBKDF2 with iteration and a salt, store iteration$salt$hash (where hash is the result of the PBKDF2 on the password). - when user logs in check that the hash matches the PBKDF2 on password with iteration and salt. But now, i've a the data enccryption key (DEK) and i've to store it somewhere. I can't use the password directly to encrypt the DEK since the lenght must be 32 (or 16, or 24). I should use PBKDF2 to derive a 32 byte hash, but this value is already stored in the password_hashed field. Should I compute anoterh PBKDF2 with a different salt and a different iterations for the encryption of DEK? if so i'll store in the db just$iterations and encryption and apply those to the password (after the user logs in) to derive an encryption key for the DEK? What's a good approach?
• anjanb 10y ago
  Password max length should be minimum 64 chars as specified in https://pages.nist.gov/800-63-3/sp800-63b.html#aal_privacy https://pages.nist.gov/800-63-3/sp800-63b.html#aal_privacy. We want to know what compliance levels apply for the above rule in an enterprise product. Anyone knows where I can find compliance levels for Products targeted for Enterprise customers ?
• shthed 10y ago
  Also systems should always notify users if their password or email address has been changed, immediately alerting that they've been compromised. 2factor authentication is great so you always know if someone is attempting to login as you.
• Unkechaug 10y ago
  What are the alternatives to SMS two factor authentication? Software like Authy? Even if it's easy to get around SMS wouldn't utilities like Authy also have vulnerabilities, or is the idea that at least they can be patched?