23 ms·

New NIST password guidelines: don't require character types or rotation

642 points by aaronharnly 10y ago

labster 10y ago
"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." I had not even thought about normalization before in this context, but I could see it being an issue if a user moves to a new device. But what if new composed characters are added to Unicode, does that mean the user can no longer log in with NFC passwords? I guess that K in NFKC is important.
- lmm 10y ago
  NFC decomposes composed characters that were not present in the first version of Unicode, for precisely this reason.
aaronharnly 10y ago
Operative bit in 5.2.2: "Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise of the authenticator or a subscriber requests a change." I'm cautiously hopeful that this will supply needed ammunition for those advocating for saner password rules and policies in organizations big and small.
- vacri 10y ago
  Pity they only went for 8 characters, though.
  - henvic 10y ago
    You are not forced to use 8 only on most places. And most of the time 8 is good enough. And by forcing more characters you may end up messing things up because people can start using patterns that defies the very core idea why there should be a 'minimum length'. And rate limiting (see 5.2.2) should take care of most concerns about it. Though, I think this is bad > Unless otherwise specified in the description of a given authenticator, the verifier SHALL effectively limit online attackers to 100 consecutive failed attempts on a single account in any 30 day period. Well, imho there MUST be no limit. This is prone to a DoS attack. Rate limiting and other things MUST be able to solve this one way or another.
    - cstejerean 10y ago
      Then consider this a rate limit with average of 3.3 attempts per day over a 30 day period.
      - henvic 10y ago
        Except this is a rate limiting on the account globally, and here lies the DoS problem. So if you follow it you can theoretically have your account locked down by an idiot on the other side of the world. You can minimize this by making it per IP, for example. So, you'd have to have an idiot on your home. Yeah, maybe this is not 100% bullet proof given IPv6 and so on, but at least this doesn't introduce a vector for DoS.
        Spooky23 10y ago
        You mitigate that by putting MFA in front.
        kbart 10y ago
        MFA is not a magic solution to all problems either. You can't expect me to give my phone number or real email address to every random site I login into.
        petters 10y ago
        A security key should work.
        CiPHPerCoder 10y ago
        You don't need to do that for HOTP/TOTP though. 1. Scan a QR code. 2. You now have a secret value that can generate a deterministic pseudorandom integer securely indefinitely. Also, SMS-based MFA should be burned to the ground.
        AstralStorm 10y ago
  - kibwen 10y ago
    That's only the absolute minimum length that a password may be, not the recommended length. But yes, I do agree that it's a small shame that it's not at least slightly longer. Other than that these rules look great.
  - joelthelion 10y ago
    If you have strong hashing that makes it costly to brute force passwords, I think this should be enough for most users. Also, there is little evidence that entropy increases all that much when you force users to choose very long passwords.
- beedogs 10y ago
  Forced periodic password change has got to be near the top of the list in terms of the dumbest things the IT world has blindly gone along with in the past decade. Glad NIST finally agrees with me on this.
  - dimino 10y ago
    I think that's unfair! It makes sense on first glance, right? People can't steal your password if it changes all the time. I personally find it unintuitive to think that people would give up on the "memorization" part if it became "too hard". It's true, and we know this from study, but to say it's "dumb" is unfair.
    - Twisell 10y ago
      The only password I need to write on a paper near my computer is of a client that require periodic change over his Vpnssl every 1 month. When connecting to it I must type it 3 different time in a context where password manager don't work. After a year of trying to keep track of the changes via a secured method (and at least 12 call to their IT so they reset the password without any identity check on their part) I finally resigned and write it down on paper and write the new one every time they ask me to change. Bonus fun fact : Theses idiots also truncated password at 8 characters but truncated in different manners on the 3 login steps required so it's only after 4-5 failed attempts at a secured corectbatterystapplehorse that I understood that weak password was mandatory by their rules... PS: And of cour rotation between Passwd1 passwd2 passwd3 passwd4 (then back to 1) was perfectly accepted and considered as safe
    - Qwertystop 10y ago
      I ended up memorizing my home's old WEP key simply because, since I was the "tech guy" in the family, everyone would ask me whenever they needed to add a device (never mind that I was mostly just going to the password booklet and reading it out). Eventually I just stopped needing to look it up. I've since used it in some places, blended with a mnemonic for the specific site. 10 hex characters plus a string might not be the highest-security thing, but at least it's not going to fall to anything less than brute-force.
- logicallee 10y ago
  They should settle on requiring a memorable, yet high entropy password that is impossible to conpromise. For example the string "IpromiseIamauthorizedtoaccessthissystem". This string is very high-entropy (does not appear anywhere in Google, is 9 words, a mixture of upper and lowercase. For someone trying every character combination, it would take over a thousand years to crack. It includes a second factor (the promise) by definition. In short it should be the REQUIRED secure password for all applications.
  - dublinben 10y ago
    >does not appear anywhere in Google It does now! This is why it's so important to use a method like diceware to select a strongly random set of words for your passphrase.
    - deleted 10y ago
      [deleted]
    - ricardobeat 10y ago
      If uniqueness is a goal, why not just use UUIDv4?
      - malka 10y ago
        both uniqueness and easiness of memorization are important here
        criddell 10y ago
        I have one passphrase that I've memorized and that gets me into my password manager. I couldn't tell you any of my passwords other than that one. I also use two factor authentication in the form of TOTP (the 6 digit number that changes every 30 seconds) wherever I can. If so many sites didn't have a limit on password length, I would use UUIDs. BTW, is there any reason to have a short limit on password length? I'm talking less than 20 characters? I could understand limiting it to 100 characters, but when it's short it makes me feel like the site might be storing my password rather than a hash.
- CWuestefeld 10y ago
  I wish they'd also added: Verifiers SHOULD NOT prevent users from pasting secrets from the keyboard.
  - sleavey 10y ago
    I've seen banks do this, and I agree it's incredibly annoying. KeePassX's autotype function bypasses copy-and-paste restrictions, since it emulates the keyboard as it types your password.
    - nommm-nommm 10y ago
      Pressing F12 and modifying the DOM usually works as well.
    - paulddraper 10y ago
      Next is custom screen keyboards made with <canvas>
      - chikei 10y ago
        You're allow only to input using their custom screen keyboard AND randomize the position of each key. Banks: this is to prevent attacker use keylogger or mouse position logger. I was like, are you fucking serious ?
        rolandog 10y ago
        Shh... don't give them any ideas.
  - jmah 10y ago
    Usually this is accomplished by blocking the keyboard shortcut; pasting via right-click menu typically works.
  - gmiller123456 10y ago
    Actually, no. This is about "memorized secrets", not "secrets stored somewhere else". That's not to say that secrets stored somewhere else can't be better than passwords in certain situations, they're just a different type of authentication. A password is "something you know", and stored password is "something you have". Some systems are required to use different types of authentication, one thing you know, one thing you have, and one thing about you (e.g. fingerprint/retina scan). Allowing a copy and paste from a different source violates the "something you know" requirement.
hug 10y ago
Previous related discussion around these rules here: https://news.ycombinator.com/item?id=13016948 https://news.ycombinator.com/item?id=13016948
ht85 10y ago
Good to see that after all this time dodging corporate pressure to implement counter-productive measures, the guidelines themselves have changed for the best :)
TwoBit 10y ago
I never understood thecidea of having to change my password periodically. The password was good last month, why isn't it good now?
- Spooky23 10y ago
  It isn't about password hacking. It's a control to limit the scope of people sharing or otherwise compromising passwords within the office. It happens, all of the time.
  - shakna 10y ago
    Wouldn't it encourage people to write down their passwords and leave them in plain sight? Increasing shared passwords within an office space?
  - gregmac 10y ago
    Except it doesn't help with that, at all. Many people use predictable rotations (incrementing number, date appended), so if you know one, you know them all. Also if they've shared it once, why would they not share it again? Put another way: why is making them regularly reset their password going to make them suddenly follow security protocol, when it didn't the last n times they had to change their password? If the office thinks it's okay to share their password it's also a symptom of several things: * Lax security environment, with not enough emphasis on security training and importance. * Poor senior management. There should be reprimands for violating security rules, as severe as losing your job for repeat offenders, and obviously IT can't do this on their own. * Bad work environment provided by IT. Why are they sharing passwords to begin with? Maybe the environment is overly locked-down with too many restrictions, or maybe the collaboration tools are just bad or missing. Fix those, the password sharing stops.
    - vbezhenar 10y ago
      It's trivially solved by comparing new password to all previous passwords and decline if they are similar. And if they wrote their passwords on the stickers, they should be explained that it's not appropriate. I agree that this approach is not very user-friendly.
known 10y ago
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... FTW
- dimino 10y ago
  I prefer the passphrase: https://xkcd.com/936/ https://xkcd.com/936/ Also, I feel very funny using generated password from a website. If I need a new password, I can just generate one in Python or something.
  - e12e 10y ago
    I have this macro saved in ipython. Note that I use a subset of symbols that's easy to type on most(?) keyboard layouts withoutany gymnastics: %load pwm import random as r import string as s def pw(n=12): return "".join([r.choice( s.ascii_letters \ + s.digits \ + "|!@#$%&/()=?+\-_.,;:") for x in range(n)])
    - apk17 10y ago
      ruby -e 'rand(34*10).to_s(34)' I prefer not to have to use the shift key in passwords, and the 34 instead of 36 ([0-9a-z]) solves my german/us layout problem in a very golfy way.
      - dchest 10y ago
        Both your and parent's password generators are not secure: they use non-cryptographic random number generators, which have limited entropy.
        vidarh 10y ago
        That matters very little if you are manually generating an occasional password here and there for personal and an attacker have no reason to know your specific method of generating the password.
Dylan16807 10y ago
That code points are counted as a single character is absolutely mandatory, but there's no requirement to allow passwords over 6 characters? Interesting choices.
deleted 10y ago
[deleted]
bdamm 10y ago
This part is very good advice: When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list of known commonly-used, expected, and/or compromised values. So, no rotation, no character set rules, but the password better not be already known. They specifically refer to comparing against a corpus of known broken passwords. Very good.
- shandor 10y ago
  The same got my attention too. A really great idea, though I'm not aware of it being used currently at all. It might be, but I've never come across/heard anyone mentioning it. Hopefully this takes root! Actually, couldn't privacy-caring service providers also check current passwords against newly-leaked lists in case something pretty big gets disclosed and warn their affected users? Would probably take some time for services with big amount of users, but that would be some awesome help to users who use same passwords in most places.
  - jsjohnst 10y ago
    Not sure if they still use it, but Tumblr blocked setting your password to a common password in the past. (Source: I wrote the feature)
  - gmac 10y ago
    I've been implementing this on secure sites for about ten years.
  - bdamm 10y ago
    Cracklib has been around for ... years. https://github.com/cracklib/cracklib https://github.com/cracklib/cracklib
- glandium 10y ago
  How long before this advice triggers someone to create a service to test passwords against a known corpus with a nice API, and, worse, people using it?
guelo 10y ago
At my publicly traded company I was told that they have to do password rotation because of Sarbanes Oxley. Is there any truth to that?
- dragonwriter 10y ago
  I'm less specifically familiar with SarbOx details than HIPAA, but I suspect the former, like the latter, requires sexurity processes that address particular issues and your institution has adopted procedures (possibly from a third-party canned set) to satisfy those that require rotation. A lot of "required by HIPAA" mythology has this origin, and what I understand of SarbOx is that it's generally similar in this regard.
  - witty_username 10y ago
    > sexurity Typo?
    - vidarh 10y ago
      Some security processes do feel a bit like bdsm.
- phonon 10y ago
  Most (virtually all) of these rules "chain-up" to what NIST says is best practice. So when NIST does a final update, (the above is just a draft of their new standards) EVERYONE(-ish) will follow (eventually).
cmurf 10y ago
"Memorized secrets that are randomly chosen by the CSP (e.g., at enrollment) or by the verifier (e.g., when a user requests a new PIN) SHALL be at least 6 characters..." Does this include credit/debit card PINs? "Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets." I take it this proscription applies to the actual passphrase, not as part of an account reset mechanism? If so, that's too bad, I really don't like these questions let alone the storage of the answer. Are these answers secrets though? If so, send like it's proscribed, and also they have to be salted and hashed in which case the answer itself isn't being stored.
peterjlee 10y ago
I'm not sure if accepting unicode characters is a good idea. It would make it more secure but you can very easily get locked out of your own account if you try to login from another device without the correct input method. Here's one extreme example of it: "I included emoji in my password and now I can't log in to my Account on Yosemite"(https://news.ycombinator.com/item?id=10742351 https://news.ycombinator.com/item?id=10742351)
- tuwtuwtuw 10y ago
  A somewhat similar issue appears with Bitlocker in Windows. When you set your password you are using your custom Windows keyboard layout, such as sv-SE (Swedish). But then when you are prompted to enter your password during boot to decrypt your computer the keyboard is always en-US. It's fun figuring out how to type Swedish and special characters on a foreign keyboard layout. Of course no part of the UI indicates this layout issue. I think Unicode is good. I think companies should fix their broken input instead.
  - loup-vaillant 10y ago
    Shame on Microsoft, then. My Ubuntu Linux laptop was installed with the default settings for full disk encryption, and it uses my favourite layout right there at boot time.
    - nikcub 10y ago
      A BIOS is 7bit ASCII - if you want anything more than that you need to load a ramdisk with drivers. If you're loading a ramdisk with drivers then you may as well also load a keylogger. You'd also need to recreate that ramdisk if your hardware fails, and good luck booting from non-root encrypted volumes. Using EN-US for boot disk volumes is pretty good advice. Microsoft have thought this through - their recovery keys are ASCII numerals only and are entered using function keys since they're the only universal keys. edit: relevent Technet: https://technet.microsoft.com/en-us/library/ee449438(v=ws.10).aspx#BKMK_Key https://technet.microsoft.com/en-us/library/ee449438(v=ws.10...
nicois 10y ago
pwgen
SeanDav 10y ago
> "When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list of known commonly-used, expected, and/or compromised values." This has to be applied to the whole password (which it implies anyway) or you end up with the rather silly situation which I encountered the other day when I had to create a temporary password for a Microsoft service. It absolutely refused to accept even a very secure password if there was a portion that was not secure. For example: a password similar to "$4(password(!monsT3rDiet%@" was rejected. But if I removed the word "password" and made the string shorter (and therefore less secure), that was okay!
kutkloon7 10y ago
Finally some common sense in guidelines (appearently, some people need guidelines for this stuff because they have no common sense).
torbjorn 10y ago
>Unicode [ISO/ISC 10646:2014] characters SHOULD be accepted as well. So, can passwords contain emojis under these guidelines?
- AstralStorm 10y ago
  Why not 8-) Hey, I've got all the ASCII character classes. Must make it a good password. The only problem is actually typing in those, most keymaps lack support.
- theandrewbailey 10y ago
  Yes. The larger the character space, the better. In fact, even today, I'm astounded by services that let me set passwords with "high" ASCII characters, like íÑVTx¾]õ^ÖcÉ^x½0ÞØý½
Angostura 10y ago
This bit caught my attention: >Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets. I wonder if Mastercard and Visa will reconsider this policy.
- yellowapple 10y ago
  I can't wait for my credit union to heed these guidelines.
  - nommm-nommm 10y ago
    My old credit union required your password to be exactly six (6) characters with one upper case and one special character. They then added in "2FA" over phone or SMS. One day I clicked the "forgot password" link and was able to reset my password using only SMS bypassing the password part entirely. Not even a verification email.
    - closeparen 10y ago
      Could you actually transit money from online banking? I've found this to rarely be the case, and when it is there are additional verification steps / notifications that give you a chance to stop it (if it's a new payee).
- pwg 10y ago
  Wait? You mean you answer those questions with real data? My answers to those (when required) always look like this: > “What was the name of your first pet?” JBK?a0ly(VE3E-|-@BADZFPS<1Fh$X23 Where the "goop" is generated, and remembered, by my password manager (https://github.com/zdia/gorilla/wiki https://github.com/zdia/gorilla/wiki).
  - detaro 10y ago
    You really think if I call in trying to impersonate you and that question comes up the customer service person is going to require me to recite that and not accept "Oh, I just put some random garbage in" as a solution? Something that seems like a realistic answer, but is totally wrong is likely a better choice.
protonfish 10y ago
Wait, 10,000 iterations of the has function? That's surprising, and of questionable value.
- alltakendamned 10y ago
  Yes, at least. _and_ in combination with a slow hashing function such as PBKDF-2, where the current recommendation for server side hashing is 100K+ iterations. The workload is ideally set to something that is acceptable to users, but considerably slows down brute-force attempts by attackers. Please educate yourself some more before making statements on the value of things that surprise you, they might be there for a good reason.
  - Pxtl 10y ago
    Doesnt this leave your auth system very vulnerable to DDOS?
    - alltakendamned 10y ago
      Well, the calculation of the hash on the server side will of course also be a tiny bit slower, but this will seldom significantly increase the risk of application level DDOS, also because you can size the machines according to your needs. Also, even 10s of thousands of iterations are very fast (run `openssl speed` to get an idea). See this more as a mechanism to introduce 8-10 ms delay for every password check. This will delay the attacker, but shouldn't bring down a server. This does not have any impact on network-level DDOS scenarios. In short, in password authentication, slower is better.
    - KayEss 10y ago
      Only if you don't also implement the limiting that is also described.
  - protonfish 10y ago
    The brute force would have to be on a raw database dump, and is probably in no rush to complete. Also, speed being hardware dependent, the attacker could simply get more, or wait for the advance of Moore's law so that what was "slow" last year is now fast. Deliberately slow hashing is just shouting into the wind. Your comment about "please educate yourself" was not constructive.
discreditable 10y ago
They also discourage biometric use: https://pages.nist.gov/800-63-3/sp800-63b.html#biometric_use https://pages.nist.gov/800-63-3/sp800-63b.html#biometric_use
vog 10y ago
Obligatory XKCD on this topic: "Password Strength" https://xkcd.com/936/ https://xkcd.com/936/
OliverJones 10y ago
It says "SHALL be generated using an approved random bit generator." What are some examples? debian /dev/urandom? dotnet RNGCryptoServiceProvider? others? Who approves this stuff? Does anybody know?
- SparkyMcUnicorn 10y ago
  Edit: Confirmed info here http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP... Source: https://www.nist.gov/news-events/events/2016/05/random-bit-generation-workshop-2016 https://www.nist.gov/news-events/events/2016/05/random-bit-g...
stefek99 10y ago
5.1.1.2. Memorized Secret Verifiers I prefer plain English aka "passwords"
- lemtzas 10y ago
  I like the implications of "pass phrase"
kasbar 10y ago
EsraaAsem
rconti 10y ago
Super relevant because today I got the annual reminder to check my Social Security statement online. Go to login, password expired. Expires every 6mo. Also, requires punctuation. I type in a typical strong/long password and it says "weak" until I append ! to the end and magically now it's "STRONG!"
Tostino 10y ago
Interestingly enough, I just recently released a password strength library which can help enforce these exact requirements. https://github.com/GoSimpleLLC/nbvcxz https://github.com/GoSimpleLLC/nbvcxz
deleted 10y ago
[deleted]
rphlx 10y ago
They appear to be dangerously unaware of modern memory-hard PBKDFs such as Argon2, winner of the https://en.wikipedia.org/wiki/Password_Hashing_Competition https://en.wikipedia.org/wiki/Password_Hashing_Competition

642 points by aaronharnly 10y ago

"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." I had not even thought about normalization before in this context, but I could see it being an issue if a user moves to a new device. But what if new composed characters are added to Unicode, does that mean the user can no longer log in with NFC passwords? I guess that K in NFKC is important.

lmm 10y ago
NFC decomposes composed characters that were not present in the first version of Unicode, for precisely this reason.

aaronharnly 10y ago

Operative bit in 5.2.2: "Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise of the authenticator or a subscriber requests a change." I'm cautiously hopeful that this will supply needed ammunition for those advocating for saner password rules and policies in organizations big and small.

vacri 10y ago
Pity they only went for 8 characters, though.
- henvic 10y ago
  You are not forced to use 8 only on most places. And most of the time 8 is good enough. And by forcing more characters you may end up messing things up because people can start using patterns that defies the very core idea why there should be a 'minimum length'. And rate limiting (see 5.2.2) should take care of most concerns about it. Though, I think this is bad > Unless otherwise specified in the description of a given authenticator, the verifier SHALL effectively limit online attackers to 100 consecutive failed attempts on a single account in any 30 day period. Well, imho there MUST be no limit. This is prone to a DoS attack. Rate limiting and other things MUST be able to solve this one way or another.
  - cstejerean 10y ago
    Then consider this a rate limit with average of 3.3 attempts per day over a 30 day period.
    - henvic 10y ago
      Except this is a rate limiting on the account globally, and here lies the DoS problem. So if you follow it you can theoretically have your account locked down by an idiot on the other side of the world. You can minimize this by making it per IP, for example. So, you'd have to have an idiot on your home. Yeah, maybe this is not 100% bullet proof given IPv6 and so on, but at least this doesn't introduce a vector for DoS.
      - Spooky23 10y ago
        You mitigate that by putting MFA in front.
        kbart 10y ago
        MFA is not a magic solution to all problems either. You can't expect me to give my phone number or real email address to every random site I login into.
        petters 10y ago
        A security key should work.
        CiPHPerCoder 10y ago
        You don't need to do that for HOTP/TOTP though. 1. Scan a QR code. 2. You now have a secret value that can generate a deterministic pseudorandom integer securely indefinitely. Also, SMS-based MFA should be burned to the ground.
        AstralStorm 10y ago
- kibwen 10y ago
  That's only the absolute minimum length that a password may be, not the recommended length. But yes, I do agree that it's a small shame that it's not at least slightly longer. Other than that these rules look great.
- joelthelion 10y ago
  If you have strong hashing that makes it costly to brute force passwords, I think this should be enough for most users. Also, there is little evidence that entropy increases all that much when you force users to choose very long passwords.
beedogs 10y ago
Forced periodic password change has got to be near the top of the list in terms of the dumbest things the IT world has blindly gone along with in the past decade. Glad NIST finally agrees with me on this.
- dimino 10y ago
  I think that's unfair! It makes sense on first glance, right? People can't steal your password if it changes all the time. I personally find it unintuitive to think that people would give up on the "memorization" part if it became "too hard". It's true, and we know this from study, but to say it's "dumb" is unfair.
  - Twisell 10y ago
    The only password I need to write on a paper near my computer is of a client that require periodic change over his Vpnssl every 1 month. When connecting to it I must type it 3 different time in a context where password manager don't work. After a year of trying to keep track of the changes via a secured method (and at least 12 call to their IT so they reset the password without any identity check on their part) I finally resigned and write it down on paper and write the new one every time they ask me to change. Bonus fun fact : Theses idiots also truncated password at 8 characters but truncated in different manners on the 3 login steps required so it's only after 4-5 failed attempts at a secured corectbatterystapplehorse that I understood that weak password was mandatory by their rules... PS: And of cour rotation between Passwd1 passwd2 passwd3 passwd4 (then back to 1) was perfectly accepted and considered as safe
  - Qwertystop 10y ago
    I ended up memorizing my home's old WEP key simply because, since I was the "tech guy" in the family, everyone would ask me whenever they needed to add a device (never mind that I was mostly just going to the password booklet and reading it out). Eventually I just stopped needing to look it up. I've since used it in some places, blended with a mnemonic for the specific site. 10 hex characters plus a string might not be the highest-security thing, but at least it's not going to fall to anything less than brute-force.
logicallee 10y ago
They should settle on requiring a memorable, yet high entropy password that is impossible to conpromise. For example the string "IpromiseIamauthorizedtoaccessthissystem". This string is very high-entropy (does not appear anywhere in Google, is 9 words, a mixture of upper and lowercase. For someone trying every character combination, it would take over a thousand years to crack. It includes a second factor (the promise) by definition. In short it should be the REQUIRED secure password for all applications.
- dublinben 10y ago
  >does not appear anywhere in Google It does now! This is why it's so important to use a method like diceware to select a strongly random set of words for your passphrase.
  - deleted 10y ago
    [deleted]
  - ricardobeat 10y ago
    If uniqueness is a goal, why not just use UUIDv4?
    - malka 10y ago
      both uniqueness and easiness of memorization are important here
      - criddell 10y ago
        I have one passphrase that I've memorized and that gets me into my password manager. I couldn't tell you any of my passwords other than that one. I also use two factor authentication in the form of TOTP (the 6 digit number that changes every 30 seconds) wherever I can. If so many sites didn't have a limit on password length, I would use UUIDs. BTW, is there any reason to have a short limit on password length? I'm talking less than 20 characters? I could understand limiting it to 100 characters, but when it's short it makes me feel like the site might be storing my password rather than a hash.
CWuestefeld 10y ago
I wish they'd also added: Verifiers SHOULD NOT prevent users from pasting secrets from the keyboard.
- sleavey 10y ago
  I've seen banks do this, and I agree it's incredibly annoying. KeePassX's autotype function bypasses copy-and-paste restrictions, since it emulates the keyboard as it types your password.
  - nommm-nommm 10y ago
    Pressing F12 and modifying the DOM usually works as well.
  - paulddraper 10y ago
    Next is custom screen keyboards made with <canvas>
    - chikei 10y ago
      You're allow only to input using their custom screen keyboard AND randomize the position of each key. Banks: this is to prevent attacker use keylogger or mouse position logger. I was like, are you fucking serious ?
      - rolandog 10y ago
        Shh... don't give them any ideas.
- jmah 10y ago
  Usually this is accomplished by blocking the keyboard shortcut; pasting via right-click menu typically works.
- gmiller123456 10y ago
  Actually, no. This is about "memorized secrets", not "secrets stored somewhere else". That's not to say that secrets stored somewhere else can't be better than passwords in certain situations, they're just a different type of authentication. A password is "something you know", and stored password is "something you have". Some systems are required to use different types of authentication, one thing you know, one thing you have, and one thing about you (e.g. fingerprint/retina scan). Allowing a copy and paste from a different source violates the "something you know" requirement.

hug 10y ago

Previous related discussion around these rules here: https://news.ycombinator.com/item?id=13016948 https://news.ycombinator.com/item?id=13016948

ht85 10y ago

Good to see that after all this time dodging corporate pressure to implement counter-productive measures, the guidelines themselves have changed for the best :)

TwoBit 10y ago

I never understood thecidea of having to change my password periodically. The password was good last month, why isn't it good now?

Spooky23 10y ago
It isn't about password hacking. It's a control to limit the scope of people sharing or otherwise compromising passwords within the office. It happens, all of the time.
- shakna 10y ago
  Wouldn't it encourage people to write down their passwords and leave them in plain sight? Increasing shared passwords within an office space?
- gregmac 10y ago
  Except it doesn't help with that, at all. Many people use predictable rotations (incrementing number, date appended), so if you know one, you know them all. Also if they've shared it once, why would they not share it again? Put another way: why is making them regularly reset their password going to make them suddenly follow security protocol, when it didn't the last n times they had to change their password? If the office thinks it's okay to share their password it's also a symptom of several things: * Lax security environment, with not enough emphasis on security training and importance. * Poor senior management. There should be reprimands for violating security rules, as severe as losing your job for repeat offenders, and obviously IT can't do this on their own. * Bad work environment provided by IT. Why are they sharing passwords to begin with? Maybe the environment is overly locked-down with too many restrictions, or maybe the collaboration tools are just bad or missing. Fix those, the password sharing stops.
  - vbezhenar 10y ago
    It's trivially solved by comparing new password to all previous passwords and decline if they are similar. And if they wrote their passwords on the stickers, they should be explained that it's not appropriate. I agree that this approach is not very user-friendly.

known 10y ago

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

dimino 10y ago
I prefer the passphrase: https://xkcd.com/936/ https://xkcd.com/936/ Also, I feel very funny using generated password from a website. If I need a new password, I can just generate one in Python or something.
- e12e 10y ago
  I have this macro saved in ipython. Note that I use a subset of symbols that's easy to type on most(?) keyboard layouts withoutany gymnastics: %load pwm import random as r import string as s def pw(n=12): return "".join([r.choice( s.ascii_letters \ + s.digits \ + "|!@#$%&/()=?+\-_.,;:") for x in range(n)])
  - apk17 10y ago
    ruby -e 'rand(34*10).to_s(34)' I prefer not to have to use the shift key in passwords, and the 34 instead of 36 ([0-9a-z]) solves my german/us layout problem in a very golfy way.
    - dchest 10y ago
      Both your and parent's password generators are not secure: they use non-cryptographic random number generators, which have limited entropy.
      - vidarh 10y ago
        That matters very little if you are manually generating an occasional password here and there for personal and an attacker have no reason to know your specific method of generating the password.

Dylan16807 10y ago

That code points are counted as a single character is absolutely mandatory, but there's no requirement to allow passwords over 6 characters? Interesting choices.

deleted 10y ago

[deleted]

bdamm 10y ago

This part is very good advice: When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list of known commonly-used, expected, and/or compromised values. So, no rotation, no character set rules, but the password better not be already known. They specifically refer to comparing against a corpus of known broken passwords. Very good.

shandor 10y ago
The same got my attention too. A really great idea, though I'm not aware of it being used currently at all. It might be, but I've never come across/heard anyone mentioning it. Hopefully this takes root! Actually, couldn't privacy-caring service providers also check current passwords against newly-leaked lists in case something pretty big gets disclosed and warn their affected users? Would probably take some time for services with big amount of users, but that would be some awesome help to users who use same passwords in most places.
- jsjohnst 10y ago
  Not sure if they still use it, but Tumblr blocked setting your password to a common password in the past. (Source: I wrote the feature)
- gmac 10y ago
  I've been implementing this on secure sites for about ten years.
- bdamm 10y ago
  Cracklib has been around for ... years. https://github.com/cracklib/cracklib https://github.com/cracklib/cracklib
glandium 10y ago
How long before this advice triggers someone to create a service to test passwords against a known corpus with a nice API, and, worse, people using it?

guelo 10y ago

At my publicly traded company I was told that they have to do password rotation because of Sarbanes Oxley. Is there any truth to that?

dragonwriter 10y ago
I'm less specifically familiar with SarbOx details than HIPAA, but I suspect the former, like the latter, requires sexurity processes that address particular issues and your institution has adopted procedures (possibly from a third-party canned set) to satisfy those that require rotation. A lot of "required by HIPAA" mythology has this origin, and what I understand of SarbOx is that it's generally similar in this regard.
- witty_username 10y ago
  > sexurity Typo?
  - vidarh 10y ago
    Some security processes do feel a bit like bdsm.
phonon 10y ago
Most (virtually all) of these rules "chain-up" to what NIST says is best practice. So when NIST does a final update, (the above is just a draft of their new standards) EVERYONE(-ish) will follow (eventually).

cmurf 10y ago

"Memorized secrets that are randomly chosen by the CSP (e.g., at enrollment) or by the verifier (e.g., when a user requests a new PIN) SHALL be at least 6 characters..." Does this include credit/debit card PINs? "Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets." I take it this proscription applies to the actual passphrase, not as part of an account reset mechanism? If so, that's too bad, I really don't like these questions let alone the storage of the answer. Are these answers secrets though? If so, send like it's proscribed, and also they have to be salted and hashed in which case the answer itself isn't being stored.

peterjlee 10y ago

I'm not sure if accepting unicode characters is a good idea. It would make it more secure but you can very easily get locked out of your own account if you try to login from another device without the correct input method. Here's one extreme example of it: "I included emoji in my password and now I can't log in to my Account on Yosemite"(https://news.ycombinator.com/item?id=10742351 https://news.ycombinator.com/item?id=10742351)

tuwtuwtuw 10y ago
A somewhat similar issue appears with Bitlocker in Windows. When you set your password you are using your custom Windows keyboard layout, such as sv-SE (Swedish). But then when you are prompted to enter your password during boot to decrypt your computer the keyboard is always en-US. It's fun figuring out how to type Swedish and special characters on a foreign keyboard layout. Of course no part of the UI indicates this layout issue. I think Unicode is good. I think companies should fix their broken input instead.
- loup-vaillant 10y ago
  Shame on Microsoft, then. My Ubuntu Linux laptop was installed with the default settings for full disk encryption, and it uses my favourite layout right there at boot time.
  - nikcub 10y ago
    A BIOS is 7bit ASCII - if you want anything more than that you need to load a ramdisk with drivers. If you're loading a ramdisk with drivers then you may as well also load a keylogger. You'd also need to recreate that ramdisk if your hardware fails, and good luck booting from non-root encrypted volumes. Using EN-US for boot disk volumes is pretty good advice. Microsoft have thought this through - their recovery keys are ASCII numerals only and are entered using function keys since they're the only universal keys. edit: relevent Technet: https://technet.microsoft.com/en-us/library/ee449438(v=ws.10).aspx#BKMK_Key https://technet.microsoft.com/en-us/library/ee449438(v=ws.10...

nicois 10y ago

pwgen

SeanDav 10y ago

> "When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list of known commonly-used, expected, and/or compromised values." This has to be applied to the whole password (which it implies anyway) or you end up with the rather silly situation which I encountered the other day when I had to create a temporary password for a Microsoft service. It absolutely refused to accept even a very secure password if there was a portion that was not secure. For example: a password similar to "$4(password(!monsT3rDiet%@" was rejected. But if I removed the word "password" and made the string shorter (and therefore less secure), that was okay!

kutkloon7 10y ago

Finally some common sense in guidelines (appearently, some people need guidelines for this stuff because they have no common sense).

torbjorn 10y ago

>Unicode [ISO/ISC 10646:2014] characters SHOULD be accepted as well. So, can passwords contain emojis under these guidelines?

AstralStorm 10y ago
Why not 8-) Hey, I've got all the ASCII character classes. Must make it a good password. The only problem is actually typing in those, most keymaps lack support.
theandrewbailey 10y ago
Yes. The larger the character space, the better. In fact, even today, I'm astounded by services that let me set passwords with "high" ASCII characters, like íÑVTx¾]õ^ÖcÉ^x½0ÞØý½

Angostura 10y ago

This bit caught my attention: >Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets. I wonder if Mastercard and Visa will reconsider this policy.

yellowapple 10y ago
I can't wait for my credit union to heed these guidelines.
- nommm-nommm 10y ago
  My old credit union required your password to be exactly six (6) characters with one upper case and one special character. They then added in "2FA" over phone or SMS. One day I clicked the "forgot password" link and was able to reset my password using only SMS bypassing the password part entirely. Not even a verification email.
  - closeparen 10y ago
    Could you actually transit money from online banking? I've found this to rarely be the case, and when it is there are additional verification steps / notifications that give you a chance to stop it (if it's a new payee).
pwg 10y ago
Wait? You mean you answer those questions with real data? My answers to those (when required) always look like this: > “What was the name of your first pet?” JBK?a0ly(VE3E-|-@BADZFPS<1Fh$X23 Where the "goop" is generated, and remembered, by my password manager (https://github.com/zdia/gorilla/wiki https://github.com/zdia/gorilla/wiki).
- detaro 10y ago
  You really think if I call in trying to impersonate you and that question comes up the customer service person is going to require me to recite that and not accept "Oh, I just put some random garbage in" as a solution? Something that seems like a realistic answer, but is totally wrong is likely a better choice.

protonfish 10y ago

Wait, 10,000 iterations of the has function? That's surprising, and of questionable value.

alltakendamned 10y ago
Yes, at least. _and_ in combination with a slow hashing function such as PBKDF-2, where the current recommendation for server side hashing is 100K+ iterations. The workload is ideally set to something that is acceptable to users, but considerably slows down brute-force attempts by attackers. Please educate yourself some more before making statements on the value of things that surprise you, they might be there for a good reason.
- Pxtl 10y ago
  Doesnt this leave your auth system very vulnerable to DDOS?
  - alltakendamned 10y ago
    Well, the calculation of the hash on the server side will of course also be a tiny bit slower, but this will seldom significantly increase the risk of application level DDOS, also because you can size the machines according to your needs. Also, even 10s of thousands of iterations are very fast (run `openssl speed` to get an idea). See this more as a mechanism to introduce 8-10 ms delay for every password check. This will delay the attacker, but shouldn't bring down a server. This does not have any impact on network-level DDOS scenarios. In short, in password authentication, slower is better.
  - KayEss 10y ago
    Only if you don't also implement the limiting that is also described.
- protonfish 10y ago
  The brute force would have to be on a raw database dump, and is probably in no rush to complete. Also, speed being hardware dependent, the attacker could simply get more, or wait for the advance of Moore's law so that what was "slow" last year is now fast. Deliberately slow hashing is just shouting into the wind. Your comment about "please educate yourself" was not constructive.

discreditable 10y ago

They also discourage biometric use: https://pages.nist.gov/800-63-3/sp800-63b.html#biometric_use https://pages.nist.gov/800-63-3/sp800-63b.html#biometric_use

vog 10y ago

Obligatory XKCD on this topic: "Password Strength" https://xkcd.com/936/ https://xkcd.com/936/

OliverJones 10y ago

It says "SHALL be generated using an approved random bit generator." What are some examples? debian /dev/urandom? dotnet RNGCryptoServiceProvider? others? Who approves this stuff? Does anybody know?

SparkyMcUnicorn 10y ago
Edit: Confirmed info here http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP... Source: https://www.nist.gov/news-events/events/2016/05/random-bit-generation-workshop-2016 https://www.nist.gov/news-events/events/2016/05/random-bit-g...

stefek99 10y ago

5.1.1.2. Memorized Secret Verifiers I prefer plain English aka "passwords"

lemtzas 10y ago
I like the implications of "pass phrase"

kasbar 10y ago

EsraaAsem

rconti 10y ago

Super relevant because today I got the annual reminder to check my Social Security statement online. Go to login, password expired. Expires every 6mo. Also, requires punctuation. I type in a typical strong/long password and it says "weak" until I append ! to the end and magically now it's "STRONG!"

Tostino 10y ago

Interestingly enough, I just recently released a password strength library which can help enforce these exact requirements. https://github.com/GoSimpleLLC/nbvcxz https://github.com/GoSimpleLLC/nbvcxz

deleted 10y ago

[deleted]

rphlx 10y ago

They appear to be dangerously unaware of modern memory-hard PBKDFs such as Argon2, winner of the https://en.wikipedia.org/wiki/Password_Hashing_Competition https://en.wikipedia.org/wiki/Password_Hashing_Competition