14 ms·
Operative bit in 5.2.2: "Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets. Verifier
by 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 agoPity they only went for 8 characters, though.
- henvic 10y agoYou 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 agoThen consider this a rate limit with average of 3.3 attempts per day over a 30 day period.
- henvic 10y agoExcept 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 agoYou mitigate that by putting MFA in front.
- kbart 10y agoMFA 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 agoA security key should work.
- CiPHPerCoder 10y agoYou 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 agoScanning a QR code by hand is easy when you don't have the phone handy. (sarcasm) Actual OTP should allow you to print out or write down a set of codes.
- CiPHPerCoder 10y ago> Scanning a QR code by hand is easy when you don't have the phone handy. (sarcasm) That's way different from "I don't want to give out my phone number".
- user5994461 10y agoBoth are impossible when not having a phone.
- iopq 10y agoRate limiting seems like a good application of neural networks. Find out when hackers tried a lot of passwords and when users tried a lot of passwords. Run that data through a model and you can get a model that changes as hackers change their attack methods. Although you'll have to manually classify hacking attempts vs. real users.
- Spooky23 10y agoRate limiting is better than lockout. Other federal agencies (IRS in particular) require lockouts with only 3 bad password attempts. That generates really high reset/unlock call volume -- easily 20-30% of users require intervention or reset compared to 7-12%.
- mulmen 10y agoCan you explain those numbers? 7-12% of what? Are you suggesting that rate limiting reduces call volumes by a little more than half compared to lockouts? Where did you get the data?
- ajkjk 10y agoI think s/he's saying that rate limiting leads to fewer password resets compared to lockouts. Which makes sense.
- Spooky23 10y agoIn one large, diverse environment I'm familiar with, that policy spiked the need for intervention (password resets, unlocks, etc). That spikes costs. Many users (mobile) need to call someone, which is $$$. Those interventions also lead to things like figuring out what app stored password is relocking the account. That kind of exercise could cost a few hundred bucks. ...all for zero benefit.
- rrobukef 10y agoHeh, I often have more than 3 wrong password attempts. Lockout is a really bad idea for me.
- richmarr 10y agoContext is also relevant. The iPhone for example has a PIN lockout, and young kids love phones. More than once I've been punished by Apple for my kids curiosity.
- 10y ago
- semi-extrinsic 10y ago> This is prone to a DoS attack. When will we see the first organization (government or private) that is effectively completely DoS'ed for days on end because their login does this, while all their email addresses are listed on their website? If sustained, I imagine this could shut down an entire organization quite effectively for a few days. Probably could lose someone millions. Or add insult to injury, and have them pay BTC for the attack to stop.
- jessaustin 10y agoSuch an organization might investigate the use of stored tokens so that all users don't have to be authenticated simultaneously.
- henvic 10y agoSometimes I definitely scare my coworkers just by caring about such edge cases. They probably think I use foil hat at home :)
- johnward 10y agoWhen I am limited to only 8 characters it's always a bank account.
- mathgeek 10y agoI've found the best way to get around this limit is to give the account information to my payroll department and then never access it.
- JadeNB 10y ago> I've found the best way to get around this limit is to give the account information to my payroll department and then never access it. Maybe I don't understand, but isn't the issue not your access to it, but others'? If you are forced to have a weak password protecting sensitive information, then it's an issue even if you never need to access that information yourself. (Or maybe you mean that you never even establish the account, and hence the weak password, in the first place?)
- mathgeek 10y agoMerely wordplay on leaving your money in an account and letting it accumulate. Was continuing on the "8 character limit in my bank account" double meaning.
- eriknstr 10y ago>rate limiting (see 5.2.2) should take care of most concerns about it. Not in the case the hashes are leaked. However I agree very much with what you said otherwise.
- bo1024 10y ago> 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. I agree. Nobody is going to guess a good password in 100 attemps, or 100,000,000 attempts. A tiny bit of rate-limiting, like one login attempt/second, should be enough to prevent successful brute force on good passwords. The threat is hacking the database of hashes and brute-forcing offline.
- samirm 10y ago8 is nowhere near good enough.
- kibwen 10y agoThat'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 agoIf 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 agoForced 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 agoI 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 agoThe 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 agoI 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 agoThey 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 agoIf uniqueness is a goal, why not just use UUIDv4?
- malka 10y agoboth uniqueness and easiness of memorization are important here
- criddell 10y agoI 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 agoI wish they'd also added: Verifiers SHOULD NOT prevent users from pasting secrets from the keyboard.
- sleavey 10y agoI'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 agoPressing F12 and modifying the DOM usually works as well.
- paulddraper 10y agoNext is custom screen keyboards made with <canvas>
- jmah 10y agoUsually this is accomplished by blocking the keyboard shortcut; pasting via right-click menu typically works.
- gmiller123456 10y agoActually, 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.