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.
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.
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.
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.
This is an excellent approach. In addition, I recommend adding pithy terms of service to the end so that the holder can sue anyone who steals the password. You'd be surprised how many black-hats are deterred by the threat of prosecution.
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.
If you only have the password to your password manager, how do you log on to your computer?
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 laptop has a fingerprint sensor that I use. There is a backup password but I don't know what it is but I do have it in my password manager that I can access from my phone.
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...).
I might be wrong, but I believe a fingerprint is equivalent to around 80 bits of entropy which is roughly the strength of a good 13 character password.
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.
The problem with long passwords and "culture fit employees" is at a former employer root passwords were mostly never used (magic of sudo, kerberos, etc) and were stored in sealed envelopes in a semi-secured lockbox, and during the inevitable outage it was comically discovered two star trek fans configured two machines to the same trek quote as a password.
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.
I believe it was one of the numerous starship self destruct codes, which also technically passes the usual hoops of letters and numbers and mixed case and punctuation.
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.
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.
> The general attack model is what's known as an offline password-guessing attack.
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.
But he starts with saying the file can be processed offline. And I wonder, if one gets the "password" file to be processed offline, why can't he simply get the data too?
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.
After reading through most of that, it seems that the big problem with the XKCD scheme is that it's often impractical. Too many sites restrict password length and so you are forced to use the Schneier modification to get more entropy per character.
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.
Yep, unfortunately for passphrases the maximum acceptable password length on web sites tends to be the #1 factor limiting their use. I created sample passphrases and tried them on a handful of different sites to measure the problem. See starting slide 31 in this presentation (PDF): http://www.passwordresearch.com/files/How%20Secure%20Are%20M...
Do you know why sites would set a low limit? I can understand limiting to, say, a couple hundred characters, but 16 is ridiculous. These days, all anybody is going to store is a salted hash so the passphrase length should be mostly irrelevant.
Edit: that's a pretty nice slide deck. Thanks for the pointer.
> These days, all anybody is going to store is a salted hash so the passphrase length should be mostly irrelevant.
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.
One little problem with your passphrase is, it's grammatically correct. If the attacker suspects as much, this will dramatically reduce the search space.
Personally, I'd rather bet on something like Diceware.
At very least that is more secure than a random 9 character password and much easier to remember. 9 words to the power of 20k[0] compared to 9 letters to the power of 52 (random case).
You're right, it's much better, but the entropy of an English word is nowhere near log2(20K) (between 14 and 15 bits of entropy), especially in a grammatically correct sentence, because you're simply unlikely to select them truly randomly.
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.
> You're right, it's much better, but the entropy of an English word is nowhere near log2(20K) (between 14 and 15 bits of entropy), especially in a grammatically correct sentence, because you're simply unlikely to select them truly randomly.
I've heard the average entropy of English is 3 bits/character, in which case 14-15 bits sounds about right for a word.
I'm not sure your average English word has as much as five characters on average. Okay, let's count this paragraph.
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.
I agree the way you describe is even better. That said if the previous posters password isn't enough entropy for your use case some form of 2 factor auth should come into play as well.
I tend to do manual "diceware"-passphrase generation when I need to (i.e. I cannot use my password manager for any reason).
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...
I get a special character (space), lower case, upper case, and numbers. Change the number for rotation, it works if they don't search for short Hamming distances. Worked at my last gig.
Not so much. Too many sites arbitrarily block spaces and impose maximum lengths. Other character exclusions are all too common as well, though not relevant to this pattern
Is there anyone reading this who has chosen to implement such
limits? If so, why?
> 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.)
Thanks for the reply. Sounds like another case of "we've always done it this way".
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.
Max length limits can also be imposed by actual cryptographic hashes. (8-char limits are admittedly implausible.) For example, bcrypt is generally considered a good idea for storing passwords, but has a length limit of somewhere around 55 bytes (http://security.stackexchange.com/questions/39849/does-bcryp... for details).
Chosen to impose a maximum length? No (though I would probably limit to 4k just to have some kind of sanity limit - if you don't define a limit then your system still has a practical limit, it just doesn't fail gracefully when you hit it). Had to implement a maximum length for compatibility with a legacy system? Yes.
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.
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%.
Yes, and I like the approach that Trezor takes [1] for 4-digit PINs where the wait time increases by power of two. Also adding 2-factor authentication increases the security even on weaker passwords.
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 meant the wait time increase. If I don't like you (or am just a jerk in general), I'll just write a script to automatically retry 0000 after the lockout period. I'm not trying to break into your account; I'm just hassling you with a DoS attack.
Surely DOS would only be an issue if the service literally sat there doing nothing for that period of time? Isn't the solution here just to reject all requests for that period of time doing the absolute minimum processing required?
Not DOS against the entire service, against a targeted user not being able to access the server (because you just entered a wrong password often enough that the system blocks his valid log-in attempts).
Both of you are correct, just talking about different things. PBKDF2 rounds are clearly sequential.
Meanwhile, you can issue multiple simultaneous requests in parallel to try to authenticate the credentials, possibly from a large bank of distinct hosts.
Assuming a web page, does the page reload in less than 1 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.
It's pretty meaningless to say "this is rate limiting not lock-out" when the rate limit is a ~7 hour wait between attempts. Many lock-outs automatically unlock faster than that! The comment you are replying to is correct, this is a DoS vector.
I worked for a State government about 10 years ago. Some asshole managed to lock every single user's account by having a script attempt a login with an invalid password 10 times. Nobody could work for ~7 hours.
Can 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?
In 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.
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.
> 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?)
Merely 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.
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.
Most of the time when I see large scale password cracking attempts against customer servers, I have to block large blocks because they're coming from large number of IPs. I had to block most of South Korea at one point, because we saw abusive traffic from millions of IPs belonging to a couple of major ISPs in South Korea (thankfully non of our customers had much if any legitimate traffic from outside Europe at the time).
> 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
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.
MFA is basically another key|password. If I am not careful with my secret key and password what difference does it make that there are two of them?
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.
Have you ever messed with a friend by locking out their phone?
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.
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.
This is why I'm a big fan of the U2F standard, which allows a device (generally a small USB/NFC device) to generate shared secrets for arbitrary services without exposing any personal information.
Think about this problem in context with the NIST trust level framework.
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.
That's my point. MFA itself is certainly a very useful security solution (for example, I wouldn't trust a bank that doesn't use it), but "MFA everywhere" is not a way to go, because I value my privacy more than some useless Internet account.
Rate 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.
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.
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.
"Forced periodic password change has got to be near the top of the list in terms of the dumbest things"
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!
Tip: Some systems only remember your last 3 or 10 passwords, so it's worth rotating up to Password9 and then coming back to Password0. Tip given by my boss who received it by his chain of command of old people who couldn't remember the password change. True story.
I'm not sure that it makes much difference whether I reset to 0 or keep going through 10 and up. My biggest frustration is that every password change I'll mistype my closing digit for about a week before muscle memory gets the new one right,
(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)
... and then you get locked out because your domain controller (or whatever) is set up to ban you after ~3 invalid login attempts in a row. Happened to me once.
Which is why in a lot of corporate systems, the password history is set to 13 last passwords. a) it prevents a 0-9 rotation, and b) it also prevents people rolling passwords based on month name or number.
Do they put a maximum on how many times you can change your password? If not, you could just cycle through 13 passwords in 5 minutes, then switch back to your original password.
Fun fact. In my organization we are required to change password each three months, so now im on ...24 and i can calculate from that how long i been working here :)
This is what I used to do before I started using a password manager. Now I just change my password to a new, randomly generated one every month while my master password stays the same.
It does for me. KeePass on my phone + InputStick. I've even got a macro set up to enter all the necessary keystrokes so I can login with one tap. (Ctrl+Alt+Del -> Enter Password -> Enter)
You're welcome. I discovered it myself only around 6 months ago, and so far I've found it to be very useful.
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 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.
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
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.
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.
I wrote a tool a while back that's excellent at this. It produces a 1MB file that you can do a straightforward search against and use to blacklist 161,000 different common passwords.
> There are no fancypants libraries, frameworks, or nonsense required. Use your favorite language with the index, I don't care what it is. ...unless you like XML. If you like XML, I'm judging you.
"bad_passwords.txt" seems to be 1 line long? Am I missing something..
edit: Oh, "Convert your user's password to lowercase and do a simple string search against the index. No regular expressions are necessary." That makes sense, apologies.
I like your license choice. Is there a reason you chose Unlicense over CC0? I've never heard of it before. The text is a bit shorter than CC0 which is nice. Creative Commons recommends against using CC licenses for software so as not to step on the toes of the GPL which doesn't seem applicable if you really want public domain. [1]
Oof. I don't remember exactly, but I do remember spending a lot of time (too much time) deciding between various license options. I think in the end I chose Unlicense primarily because it's easier to find Unlicensed projects on Github.
There are a few approaches that would work better for specific environments. I could make a gigantic Bloom filter for example, with lookup functions in a few languages.
But my goal was to make something that any programmer could use in any environment. Substring searching is a basic programming skill and just about everything supports it. (COBOL74 needs external functions to do it.)
No, I meant in addition; if you want it to be used widely, a few tweaks (if that?) and you could make a Django version (Django already supports the feature, it just uses a short (1000) wordlist by default).
Calling it an algorithm may be giving it too much credit.
The packing program reads in a file, sorts the passwords into clusters based on their length, maintaining a popularity count as it goes. Then it prunes any passwords that occur less than some number of times in the input file ("4" by default, so it doesn't spend a lot of time churning on unpopular passwords). Next, starting with the longest passwords, it works its way down the list, merging the popularity count of shorter passwords into the most popular longer passwords which contain the entire shorter password. e.g., "password" gets merged into "password1234".
Finally it starts writing the output. Starting with the most popular password, it searches up to N passwords ahead in the list (40 by default), looking for any passwords that begin with the same characters that the current password ends with. So it finds "123456", and writes "password123456" to the output file.
I think the only thing I can do to optimize it further is to re-cluster the passwords by their starting character during the output stage, to improve its chances of always finding two passwords that can be glued together.
It's a crude brute-force approach but it works okay.
I just looked at the code, it's not that bad, I really will release it with the next update.
What I'd do is sort the popular passwords by length, start with the longest. Then as you're adding new passwords to the end, check if it's already in there. Then you'll go from phrases to words with a lot of them being duplicates.
At least if you wanted to keep it as a long string. I'd still probably approach this as a bloom filter as others suggested since it'd let you have a larger number of entries for similar memory footprint.
A Bloom filter is absolutely the right way to do this sort of thing, except that I had as a firm requirement, "something that any programmer of any skill level can use in any environment."
The file is small enough, and the approach straightforward enough, that for instance somebody could write a trivial Wordpress or Joomla or Drupal plugin for it, and they wouldn't have to think about Bloom filters or have ready-made lookup functions.
I placed greater value on adoptability than cleverness.
Yes, it is simple, yet elegant solution to the common password problems. I would also add check against common patterns (numbers or letters in increasing/decreasing order or keys subsequent in keyboard etc.) to this, so you can't use "password1239" instead of "password123" and call it a day.
I'd say to just treat any of the common passwords as a single character when validating. If "password" was treated as a single character, then password123 would only count for 4 characters. It might be tough to explain to users, but it would solve the problem.
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?
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.
Yeah, I think this comparison against known/expected/compromised values is the key offset for not imposing character set rules. They made the smart choice.
>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.
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.
I routinely get into my own accounts by saying "oh, I don't remember wat I set that to" for multiple security questions until I get questions I don't need to look up the answers to.
It really is scary, in that even my bank will fall back on things that are either easy to obtain or easy to guess, because they clarly have to deal with too many people who either genuinely have no clue, or like me can't be bothered to look up what I've answered. "Telephone banking password? I have no idea what that is. Did I set one? Sorry, can't remember..."
That's why I generally use random noise for my actual password, but random sets of 4 - 6 words for security questions. Both generated by 1Password and stored there. At least with a random set of words, they're something you can communicate verbally over the phone.
One reason, because I started using it long ago, and it works for me, so...
Second, after looking at KeePass (very briefly), it appears to be .net, and while it 'would' run on Linux, I'd have to install .net for Linux (Mono), and I'm just not going to do that.
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.
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).
> "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!
"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.
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.
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.
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.
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.
And where exactly the keylogger is supposed to come from? Has your laptop been tampered with during lunch? Then I'm afraid bitlocker is just as screwed as my Ubuntu. Or has the laptop been owned during use (remote vulnerability, double click on a malware…)? Same thing.
I'm not sure I see the point of this limitation. At a first glance, it seems using the BIOS only doesn't buy us much.
Any recommendations on a good keylogger software please? Have anybody tried this one https://www.refog.com/ , I read only positive reviews on it. Thanks in advance.
The rationale was that if, password hashes got compromised, the attacker would only have until the next forced rotation to crack the passwords and take over accounts.
edit: or, in particularly terrible systems, if plaintext passwords were leaked.
Of course, that's only useful if it doesn't affect any other password security concerns, and it turns out that users who are forced to change their passwords frequently pick worse passwords, which is a bigger problem than the scenario this was supposed to protect against.
> it turns out that users who are forced to change their passwords frequently pick worse passwords
I can vouch for this. My rotating password at work is _______1, followed by _______2, then _______3, and so on. If a year-old hash gets cracked, it won’t take a rocket scientist to know that the password right now is _______4.
Get a password manager already, and let it just generate random passwords for you. Typing in passwords is so lame. :) If you are on macOS I highly recommend https://github.com/ravenac95/sudolikeaboss (and by extension 1Password).
I use a password manager. The password in question is one I type all the time, in dozens of different contexts, on a computer I don’t own and can’t modify :(.
This would be fantastic if work allowed me to install one. Sadly, some of us work in locked down environments so resort to such silliness to get through the work day.
I'm sorry. that sucks. That's just stupid. I could see employers requiring you to use their password manager, but ugh, not allowing use of one is just gross.
That said, lastpass can work without any modifications to your local machine(i.e. it can work without any browser plugins even) tho it's not very fabulously integrated, it does work... Assuming of course they don't block access to the lastpass website and JS.
> The rationale was that if, password hashes got compromised, the attacker would only have until the next forced rotation to crack the passwords and take over accounts.
In all fairness, it's a fair assumption. There is an attack vector where one gets an old password from 8 years ago by whatever means... and it is still valid.
The execution was terrible though. People started forcing password change every month [which is overkill to stop an attack that has a multi year timespan] and it created a whole new set of disasters.
That's going to go badly for you the moment the attackers realise what you've done. Admittedly they'll no longer be able to compromise the account, but you better really care about that.
How about ... a duress code that diverts to a system that looks like the real one but actually contains disinformation (possibly including a misdirection that makes them think you were on their side all along, so that they let you go)
I'd say that in most cases, the safest approach to a duress code would simply be to give real access to the system, possibly with lower privileges if it can be done without too much suspicion, while also triggering an alarm.
The cost of maintaining a sufficiently real-looking system is likely to be very high, with the very real risk that it won't fool an attacker.
I would have thought it was actively detrimental to ask people to come up with a new one every month. I can just imagine villainous hacker sitting there thinking "Blast, none of the employee's passwords were in my database of common passwords. Never mind, next month they'll have to have a whole new set and maybe one of those will be."
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.
> It does help to limit the scope of who has passwords.
Only if the rotation isn't predictable. If I receive "password3" and it doesn't work and Joe who shared it with me isn't available, I probably wouldn't think twice about trying "password4".
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.
I don't think it's trivial to find similar password for multiple reasons.
Comparing old passwords without plaintext is really hard and at best inexact.
Storing them plaintext (or even reversibly encrypted) is completely stupid, of course.
Even if these technical problems could be solved, sequences like: November6, December7, January8 are not "similar" but easily predictable.
Even this sequence is probably not hard to figure out if you look at a keyboard:
Secret1
Drvtry2
Ftbytu3
Deeper though, what security threat is this actually mitigating? Bad passwords caused by rotation requirements that are needed because of bad company policies, training and practices? Is there a security equivalent of "yak shaving"?
Same way you check if the password is correct. Check against the old hashes. When the user sets the new password, if it looks like it matches an iterative pattern (i.e. if it ends in a number) then test the previous few from that sequence against the old hashes. Note, this is still a terrible idea.
You don't compare the hashes. When the user changes the password to "myOldPassword22", you hash "myOldPassword21" and "myOldPassword20" etc and compare those to the old hashes.
Do you know how many variations there could possibly be??
For example, I could use: myoldpasswordA1 / myoldpasswordB2 / myoldpasswordC3. Probably obvious to a human my next one will be D4, but it is a comparable problem to "play every possible game of chess" for a computer to figure that out.
Combined with using a secure computationally-expensive password storage mechanism (eg: bcrypt or PBKDF2) and I'm not exaggerating: it now takes billions of years to verify a password change is allowed.
And this is trying to solve a compromised password problem. If there's no compromise, rotating passwords is pointless.
If the password IS compromised, rotating the password doesn't really fix it, it merely limits access -- maybe. It doesn't address the original means of the compromise (so you have to assume that's still there). It doesn't address backdoors installed. It doesn't address information stolen.
So this is a hell of a lot of work to accomplish .. basically nothing.
> For example, I could use: myoldpasswordA1 / myoldpasswordB2 / myoldpasswordC3. Probably obvious to a human my next one will be D4, but it is a comparable problem to "play every possible game of chess" for a computer to figure that out.
Two possible changes (forward/backwards) for two characters out of 15. 420 combinations. Not exactly billions.
> Two possible changes (forward/backwards) for two characters out of 15.
Yes, but you can only cut down the sample space in this way because you can look at "myoldpasswordA1" and know that the 'A1' characters are the iterators. A computer doesn't know that.
My figure is for testing all possible ways of changing two characters by one each (and the ways of changing only one character are a tiny subset of that). This doesn't catch people who change 3 or more characters, or who change characters by more than 1, but at that point is it really still so easy to guess?
Why does someone have an old password in the first place? You should be asking how it got compromised, who knew the credentials, if it was compromised while still active, and if so, how many backdoors were installed, what data/systems were compromised, and how do you prevent this from happening again.
None of the problems could have been avoided if only there was a better password iteration detection algorithm.
> Why does someone have an old password in the first place? You should be asking how it got compromised, who knew the credentials, if it was compromised while still active, and if so, how many backdoors were installed, what data/systems were compromised, and how do you prevent this from happening again.
All true. Nevertheless, there are cases where someone gets a one-off copy of a password - perhaps overheard. If you force them to actively install a backdoor then you increase the costs of attacking greatly. It's not about perfect security, it's about the cost/benefit - a lot of crime is crime of opportunity, especially internal fraud.
> If you force them to actively install a backdoor then you increase the costs of attacking greatly.
I think that it's my fault, but I can't understand this sentence. Doesn't forcing someone to install a backdoor decrease security? The only reading that makes sense to me is "If you make it so that it's user action, rather than inaction, that results in the installation of a backdoor …"?
(For what it's worth, although I disagree with you, I respect your dedication to arguing this determinedly but civilly.)
What I meant was: "if you force an attacker who obtains a one-off copy of a password (perhaps overheard) to actively install a backdoor (in order to have the capability to perform an attack at some later time - as opposed to being able to passively maintain that capability by simply remembering that person's password pattern) then you increase the costs of attacking greatly"
If you store N variations, a random guess has N chances to hit one. Once an attacker knows a variation, they may be able to use it to narrow down on the real password.
I work in security and yes, it definitely helps in some cases with preventing lateral movement. Since servers aren't rebooted often, if I choose to run mimikatz to dump creds off of the server and steal a user's password, that password may as well be useless if the user logged in long enough for a password reset to have been enforced in that time.
It's a halfhearted attempt to protect against vulnerable zombie accounts. When someone leaves for whatever reason, their account (if not terminated) still has access. Someone could hack in (or the former user could try to log in at a later date) and get that access. The policy of "If you don't change your password in the next 7 days, you will have to contact IT to reset it.", (along with actually locking out the account if the password isn't changed in time), could greatly reduce potential abuse of those zombie accounts. A large organization, especially one with lots of turnover, could accumulate thousands of those zombie accounts over the years.
Of course, the proper thing to do would be to deactivate the account when someone leaves the organization. But if the organization doesn't have it together enough to deactivate and reactivate accounts properly, they might rely on the time limit as a fallback. The reason your password isn't good now is that someone doesn't have the info they need to do their job (deactivating accounts) properly, is lazy, or is paranoid. In any case, it's a signal that the organization that's requiring you to change your password can't manage account deactivation.
If, for whatever reason, your password ends up somewhere (even some sort of keyboard buffer?), but is found a couple months later, then it can't be used anymore.
It's also a similar rationale to password resets. The e-mail might end up in some leak somewhere (see WikiLeaks), but the link won't be valid anymore.
It doesn't stop all classes of security issues, but it does make the data time-sensitive. Think about all the account leaks that happen. The data is rarely current (usually a year+ old).
For example, imagine if someone compromises one of your backups. Some hard drives were stolen from the office or something. In there you had your password written in a text file ( because you're that kind of person). The attacker still doesn't have access to your computer. But they do have access to your password from the time of backup.
A disgruntled employee remembers the password of a former coworker. At one point the password will change, so the window of opportunity is smaller.
It's not perfect, obviously, but in a lot of office environments passwords are easy to gleam.
Another argument for password rotation: it usually forces people to keep different passwords per service. Without rotation, people tend to use the same password for everything
There's a trade-off, but it doesn't accomplish nothing
It's fundamentally the same principle as forward secrecy: that the compromise of one password doesn't permanently destroy the security of the systems to which that password applies.
"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.
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!"
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.
It says "SHALL be generated using an approved random bit generator." What are some examples? debian /dev/urandom? dotnet RNGCryptoServiceProvider? others?
Good to see that after all this time dodging corporate pressure to implement counter-productive measures, the guidelines themselves have changed for the best :)
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ÞØý½
Interestingly enough, I just recently released a password strength library which can help enforce these exact requirements. https://github.com/GoSimpleLLC/nbvcxz
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.
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.
You don't seem to understand the scale here. Normal, non-secure hash functions can be calculated at a rate of hundreds of millions per second, and can easily be brute-forced within a few hours. Current rule of thumb for PBKDF2 (for example) is to choose an iteration count corresponding to around two hashes per second, and the work is not parallelizable. That turns those hours of work into millenia.
If it really concerns you, proper practice is to store the iteration count alongside the hash and salt, so you can easily go through and add more iterations if you want as computers get faster.
The parent comment of educating yourself refers to the fact that using a slow hash function and using multiple iterations has be password storing best practice for many years.
Its neither surprising (rather expected) nor of questionable value.
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.
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.
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)])
Note: random wasn't patched to use a secure generator in python3 (yet) - from a quick look, it appears secrets.choice() does what I thought random.choice() already did (python 3.6, not 3.5 and earlier)
But looks like "secrets"[1] has the strong random.choice provider among others.
Probably the (minimal, dirty) change needed (for python 3.6 and later) is:
import secrets as r
But I can't test that right now. Thanks for calling me out on this, and having me do a quick search to check my assumptions.
I do agree that for this particular case, the pseudo-random generator seeded by system time might be enough (or at least better than "random" key presses) - but I don't like spreading bad patterns. And for any code generating many passwords, with the opportunity for an attacker to get a sample - this is likely very bad.
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.
I'm cautiously hopeful that this will supply needed ammunition for those advocating for saner password rules and policies in organizations big and small.