Verifiers SHOULD NOT prevent users from pasting secrets from the keyboard.
Banks: this is to prevent attacker use keylogger or mouse position logger.
I was like, are you fucking serious ?
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.
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.
Honest question since I want a solution to that problem. I want separate credentials for my home and office computer so even though I use a password manager I have like 3-4 sensitive passwords I have to keep in my head.
My office computer has a relatively weak password because there's nothing on it that is personally sensitive. They force a password change every three months so I added a counter to the password and just increment that each time (pa$$1word, pa$$2word, pa$$3word, etc...).
A determined adversary can do things like lift a fingerprint from elsewhere and use that, but it's not really something I worry about too much. They could also arrest me and press my finger down on the sensor or beat me and I'll tell them every password I can.
I mostly worry about having strong credentials to remote systems.
I would imagine in the "real world" outside strict culture fit requirements that a certain percentage of passwords will be popular bible verses, for example.
There's a curve where the likelihood of collision or predictability is very high with short passwords and it declines with length until it starts increasing again.
I used to use full engineering parts numbers of semiconductors I used in projects. I also used some verbose API names that I used a lot. In retrospect that's a terrible idea. I wonder how many people sitting next to me used the same password.
Was it "Live long and prosper" or "He's dead, Jim"? The latter seems more suitable given the circumstances :)
I actually looked it up: 1,1A(bunch more stuff here)000Destruct0 it was kinda long. From memory that movie even displayed it on the screen so the guys used the same capitalization and everything.
https://www.schneier.com/blog/archives/2014/03/choosing_secu...
The main point from his essay is anything that can be remembered can be hacked. He then softens that statement to show a way to take your memorable phrase and turn it into something stronger.
Most of the time these days we're talking about online services or devices where there are practical limitations (or software limitations) imposed on how quickly we can "guess" a password. This is the most important use of passwords, their strength within a hash should be a concern of the proprietor rather than the user.
Specifically using a salt + pepper, and a hashing algorithm that can be made computationally expensive (or use some other finite computing resource like a lot of memory or even GPU power).
> This is why the oft-cited XKCD scheme for generating passwords -- string together individual words like "correcthorsebatterystaple" -- is no longer good advice. The password crackers are on to this trick.
Them being "on to this trick" doesn't defeat it. It is mathematically stronger. The US-English keyboard has 100 common characters on it. A eight year old child knows over 2,600 words. The key to an "XKCD password" is that one letter in a "random" password must be equal to about half a word in an XKCD-style password (e.g. 8 characters = 4 words, 6 characters = 3 words, and so on).
So:
"12345678" (8 chars)
"OneTwoThreeFour" (4 words)
Are equally as secure (still terrible passwords, but the maths works out). That's because, assuming a "bad guy" knows your trick, the search space is much MUCH larger for an XKCD style password than a traditional password.
Schneier is just mistaken, word-based passwords assuming a reasonable length almost always perform better than random characters, and the maths shows that pretty steadily. We ASSUME a bad guy knows what we're doing, that's a given, but again it is still a much harder task for a bad guy even with perfect intelligence.
Maybe there is a difference between what is supposed to be protected. The login to some server based server? Or something I use locally like my tax files.
He wanted to rant and therefore didn't read the description of the "xkcd scheme" with enough concentration to understand it.
Legions of security people debunked Schneier, but unfortunately he didn't have it in him to retract his claim and update his post.
This blog post is the best example you can give of Schneier quitting academic discourse and becoming a pundit.
If you make a password from an alphabet of 64 characters (upper and lower case, digits, and some special characters), there are 6 bits per character of entropy so a ten character random password could have 60 bits of entropy.
If you are choosing words from a list 4000 words long, there are 11 bits of entropy per word and so you would need to string together five random words to get a password of equal strength. The big problem then is having enough space to type that many characters.
Edit: that's a pretty nice slide deck. Thanks for the pointer.
Since I still run into services where the "forgot password" mechanism emails your current password in the clear, this is unfortunately not as true as one would hope.
Personally, I'd rather bet on something like Diceware.
[0]http://www.lingholic.com/how-many-words-do-i-need-to-know-th...
Some words are way more common than others, and they are much more likely to be found in your passphrase if you didn't use an external random index generator (be it a set of dice or /dev/urandom), because of availability bias: you're more likely to chose common words, or even worse, uncommon words pertaining to your interests.
Diceware uses a smaller set (about 8K words), but if you select them truly randomly, you'll get close to 13 bits of entropy per word —guaranteed. I wouldn't cry too much over the loss of 2 bits per word, because Diceware words tend to be short.
Then again, even a word in a grammatically correct sentence is likely to have more than the 6-7 bits of entropy a character may have. I wouldn't bet on anything above 10, though.
I've heard the average entropy of English is 3 bits/character, in which case 14-15 bits sounds about right for a word.
91 characters, in 21 words. 4.3 characters on average, which would mean 13 bits of entropy. I don't believe it. It sounds like your source didn't account for word frequencies in real sentences, let alone grammatical constraints.
So just random words and half-words are appended, like: 'misfortune behold oratory plexum'
Then again, these things tend to just stick very well in my mind, so it may not be appropriate for everyone. Also, I only need to do this on certain services, so it's not that many to remember.
The hard part is when they then reply with "requires at least one upper case character, number, symbol, etc.". A certain XKCD comic comes to mind...
Lorem ipsum random garbage 1
Is there anyone reading this who has chosen to implement such limits? If so, why?
I haven't, but here's one answer I got from someone who did.
The bizarre password requirements at $WORK have the property that, sometimes, a subset of a password will be permitted when the full password would not be. I contacted our IT department once with a specific example of an objectively weak password which was accepted, and a stronger password (at least, it contained the weaker password as a strict subset) which was rejected. I proposed a concrete, simple-to-implement suggestion for how to relax the rules to avoid this kind of paradox. (I don't remember what it was.)
He agreed with me that this was an undesireable outcome, and that my proposal was implementable. However, he said that the institution would nonetheless not implement it, because people were used to the old rules, and would be confused if they changed.
(When I asked how people could be confused if all the old passwords were still acceptable, and the only change was that new, stronger passwords also became acceptable, he stopped responding.)
I feel like underlying all of this, there's a lagging perception that "spaces and special characters are hard". But when all you're doing is hashing them... they're really really not. Whenever I hit a max length limitation, I'm automatically assuming that particular password is being kept in plaintext.
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.
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%.
[1] https://doc.satoshilabs.com/trezor-faq/threats.html#brute-fo...
Back in my time in the military, there was an online portal that held your service information, the ability to request leave (time off), pay, etc. It was the place to go if you needed information aside from a paystub.
It required 8 char min, two upper, two lower, two special char (from a predefined list), and passwords would expire every 30 days. The thing is, most people knew all of their service info off of the top of their head. People also weren't requesting leave very often either, so most people would have to change their password on every login from some bullshit permutation of keyboard rolling with numbers and special chars tacked onto the end.
All that being said, you only had 3 attempts before lockout. No one wanted to risk lockout, so you'd make a throwaway password and reset it if you wanted to login. If you were locked out, it was a call to a civilian contractor with a hold time of 10-30 minutes just to get a temporary password emailed to you.
One of the easiest ways to fuck with someone was to intentionally lock out their account. It was trivial to find someone's username via searching through the email global address list. Then you pull up the portal, enter their user, smash the keyboard, and cackle as you have cost that person a guaranteed 10 minutes minimum just to do something trivial like print something from their file.
I wonder why this didn't establish in the first place...
Meanwhile, you can issue multiple simultaneous requests in parallel to try to authenticate the credentials, possibly from a large bank of distinct hosts.
Do human users authenticate faster than once a second?
On a full sized keyboard, the normal rate is 3.3 key presses per second. On a mobile device, I'm sure an 8 character password will take far more than 1 second.
For brute force attack defense, rate limiting a single account globally to 1/sec, i.e. independent of source IP address, should be sufficient and prevent parallel attacks by bots, but this still makes DOS attacks on a particular account easy, but not the entire system except traditional overload.
Many API systems work this way and it's proven effective.
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.
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.
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.
> > 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.
Not in the case the hashes are leaked. However I agree very much with what you said otherwise.
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?)
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.
So the answer is: Some are already doing that.
I think that can be read two ways.
1) 100 failed attempts/account/month 2) 100 failed attempts/IP/account/month
The latter still limits an attacker but is less likely to be a plausible DoS against the account unless the attacker has compromised the legitimate user's machine at which point all is lost anyway. Later in the same section:
> When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts from the same IP address.
Which suggests the failure count is per IP and not per account.
No, security is tough. The better security the less useful it is. NIST got this right. Do what you can, don't kill the user and implement security on the aaa side.
I was specifically addressing the DoS vulnerability of locking an organization out en masse by taking advantage of account lockout or timeout policy. A list of emails and a six line script could take a whole company offline.
MFA can be used to address that by requiring pre-auth before you can enter a password.
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.
Actual OTP should allow you to print out or write down a set of codes.
That's way different from "I don't want to give out my phone number".
"I have a phone number but don't want to give it out" is different than "I don't have a phone".
But hey, there are 2FA devices you can use instead.
Nobody gives a shit about low trust environments... go ahead and crack my slashdot account, but higher trust stuff like mail, money, network access etc absolutely need MFA.
Also, there is little evidence that entropy increases all that much when you force users to choose very long passwords.
Totally agree. I often encounter problems that go like this:
UltraSecureSystem: Create a secure password.
Me: "#@(J #!_04';/1~"
UltraSecureSystem: Password must be at least 8 characters long, can't include special characters and consists of at least one upper case letter, one lower case letter and one number.
Me: "Password0"
UltraSecureSystem: Congratulations, your ultra secure password created!
<After 1 month>
UltraSecureSystem: Your password has expired, create a new ultra secure password.
Me: "Password1"
UltraSecureSystem: Congratulations, your totally new and totally secure password created!
(Although this time I had a unique experience where I adjusted quite quickly from "2" to "3" and because I was still thinking "don't forget to incrememnt" ended up typing "4". Uggggghhhhhhhhhh)
pls don't hack me
As the implementer, I've argued many times about it, but the ITSec bods always think they know best.
Their website lists a lot of different potential applications, but I use it almost exclusively for entering passwords from KeePass. In addition to allowing password entry on the computer's lock screen, it also saves me the trouble of having to read and retype passwords manually on computers that don't have KeePass installed, and avoids exposing my entire password database to the computer it's plugged into (as would be the case if I used portable KeePass on a USB memory stick).
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.
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
I'm cautiously hopeful that this will supply needed ammunition for those advocating for saner password rules and policies in organizations big and small.