Sadly the "long passphrase" advice is also out of date. It relies on the naive idea that all password cracking is done brute-force, one character at a time. But all the huge leaks of password DBs over the past few years has given crackers a huge dataset to study and understand password generation behaviours, including how people come up with passphrases.
Ars Technica did a long look at password cracking techniques[1] that covered stuff like this. The tl;dr is that any strategy short of full randomness is wrong. Either use a password manager, or use a set of dice, just make sure that your own human predictability cannot meaningfully affect the outcome.
The strategy is fine - the problem is that people don't use a random number generator. This is how you get a 3-word password with 54-bits of complexity (on a mac with a recent ruby):
The long passphrase idea as suggested by xkcd is fine, provided you pick random words. For instance, a database of 2048 words, and a 4 word passphrase has 44 entropy (2^44 possible passwords).
>>> log2(2048 ** 4)
44.0
Even if somebody knows the pattern they have 17 592 186 044 416 passwords to try. You can further increase number of passwords to try by increasing number of words. Probably with advances of technology 4 words may be somewhat unsecure in the future, but 5 words is 2048 times harder to crack than 4 words password, so it should be still secure.
The article in question shows three word passwords being cracked, but please note that three words is 2048 times easier to crack than 4 words, and probably very feasible to crack using graphics cards (provided poor choice of algorithms like MD5).
> Sadly the "long passphrase" advice is also out of date. It relies on the naive idea that all password cracking is done brute-force, one character at a time.
I thought the point was that a increasing the length typically does more for you in terms of entropy than increasing the size of the alphabet.
> The tl;dr is that any strategy short of full randomness is wrong.
I don't know. You might want to have a password with some regularity to make it easier to remember (at the expense of being longer for a given entropy).
The XKCD method of generating passwords [1] does not imply 'best case' entropy of crackers going after each individual character. Instead it clearly states 44 bits of entropy which is the 'worst case' entropy when the attacking knows your exact method and dictionary used when generating the password.
I'd argue that when targeting the same number of bits of entropy the XKCD method is still easier to remember than a bunch of fully random characters.
I think nowadays the bigger problem is that sites don't cooperate with password managers. I am trying to use 20character passwords and some sites still limit that number to 12 or 16. Also the fact that blizzard or steam doesn't use TOTP that google auth. uses pisses me off.
Related problem: sites that don't let you paste into the password field - either when setting a password or trying to log in. To the people who do this: what do you think you're accomplishing? It's not going to stop somebody brute-forcing your site, and you're making it difficult to use a password manager.
Sites with stupid Javascript isn't half the problem that mobile is. I still can't make in-app purchases on my iPhone because every time I try, Apple makes me put in my security question answers, which are random strings just like the passwords are, and then I get "your request has timed out."
Really I should be thanking Apple though for helping me save money.
been awhile since I have played (star/war)craft/throne/wings of liberty but I recall that blizzard specifically ignored capital letters. I could enter my password in without capitals and it worked fine. any thought to why this may occur?
Every time I participate in a security audit for some enterprise contract I have to explain and defend why we don't enforce complexity and rotation rules.
Lately citing the NSA's change in position has been convincing enough and we don't get nearly as much push back.
One thing I suggest to people these days is to instead make a passphrase where at least one of the words is an "English-like nonword". Something that sounds like a word but doesn't appear in the dictionary. People are pretty good at remembering things like that, and I find that most people can remember their passwords even a week later with this method.
A sample password might be: "Zapagar, lightning chomper"
Or maybe: "plodding! Sloimo can't 3lap"
It's much easier to remember a password if it forms a little story in your head.
Too many people try to optimize the "hard to guess" part of a password requirement without considering the "easy to remember" requirement. Typing long passwords isn't nearly as much of a hassle if it is full of normal words instead of insane garbage like L1ghtn1nG that computers can easily guess anyway. Length is the best defense.
Oh freddled gruntbuggly,
Thy micturations are to me,
As plurdled gabbleblotchits,
On a lurgid bee,
That mordiously hath blurted out,
Its earted jurtles, grumbling
Into a rancid festering confectious organ squealer. [drowned out by moaning and screaming]
Now the jurpling slayjid agrocrustles,
Are slurping hagrilly up the axlegrurts,
And living glupules frart and stipulate,
Like jowling meated liverslime,
Groop, I implore thee, my foonting turlingdromes,
And hooptiously drangle me,
With crinkly bindlewurdles,mashurbitries.
Or else I shall rend thee in the gobberwarts with my blurglecruncheon,
See if I don't!
All it takes is one website to poorly secure your credentials, and your password is exposed everywhere in this case. Use a password manager, and use the max length you can for that website.
At which point will we need to move to strictly external hardware authentication? I think that even with password managers, it can only go so far. At some point we will be synchronizing password files with dozens of MBs, and one day you will want to login to something and won't have access to your passwords. There has to be a way of building transparent AND strong authentication.
The main problem with this would be non-standardisation. For example, I have 4 bank accounts at 4 different banks and each has a different piece of hardware for 2FA. Imagine if you needed an individual key fob for every single online account you have.
I'd love to be in a world where I click the website login button, I then type a simple pin into a key fob, then I plug the fob into a USB port, and it authenticates me. No password other than the pin. I'd also love it to just be a 'thing', not a way to just hack filling in a password field on a form.
I have an honest question about cracking passwords. Does the cracker know when they are getting close? I don't understand how they could, but every field has its experts and surprises so I thought I'd ask here.
So if I have a hashed password, and I start a hashing a dictionary, will I know that I have, say, the [whatever the word is for iterations or depth of hashing] correct, before seeing exact matches with the hashed database? Is there, I don't know, some convergence of some statistical property of the output as I get closer?
In general, that depends on the hash function. Some hash functions have that property (e.g. you might want to use such a function for some internal data structure), but cryptographic hash functions must not. If you'd find some property where you could check if you're "getting close", then that would be a major flaw in that function - i.e., it's possible that SHA-3 has some way to do that, but as far as we know (and we've tried) it does not, and if it would be the case then that would be a good enough reason to stop using SHA-3 anywhere.
They should not. However in a badly designed system they will. It turns out to be harder than you might think to not leak information. If you apply a hash to the password (which you should) and then check the hash you need to check all characters of the hash before announcing yes/no. Otherwise the attacker then time how long it takes to get to the no, when it takes longer they know that the first byte of the hash matches - this lets the attacker eliminate most of the possible passwords quickly and thus break in faster.
The above is just one of the subtle things you need to worry about when trying to design a password checker. If you get it right the answer is NO, the attacker doesn't know when he is getting close.
As others have said, for properly hashed passwords, the answer is no.
However, for plaintext passwords using the default string comparison routines, a timing attack becomes possible since it will take slightly longer to compare a partially right password than a completely wrong password. The timing discrepancies would give the attacker clues about how close he is to succeeding.
I just wish websites would remind you of their password rules at login time. I use different passwords depending on what the password rules are, and you only get to see them at signup/ password recovery, which unfortunately tends to be quite often with certain websites or web apps.
My favorite is sites that allow you to use any number of special characters when you sign up or change your password, but their login forms break when you try to use them. If there are rules, please enforce them on your sign-up form!
Amen, with a special F.U. to the sites that disallow special characters. What is the reason for that? (OK I might understand disallowing some uncommon chars but $%(^ etc shouldn't be disallowed)
This. I often think that it would be very useful to have a website to check password requirements of multiple sites.
That is, a site were we would search for "gmail.com" and it would say "minimum 8 characters. 1 letter, 1 digit and 1 symbol mandatory" (made up example).
Then of course there could also be Firefox/Chrome extensions that would query this site and show the rules near login prompts.
I'd make it myself were it not for the lack of time... but if anyone wants to pick up the idea, there it is. I just ask for 10% of ad revenue :)
There are two examples of misunderstanding the human element here.
One is that rotation and complexity rules lead to password spreadsheets and postit notes, a different kind of security issue.
Another is that forcing someone to constantly defend and explain why something is the way it is, leads to that persona eventually implementing something that (even is worse), will attract fewer questions.
I think the software community has generally done a poor job with authN, authZ, and credential management. The Web Authentication working group is working on a new spec to tackle some of their problems issues [0], but it's still fairly young and it fails to address some common pain-points.
It seems reasonable to distinguish between identity and device. If I lose some device, I can publish its revocation.
Serious internet users will have dozens, if not hundreds, of accounts. How do we handle revocations and key rotation?
Let's say that you have 26 tokens (english lower case alphabet) in your password policy. Let's also say that there is a cost incurred adding a token. How many letters would a password need to be for it to be more beneficial to add a token rather than add to the minimum length? 26^n > 27^(n-1) comes out to 88th letter providing less entropy than adding a token. The more reasonable alphabet is 52 letters (lower and upper case) and some tokens, let's say 12 tokens. 64^n > 65^(n-1) makes 269. Lesson to draw from this: always make your password longer, rather than more complicated.
Are the little devices that change the PIN or passphrase every 30 seconds the most secure way to lock access? It seems like having to have the right code at the right time was more secure than having the right code at anytime, but I wasn't sure why they weren't rolled out en mass. Is this not the best method of security?
TOTP, the algorithm used by github, google, and many others to provide two-factor auth is basically that, except your phone is the little device. IMHO this is "good enough" security for normal people. I haven't read of cases where people's second factor got hacked, just where it got bypassed (e.g. by using social engineering to skip passwords entirely).
From the point of view of somebody brute forcing their way in, there is very little difference between a password that stays the same and one that changes all the time.
Those are great against key-loggers, not so against people that have insider info.
And here I am typing a small novel every time I want to unlock my crypt, feeling smug, when just now I realize that some day even my passphrases will become "not enough". This is a weird feeling- excitement for the future, but also fear
The logic of passwords is simple, once you realize that all humans are terrible random number generators.
When you allow any part of your password to be chosen by a human, i.e. yourself, you have to assume that the human-chosen part is known to an attacker. The solution is to generate passwords with enough random bits to satisfy current demands. And by generate I of course mean to allow a real number generator (either a computer, or dice, or anything really random; i.e. something a casino would accept) to choose the password for you. Without any restrictions except a desire to minimize length, you get the classic unmemorable 0vT2GVlncZ4pZ0Ps-style passwords. If you add the restriction “must be a sequence of english words”, you get xkcd-style “correct horse battery staple” passwords. Both are fine, since they contain enough randomness not generated by a human.
But if you yourself choose, either old-style “Tr0ub4dor&3” or passphrase “now is the time for all good men”-style, you have utterly lost, since nothing has been randomly chosen, and “What one man can invent, another can discover.”.
Note: this also applies if you run a password generator and choose a generated one that you like. Since you have introduced choice, you have tainted the process, and your password now follows an unknown number of intuitive rules (for instance, there was a story here on HN the other day about how people prefer the letters in their own name over other letters of the alphabet), and these rules can be exploited by an attacker.
First, in light of how they handled the Google memo...
Screw Gizmodo.
But regarding the article itself, seems to be a nothing-burger. Once upon a time, we favored shorter complex passwords. Now, we favor longer intuitive passwords. The end.
EDIT: I see the link in OP is now a WSJ link. It was a Gizmodo link at first. Hence my comment.
[+] [-] stupidcar|8 years ago|reply
Ars Technica did a long look at password cracking techniques[1] that covered stuff like this. The tl;dr is that any strategy short of full randomness is wrong. Either use a password manager, or use a set of dice, just make sure that your own human predictability cannot meaningfully affect the outcome.
[1] https://arstechnica.com/information-technology/2013/05/how-c...
[+] [-] mdemare|8 years ago|reply
Easier to remember than `rand(254)` => 16495714355860079
[+] [-] GlitchMr|8 years ago|reply
The article in question shows three word passwords being cracked, but please note that three words is 2048 times easier to crack than 4 words, and probably very feasible to crack using graphics cards (provided poor choice of algorithms like MD5).
[+] [-] Bromskloss|8 years ago|reply
I thought the point was that a increasing the length typically does more for you in terms of entropy than increasing the size of the alphabet.
> The tl;dr is that any strategy short of full randomness is wrong.
I don't know. You might want to have a password with some regularity to make it easier to remember (at the expense of being longer for a given entropy).
[+] [-] admiun|8 years ago|reply
I'd argue that when targeting the same number of bits of entropy the XKCD method is still easier to remember than a bunch of fully random characters.
[1] https://xkcd.com/936/
[+] [-] lousken|8 years ago|reply
[+] [-] cuckcuckspruce|8 years ago|reply
[+] [-] vinceguidry|8 years ago|reply
Really I should be thanking Apple though for helping me save money.
[+] [-] throwfast1|8 years ago|reply
[+] [-] arkitaip|8 years ago|reply
[+] [-] pselbert|8 years ago|reply
Lately citing the NSA's change in position has been convincing enough and we don't get nearly as much push back.
[+] [-] al452|8 years ago|reply
[+] [-] jandrese|8 years ago|reply
A sample password might be: "Zapagar, lightning chomper"
Or maybe: "plodding! Sloimo can't 3lap"
It's much easier to remember a password if it forms a little story in your head.
Too many people try to optimize the "hard to guess" part of a password requirement without considering the "easy to remember" requirement. Typing long passwords isn't nearly as much of a hassle if it is full of normal words instead of insane garbage like L1ghtn1nG that computers can easily guess anyway. Length is the best defense.
[+] [-] Cthulhu_|8 years ago|reply
[+] [-] maccard|8 years ago|reply
[+] [-] princekolt|8 years ago|reply
[+] [-] iamphilrae|8 years ago|reply
I'd love to be in a world where I click the website login button, I then type a simple pin into a key fob, then I plug the fob into a USB port, and it authenticates me. No password other than the pin. I'd also love it to just be a 'thing', not a way to just hack filling in a password field on a form.
[+] [-] antisthenes|8 years ago|reply
For certain people (myself included) that's a much bigger risk factor than getting your password manager db compromised.
If I lose my keychain authenticator or what have you, I don't want to be stuck not being able to use any of my websites until a new one arrives.
[+] [-] tome|8 years ago|reply
[+] [-] dhimes|8 years ago|reply
So if I have a hashed password, and I start a hashing a dictionary, will I know that I have, say, the [whatever the word is for iterations or depth of hashing] correct, before seeing exact matches with the hashed database? Is there, I don't know, some convergence of some statistical property of the output as I get closer?
[+] [-] PeterisP|8 years ago|reply
In general, that depends on the hash function. Some hash functions have that property (e.g. you might want to use such a function for some internal data structure), but cryptographic hash functions must not. If you'd find some property where you could check if you're "getting close", then that would be a major flaw in that function - i.e., it's possible that SHA-3 has some way to do that, but as far as we know (and we've tried) it does not, and if it would be the case then that would be a good enough reason to stop using SHA-3 anywhere.
[+] [-] bluGill|8 years ago|reply
The above is just one of the subtle things you need to worry about when trying to design a password checker. If you get it right the answer is NO, the attacker doesn't know when he is getting close.
[+] [-] kej|8 years ago|reply
However, for plaintext passwords using the default string comparison routines, a timing attack becomes possible since it will take slightly longer to compare a partially right password than a completely wrong password. The timing discrepancies would give the attacker clues about how close he is to succeeding.
[+] [-] Malice|8 years ago|reply
[+] [-] Xoros|8 years ago|reply
Not trolling, I guess for people that don't know how it works it can be confusing.
[+] [-] Udik|8 years ago|reply
[+] [-] TrisMcC|8 years ago|reply
[+] [-] rb808|8 years ago|reply
[+] [-] Al-Khwarizmi|8 years ago|reply
That is, a site were we would search for "gmail.com" and it would say "minimum 8 characters. 1 letter, 1 digit and 1 symbol mandatory" (made up example).
Then of course there could also be Firefox/Chrome extensions that would query this site and show the rules near login prompts.
I'd make it myself were it not for the lack of time... but if anyone wants to pick up the idea, there it is. I just ask for 10% of ad revenue :)
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] dalbasal|8 years ago|reply
One is that rotation and complexity rules lead to password spreadsheets and postit notes, a different kind of security issue.
Another is that forcing someone to constantly defend and explain why something is the way it is, leads to that persona eventually implementing something that (even is worse), will attract fewer questions.
[+] [-] TheAceOfHearts|8 years ago|reply
It seems reasonable to distinguish between identity and device. If I lose some device, I can publish its revocation.
Serious internet users will have dozens, if not hundreds, of accounts. How do we handle revocations and key rotation?
[+] [-] Beltiras|8 years ago|reply
[+] [-] ciro_langone|8 years ago|reply
[+] [-] Joeri|8 years ago|reply
[+] [-] marcosdumay|8 years ago|reply
Those are great against key-loggers, not so against people that have insider info.
[+] [-] jameskegel|8 years ago|reply
[+] [-] marcosdumay|8 years ago|reply
[+] [-] meitham|8 years ago|reply
[+] [-] arkitaip|8 years ago|reply
[+] [-] teddyh|8 years ago|reply
When you allow any part of your password to be chosen by a human, i.e. yourself, you have to assume that the human-chosen part is known to an attacker. The solution is to generate passwords with enough random bits to satisfy current demands. And by generate I of course mean to allow a real number generator (either a computer, or dice, or anything really random; i.e. something a casino would accept) to choose the password for you. Without any restrictions except a desire to minimize length, you get the classic unmemorable 0vT2GVlncZ4pZ0Ps-style passwords. If you add the restriction “must be a sequence of english words”, you get xkcd-style “correct horse battery staple” passwords. Both are fine, since they contain enough randomness not generated by a human.
But if you yourself choose, either old-style “Tr0ub4dor&3” or passphrase “now is the time for all good men”-style, you have utterly lost, since nothing has been randomly chosen, and “What one man can invent, another can discover.”.
Note: this also applies if you run a password generator and choose a generated one that you like. Since you have introduced choice, you have tainted the process, and your password now follows an unknown number of intuitive rules (for instance, there was a story here on HN the other day about how people prefer the letters in their own name over other letters of the alphabet), and these rules can be exploited by an attacker.
[+] [-] traviswingo|8 years ago|reply
[+] [-] mcbruiser3|8 years ago|reply
or
b) use the "forgot my password" option every time
[+] [-] m52go|8 years ago|reply
Screw Gizmodo.
But regarding the article itself, seems to be a nothing-burger. Once upon a time, we favored shorter complex passwords. Now, we favor longer intuitive passwords. The end.
EDIT: I see the link in OP is now a WSJ link. It was a Gizmodo link at first. Hence my comment.
[+] [-] Jaruzel|8 years ago|reply
http://www.dailymail.co.uk/sciencetech/article-4771194/The-m...
I now predict an uptick in people using 'correctbatteryhorsestaple' as their password...