The man who wrote the book on password management regrets the error(wsj.com)
wsj.com
The man who wrote the book on password management regrets the error
https://www.wsj.com/articles/the-man-who-wrote-those-password-rules-has-a-new-tip-n3v-r-m1-d-1502124118
140 comments
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):
Easier to remember than `rand(254)` => 16495714355860079
ruby -e 'puts File.read("/usr/share/dict/words").lines.sample(3).map(&:chomp).join(" ")'
Easier to remember than `rand(254)` => 16495714355860079
Yeah super. Let me scale that for my bank, car loan, house loan, credit cards, FB, IG, Twitter, Email, HN, Coursera, EdX, Udacity, Udemy, Concur, forums, Netflix, LinkedIn, Paypal, Slac, Spotify, Hulu, AppleID, Reddit, Amazon, health insurance, college alumni page, Digital Ocean, WSJ, GoDaddy, hotel points, and airline miles sites.
That's a lot of accounts and a lot of passwords. You'd probably want to use a password manager. These kinds of passwords still have the advantage of being easy to hold in short-term memory, so when your password manager is on a different device than the service you're trying to use, you can look it up once and type it in rather than having to look back and forth between the two for that 16-digit number.
I think that's his point. The strategy of memorable passwords is not viable. You still need a password manager. But I agree that spellable, pronounceable passwords are helpful when you need to type on in.
I finally started using KeePassX so I could keep track of the insanely long and randomized passwords it creates across the same plethora of sites you've listed. I love using it, but there's no way in hell I can quickly update so many different credentials conveniently(e.g. update your password every 6 months or so? Just kill me now)
I've used password managers for about 15 years now. I just counted I have ~400 passwords saved, most of which I'm obviously not using and a large number for services that do not even exist any more.
As I can't be bothered to even check which ones to delete, I will definitely not be updating any of those.
As I can't be bothered to even check which ones to delete, I will definitely not be updating any of those.
Except some you can outsource everything to a password manager.
I think I remember just these passwords: my 2 banks (that keep my savings), stock broker, primary email a/c, AppleID, personal VPS. For these too I keep very personal hints (no one else can guess) in KeePass (just in case).
Master passwords for LastPass and KeePass are quite difficult and I don't keep its hint or anything anywhere. It's a risk I decided to take. On the downside I have not changed these two passwords in a long time.
Rest goes to LastPass (100s of them).
I think I remember just these passwords: my 2 banks (that keep my savings), stock broker, primary email a/c, AppleID, personal VPS. For these too I keep very personal hints (no one else can guess) in KeePass (just in case).
Master passwords for LastPass and KeePass are quite difficult and I don't keep its hint or anything anywhere. It's a risk I decided to take. On the downside I have not changed these two passwords in a long time.
Rest goes to LastPass (100s of them).
Hmmm. Have you considered closing some of those and regressing away from your online presence in order to solve your evident frustration with managing so many pwds? If I signed up for all that cra..stuff, I would close some. :)
One thing that works is putting the name of the service into part of your password for each site.
So like, Abzysbej@10netflix and Abzysbej@10hulu
So like, Abzysbej@10netflix and Abzysbej@10hulu
And then one leak in plaintext compromises all of your accounts because a targeted attacker is presumably smart enough to understand what you did...
To make it a bit less conspicuous, take the third character (or something) from the service name and put it as the fifth character (or something) in an otherwise long random string.
This will look like a random password... until someone gets two or more passwords made with this strategy, then it's pretty easy to find out the strategy.
How is any of this easier than using a password manager??
You only have to remember one password, the strategy is the same for all passwords, replace the fifth character (for example):
google: mojko2if6bibe78
youtube: mojku2if6bibe78
yahoo: mojkh2if6bibe78
Note that I don't advocate this strategy for high-security applications, but for throwaway accounts that you might want to access when not having access to your password manager it might be useful.
google: mojko2if6bibe78
youtube: mojku2if6bibe78
yahoo: mojkh2if6bibe78
Note that I don't advocate this strategy for high-security applications, but for throwaway accounts that you might want to access when not having access to your password manager it might be useful.
I should clarify, there should only be a pattern like that for the many frivolous services, and a different password for financial medical etc.
I'm not sure how big your word-list is, but my (wbritish) is:
Second, from what I gather from [1],[2] and [3] - you should probably use SecureRandom for cryptographic/security purposes:
[2] https://ruby-doc.org/core-2.4.1/Random.html
[3] https://ruby-doc.org/stdlib-2.4.1/libdoc/securerandom/rdoc/S...
$ wc -l /usr/share/dict/words
99156 /usr/share/dict/words
> Math.log(99156,2)*3
=> 49.79223735944021
Second, from what I gather from [1],[2] and [3] - you should probably use SecureRandom for cryptographic/security purposes:
$ ruby -e 'require "securerandom"; puts \
File.read("/usr/share/dict/words").lines.sample(4, \
random:SecureRandom).map(&:chomp).join(" ")'
remorse's mountaineers said arrival's
[2] https://ruby-doc.org/core-2.4.1/Random.html
[3] https://ruby-doc.org/stdlib-2.4.1/libdoc/securerandom/rdoc/S...
That may not be too viable. My first try:
> ruby -e 'puts File.read("/usr/share/dict/words").lines.sample(3).map(&:chomp).join(" ")'
xanthopsin pollenite aquascutum
> ruby -e 'puts File.read("/usr/share/dict/words").lines.sample(3).map(&:chomp).join(" ")'
xanthopsin pollenite aquascutum
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).
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).
>>> log2(2048 ** 4)
44.0
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).
In practical terms, that's still not very many. GPUs can do 2 GH/s for a simple hashing function. Your 44 bit password can be cracked in 4 hours by a single GPU, or in minutes by a cluster.
A large KDF helps, but damages user experience and again starts to become fragile if your threat model includes ASICs (a $3m expense or so for an attacker. That's a practical sum for many applications).
To put things in perspective, a CPU can do about 2^20 hashes per second. A $3m ASIC cluster (made entirely from scratch) can do about 2^52 hashes per second. It's obscenely asymmetric.
For high security accounts, you really want like 64 bits of entropy in your password plus a KDF, or you want 80 bits without a KDF.
KDFs have another major problem. If you forget a word in your password, and you also have a KDF, you have to fight your own KDF to discover that last word. You don't want that barrier.
edit: was off by a factor of 1000 in my ASIC math. $3m in ASICs can do about 2^52 hashes per second, not 2^42
A large KDF helps, but damages user experience and again starts to become fragile if your threat model includes ASICs (a $3m expense or so for an attacker. That's a practical sum for many applications).
To put things in perspective, a CPU can do about 2^20 hashes per second. A $3m ASIC cluster (made entirely from scratch) can do about 2^52 hashes per second. It's obscenely asymmetric.
For high security accounts, you really want like 64 bits of entropy in your password plus a KDF, or you want 80 bits without a KDF.
KDFs have another major problem. If you forget a word in your password, and you also have a KDF, you have to fight your own KDF to discover that last word. You don't want that barrier.
edit: was off by a factor of 1000 in my ASIC math. $3m in ASICs can do about 2^52 hashes per second, not 2^42
> you have to fight your own KDF to discover that last word. You don't want that barrier.
You pretty much want it. Why would you make your password easy to brute force so that you can recover it in case you forget it? This makes no sense.
A 6 word phrase reaches your 64 bits target (on the GP's 2-48 word dictionary). It is still easier to remember than a base64 dump of a 64 bits random number. I still fail to see anything wrong with passphrases.
You pretty much want it. Why would you make your password easy to brute force so that you can recover it in case you forget it? This makes no sense.
A 6 word phrase reaches your 64 bits target (on the GP's 2-48 word dictionary). It is still easier to remember than a base64 dump of a 64 bits random number. I still fail to see anything wrong with passphrases.
8 words is enough without a KDF. If you know 7 of the 8 words and there is a KDF, you might not be able to figure out which word is wrong or missing. But if there is no KDF you may be able to forget up to even 3 words.
Being able to brute Force your own password is a good thing if you can at least depend on knowing most of it.
Being able to brute Force your own password is a good thing if you can at least depend on knowing most of it.
Don't sites also salt (and pepper?) passwords though? Does this still apply in the scenario that they have done so?
Edit: Realised Google exists, currently reading https://stackoverflow.com/questions/16891729/best-practices-...
Edit: Realised Google exists, currently reading https://stackoverflow.com/questions/16891729/best-practices-...
> Don't sites also salt (and pepper?) passwords though?
They should salt. They should do many things. But we know some sites don't, we suspect many sites don't. Unless you know otherwise never assume a site is handling your data, including your login credentials, securely.
They should salt. They should do many things. But we know some sites don't, we suspect many sites don't. Unless you know otherwise never assume a site is handling your data, including your login credentials, securely.
That math is for fast hashes without salting, agreed. Of course, plenty of sites that lose passwords also make those mistakes...
This is wrong assuming, as is recommended practice, you use a hashing function like bcrypt or scrypt that is designed to be resistant against massive ASIC speedups, right?
I wouldn't call it wrong, but I agree that it's for fast hashes without salts. Since sites still use that (and we can't check what they're using pre-leak) it's still relevant, though.
Then I add another word or two and make that 44 bits 55 or 66 bits.
The strategy itself still works, even if the particular details of implementation change.
The strategy itself still works, even if the particular details of implementation change.
The XKCD comic includes this note:
> 1000 Guesses/Sec (Plausible attack on a weak remote web service. Yes, cracking a stolen hash is faster, but it's not what the average user should worry about.)
> 1000 Guesses/Sec (Plausible attack on a weak remote web service. Yes, cracking a stolen hash is faster, but it's not what the average user should worry about.)
Provided they don't use the same password for several services
In which case, sooner or later they'll probably end up using the password on a site that stores passwords in plaintext, and after that no amount of entropy will help.
Or the website hashes the password, and then stores a plaintext (or weakly encrypted) copy in the database as well so they can make sure you don't use a "similar" password on the next change. And in fact keep like 30 passwords in the database so hackers can get a good sense of how you construct your passwords. All for better security of course.
Oh that'd be a treasure trove for security researchers.
I think we should work on an opensource gem or plugin for cakephp that does this and hope a website uses it. It would be very good data for research into the psychology of choosing passwords.
Just imagine all the potential findings!
I think we should work on an opensource gem or plugin for cakephp that does this and hope a website uses it. It would be very good data for research into the psychology of choosing passwords.
Just imagine all the potential findings!
Maybe I'm paranoid, but I advice to my customers that any passphrase with an entropy below 80 bits is insecure, around 140 bit is fairly secure, and anything above 200 bit entropy is very secure.
I can understand why you'd want to be more careful with generated passphrases, but 80 bits of entropy is like a 16 character long alphanumeric password. That seems fairly secure to me for most purposes.
Unless the hash is 'broken' but then your options are fairly limited anyway.
Unless the hash is 'broken' but then your options are fairly limited anyway.
80 bits of entropy is between 12 and 13 visible ASCII characters and between 14-15 ASCII letters.
Yes, if you go below that I'd say it's insecure. It's a conservative estimate, I admit. An entropy of 60 might be okay, too, but there is no harm in making passwords more secure.
Yes, if you go below that I'd say it's insecure. It's a conservative estimate, I admit. An entropy of 60 might be okay, too, but there is no harm in making passwords more secure.
> but there is no harm in making passwords more secure.
Well, it makes them harder to remember and slower to type (and increases the chance of making an error and having to type it again). I hesitate slightly to do things that require me to type my long password. :-)
Well, it makes them harder to remember and slower to type (and increases the chance of making an error and having to type it again). I hesitate slightly to do things that require me to type my long password. :-)
Assuming that password complexity is the weak link in their practices.
Uhm, no, independently of that...
Going to just add some thoughts here:
It isn't quite right to treat each word as a symbol either from the information theoretic standpoint. If an attacker /knows/ your password is xkcd style words there is still cracking cost to choosing to crack using only that strategy.
To achieve similar entropy for a classic password you would need say, 8 characters A-Za-z (~7.71 characters required to achieve 44 bits of entropy) (https://en.wikipedia.org/wiki/Password_strength)
But now the cracker has to run two strategies (word based, and classic character based). Granted it is only "times two" and not an exponential increase you get by increasing your number of available symbols or better yet total number of symbols.
In a "readable words dictionary" with say 75000 words you can achieve ~64 bits of entropy. This is also completely ignoring some facets of password storage and hashing. For example, ASICs are good, but not great against scrypt since it is memory hard. So storage format matters a lot. In an offline attack of the worst case known scenario (MD5) lets just call it 25,000-100,000 MH/s in your house without a crazy amount of expense.
That works out to a (on the shortest end of things for 'desktop cracking') about 5 - 6 years. That password is safe for some time against password dumps and such. No one but a high resource attacker that wants your specific password is going to crack it in the near future if a password like that was leaked as an md5 hash. No cute articles about 90% success rates of cracking, etc.
So, the security always comes down to the needed security. Right now 5 years is pretty good. You hopefully change your passwords every 5 years. Add in a 5th symbol in word based passwords and you hit 80 bits of entropy though. That takes the crack time up to about 383,000 years. It is such a vast difference it isn't even funny.
So: 5 or 6 years vs 383,000 years. Basically, use a 5th word. This is all for a desktop cracker, but even someone with 10000 times the desktop crackers resources (e.g. ~50000 GPU, or at least several hundred ASICS) would still be working on a scale of decades.
It isn't quite right to treat each word as a symbol either from the information theoretic standpoint. If an attacker /knows/ your password is xkcd style words there is still cracking cost to choosing to crack using only that strategy.
To achieve similar entropy for a classic password you would need say, 8 characters A-Za-z (~7.71 characters required to achieve 44 bits of entropy) (https://en.wikipedia.org/wiki/Password_strength)
But now the cracker has to run two strategies (word based, and classic character based). Granted it is only "times two" and not an exponential increase you get by increasing your number of available symbols or better yet total number of symbols.
In a "readable words dictionary" with say 75000 words you can achieve ~64 bits of entropy. This is also completely ignoring some facets of password storage and hashing. For example, ASICs are good, but not great against scrypt since it is memory hard. So storage format matters a lot. In an offline attack of the worst case known scenario (MD5) lets just call it 25,000-100,000 MH/s in your house without a crazy amount of expense.
That works out to a (on the shortest end of things for 'desktop cracking') about 5 - 6 years. That password is safe for some time against password dumps and such. No one but a high resource attacker that wants your specific password is going to crack it in the near future if a password like that was leaked as an md5 hash. No cute articles about 90% success rates of cracking, etc.
So, the security always comes down to the needed security. Right now 5 years is pretty good. You hopefully change your passwords every 5 years. Add in a 5th symbol in word based passwords and you hit 80 bits of entropy though. That takes the crack time up to about 383,000 years. It is such a vast difference it isn't even funny.
So: 5 or 6 years vs 383,000 years. Basically, use a 5th word. This is all for a desktop cracker, but even someone with 10000 times the desktop crackers resources (e.g. ~50000 GPU, or at least several hundred ASICS) would still be working on a scale of decades.
The actual XKCD password generator suggests using padding as well.
Using non-alphabet padding symbols (even if they are all the same and as trivial as 111 or !!! at both ends) will improve entropy by a decent amount while being just as easy to remember.
However the password itself is still only 1 aspect of security. There are many cases where there are far easier attack vectors that don't including cracking hashes.
Using non-alphabet padding symbols (even if they are all the same and as trivial as 111 or !!! at both ends) will improve entropy by a decent amount while being just as easy to remember.
However the password itself is still only 1 aspect of security. There are many cases where there are far easier attack vectors that don't including cracking hashes.
Using non dictionary words should help greatly.
There are probably less non dictionary words than dictionary words, perhaps better advice is to use words from a random language other than your own so the password cracker might make a wrong assumption and waste his time?
> perhaps better advice is to use words from a random language other than your own
I think you may have missed the point that the XKCD cartoon was making. The question here is NOT how to generate passwords that are hard for computers to guess. That's a solved problem: simply generate a 128-bit string with a secure random number generator, and that's your secure password that computers can't guess easily.
The PROBLEM is to generate a password where the ratio of ease-for-humans-to-remember to ease-for-computers-to-guess is maximized. Using words from a language other than your own is NOT a good way to maximize this. Introducing just one more randomly-generated word from your own language will be far more effective by this criterion.
I think you may have missed the point that the XKCD cartoon was making. The question here is NOT how to generate passwords that are hard for computers to guess. That's a solved problem: simply generate a 128-bit string with a secure random number generator, and that's your secure password that computers can't guess easily.
The PROBLEM is to generate a password where the ratio of ease-for-humans-to-remember to ease-for-computers-to-guess is maximized. Using words from a language other than your own is NOT a good way to maximize this. Introducing just one more randomly-generated word from your own language will be far more effective by this criterion.
You don't need to speak a language, much less be fluent in it, to use some words from it in a password. Although I am not fluent in any language other than English, I know words in Irish Gaelic, German, Japanese, Spanish, and some other languages. It's easy to use a word I know in one of those languages as part of a password. (I do have one password that does contain a word from a language I don't speak.)
Up to a point, no doubt - but there is a good chance that the words you know from a language that you do not speak come from a small subset that is known by many non-speakers, so they may appear in cracking dictionaries, possibly gleaned from passwords that have been broken, or because they do sometimes appear in articles written predominantly in your language.
Just for completeness, your strategy assumes the attackers are assuming a particular language - which I would guess is probably the right thing for them to do, if they are looking for low-hanging fruit.
Just for completeness, your strategy assumes the attackers are assuming a particular language - which I would guess is probably the right thing for them to do, if they are looking for low-hanging fruit.
On the flip side, most of the world is multlingual or have at least been exposed to one other language. If you speak more than one language, mixing words from two or more basically renders dictionary attacks impossible, especially with number of languages and type unknown. I have words from non native languages in my passwords and they are just as easy or easier to remember.
What about having your own pattern for upper case and lower case in the words ?
Like, say, every 3rd letter of the words you choose will be upper. hoRse or baTtery etc...
Like, say, every 3rd letter of the words you choose will be upper. hoRse or baTtery etc...
Someone who actually studies this stuff can maybe correct me but I think this adds only a single bit of entropy (multiplies the possible combinations by 2) and thus is almost negligible.
Nope, it's one bit extra entropy per character. The attacker must try all possible capitilazations of each word (horse, Horse, hOrse, HOrse, etc).
You've doubled the character set so it's not negligable.
You've doubled the character set so it's not negligable.
> There are probably less non dictionary words than dictionary words
There are infinitely many non dictionary words.
I also didn't say to use _strictly_ non dictionary words.
There are infinitely many non dictionary words.
I also didn't say to use _strictly_ non dictionary words.
> 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).
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).
Adversaries will simply use common pass-phrase words as though they were part of a larger alphabet. Depending on the distribution/definition of "common", 2-4 word passphrases are then much worse than an 8 character password, for exactly the reason you state.
I'm not sure what point this is meant to counter.
Asking because I really don't know:
How do they know that a given hash is multi-word passphrase versus average joe's single "word" character jumble?
If they flip to using words as part of their alphabet and I'm using 4 unique words, they still have a large search space because the English language has so many more words than the alphabet has letters.
So do they just do both? Seems like a huge expansion in computational work.
If they flip to using words as part of their alphabet and I'm using 4 unique words, they still have a large search space because the English language has so many more words than the alphabet has letters.
So do they just do both? Seems like a huge expansion in computational work.
They might not know and might have to guess, or do both. This makes it harder for them, but it's hard to quantify how much harder, so it's reasonable to assume the worst case, i.e. that they do know the procedure with which you generated the password.
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.
[1] https://xkcd.com/936/
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/
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.
> Related problem: sites that don't let you paste into the password field
Run Firefox
Change this about:config option "dom.event.clipboardevents.enabled" to "false".
No more blocking of pasting into password fields by any site.
Run Firefox
Change this about:config option "dom.event.clipboardevents.enabled" to "false".
No more blocking of pasting into password fields by any site.
My favorite HN memory on this subject: https://news.ycombinator.com/item?id=4410350, "T-mobile password reset does not allow you to type the letter 'V'"
In those cases, either I quit the site or, in a good mood, I open the dev tools...
Yeah, fortunately products like keepassx can auto-type into those fields, which works around the problem, but it's still absurd...
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.
Really I should be thanking Apple though for helping me save money.
I'm not familiar with the experience that you're describing; does an in-app purchase itself prompt security questions directly? Or do you need to reset your AppleID password and that's why you're getting security questions?
It probably needed those questions answered once, but he can't answer them in time so his account is stuck in the "needs to verify" state.
I managed to get it once, somehow, only to be asked again the next time.
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?
I've never noticed that, because I never typed my password but I guess it's similar to what facebook[0] does in order to prevent caps lock issues?
[0] https://security.stackexchange.com/questions/68013/facebook-...
[0] https://security.stackexchange.com/questions/68013/facebook-...
I still find sites that only allow 20 chars of a-zA-Z0-9. It should be criminal.
I ran across a site with the most insane password requirements awhile back:
Some of this is from memory, so it might not be exact, but the requirements were:
1. Passwords must be exactly 14 characters long
2. Passwords must contain all 4 character classes (upper case, lower case, numbers, symbols)
3. Symbols must be from the set (! , . : ; " $ % & *) -- This wasn't specified, I had to figure it out from trial and error.
4. No more than two characters from any one class in a row (so aaBB is ok, aaaB is bad)
5. Passwords must be reset every 3 months
6. Passwords can not be similar to any previous passwords (it's vague what "similar" means)
7. Passwords must not be stored externally (IE, no copy/paste, no password managers)
Luckily I don't have to use that system anymore, because it was just completely awful. To be fair, they also had smartcards that didn't require this password nonsense, so I think the requirements were partially to encourage people to use the smartcards instead.
Some of this is from memory, so it might not be exact, but the requirements were:
1. Passwords must be exactly 14 characters long
2. Passwords must contain all 4 character classes (upper case, lower case, numbers, symbols)
3. Symbols must be from the set (! , . : ; " $ % & *) -- This wasn't specified, I had to figure it out from trial and error.
4. No more than two characters from any one class in a row (so aaBB is ok, aaaB is bad)
5. Passwords must be reset every 3 months
6. Passwords can not be similar to any previous passwords (it's vague what "similar" means)
7. Passwords must not be stored externally (IE, no copy/paste, no password managers)
Luckily I don't have to use that system anymore, because it was just completely awful. To be fair, they also had smartcards that didn't require this password nonsense, so I think the requirements were partially to encourage people to use the smartcards instead.
20? Haha, I've seen a limit of 10 this year (for my garbage collection company).
My bank (SMBC) requires exactly 4 digits for the online banking password...
Yeah, for some reason banks and credit card providers seem to be worse at this than anybody else.
Mine requires 6 digits to get in, but then for every real transaction I have to inform another 6 digits from an RSA app installed on my phone.
My bank used to do that. They finally switched to a fancy Web 2.0 interface a couple of years ago that let you use real passwords.
I have a password at work which is required to be EXACTLY eight characters, with no special characters.
Took me a long time to come up with a password.
Took me a long time to come up with a password.
That's secure enough if it's randomly generated.
Yes, but the limit being present at all potentially highlights a problem and it may be one of many. You shouldn't need an upper limit to password/passphrase size and if you have to have one because something breaks otherwise then the site really is doing something wrong. If they are getting that so wrong, what else problematical is sat waiting for Mr Hacker to discover?
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.
Lately citing the NSA's change in position has been convincing enough and we don't get nearly as much push back.
You mean NIST not NSA, right?
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.
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.
The beauty of easy to remember passwords is that you don't have to use the same one everywhere. At least not on your high value accounts.
In my keepass DB, I have 295 passwords. Are you suggesting that I should manually remember 295 unique complex passwords, rather than one long, secure password (that I cycle every 6 months or so), and a 2 factor key?
Also, my password manager protects me against phishing attacks such as being sent a password reset for my iCloud account, and clicking on the link to icloud.malicious.com. if my PW manager doesn't fill it in automatically, I don't give it my credentials as there's something wrong.
You also imply that value is a fixed cost. For instance, in 2008 when I signed up to facebook, it was a low value account, now it's a high value account.
Also, my password manager protects me against phishing attacks such as being sent a password reset for my iCloud account, and clicking on the link to icloud.malicious.com. if my PW manager doesn't fill it in automatically, I don't give it my credentials as there's something wrong.
You also imply that value is a fixed cost. For instance, in 2008 when I signed up to facebook, it was a low value account, now it's a high value account.
The problem with "remembering" multiple different "easy to remember" passwords across multiple cites is that there is a limit to how many "the password for site X is Y" associations you can hold in your head before you start forgetting which password belongs to which site.
Just use a proper password manager, then you can have proper randomly generated passwords that do not each need to be remembered (and their association to a site remembered as well).
Just use a proper password manager, then you can have proper randomly generated passwords that do not each need to be remembered (and their association to a site remembered as well).
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'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.
Hopefully never, because hardware will always remain something you can physically lose.
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.
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.
My bank already has this (a little card reader that checks my debit card pin). Seems reasonable to assume this kind of tech could be used more widely.
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?
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?
No.
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.
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.
Excellent. Thank you.
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.
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.
Aha! I was wondering if there were some "gotchas" to watch out for in the real-world systems.
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.
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.
Yes in movies or tv shows they do when you see the decipher progression on screen :) But as stated by others no.
Not trolling, I guess for people that don't know how it works it can be confusing.
Not trolling, I guess for people that don't know how it works it can be confusing.
I know better than the tv stuff, but what I don't know is if, for example, it takes 20 iterations of a hashing algorithm to match the hash, if there were statistical, or other measurable, differences that converged as you started working your way up to 20. Or, if you knew the iterations, but you only had a few characters right in the guessed password, if there was a way to know (decreasing entropy of the hash or something). I don't know the mathematics behind the algos very well.
Again, not trolling !
Your comment just make me thought of that, and how it makes me laugh each time I see that on a movie/show. And also realize that there is surely a (big) part of non-tech people that may think it's how it works.
If an encrypting method "tells" you you're getting close, it will be a bad one.
(and sorry if you took it personaly. Next time I'll check the poster profile first :)
Your comment just make me thought of that, and how it makes me laugh each time I see that on a movie/show. And also realize that there is surely a (big) part of non-tech people that may think it's how it works.
If an encrypting method "tells" you you're getting close, it will be a bad one.
(and sorry if you took it personaly. Next time I'll check the poster profile first :)
No worries. I didn't take it personally. I just wanted to clarify that I wasn't trying to ask the "obvious" question- I was asking about way more subtle things. Actually, I wasn't sure I would get a response if anybody knew that there was a way to tell. But I decided to ask anyway.
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)
Why block anything at all? If I want my password to be unicode and emoji, what's the downside to the site?
I assume they're hashing all the passwords anyway.
I assume they're hashing all the passwords anyway.
hint: they're not all hashing the passwords
I always wonder what kind of magic those websites do with the string. Hashing has become so simple. When you hash you don't have to worry about special chars (encoding issues though). It's only when you have bad practices that you should worry about ;") in the password field.
I wonder how many sites have been taking down by SQL injection attacks inside of a password. That would take something of a perfect storm of bad design, which is why I'm pretty sure there are sites out there that are vulnerable.
> I assume they're hashing all the passwords anyway.
Bad assumption. And many that do hash are using MD5 and don't bother salting.
Bad assumption. And many that do hash are using MD5 and don't bother salting.
> sites that disallow special characters
This is often an external code smell of not hashing the passwords but instead storing them as plaintext in a CHAR(8) field in a SQL database somewhere.
This is often an external code smell of not hashing the passwords but instead storing them as plaintext in a CHAR(8) field in a SQL database somewhere.
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 :)
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 :)
[deleted]
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.
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?
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).
People say the weakest link is the user in passwords, and that's often true. But for more security conscious users the weakest link is the helpdesk. It may not even be where you expect. Plenty of people have been hacked because the hacker called the support line for their registrar, hosting, email provider, or ISP and got a password changed without any form of hard verification.
It can be extremely frustrating to do everything right and then have your knees cut off by some script reader in a cube farm somewhere.
Also, if you do email verification for accounts, whenever someone changes their email send one to the old account saying 'Hey, this is being changed, are you OK with it?" and if they say no, revert the email and reset the password on the spot.
It can be extremely frustrating to do everything right and then have your knees cut off by some script reader in a cube farm somewhere.
Also, if you do email verification for accounts, whenever someone changes their email send one to the old account saying 'Hey, this is being changed, are you OK with it?" and if they say no, revert the email and reset the password on the spot.
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.
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
They won't. If it's a random enough 7 words or more passphrase, it will only become "not enough" if the key generation algorithm is broken.
you know what "correct horse battery stable" is now one of the popular passwords, just like "qwerty".
... followed by "correct horse battery stable 1", "correct horse battery stable 11", "correct horse battery stable 111"
those passwords would probably be safe to use because the correct word is "staple"
Actually a good cracker would probably catch a simple substitution like that as well.
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.
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.
No paywall: http://archive.is/JNiVT
a) 2FA
or
b) use the "forgot my password" option every time
or
b) use the "forgot my password" option every time
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.
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.
The Daily Mail coverage is worse...
http://www.dailymail.co.uk/sciencetech/article-4771194/The-m...
I now predict an uptick in people using 'correctbatteryhorsestaple' as their password...
http://www.dailymail.co.uk/sciencetech/article-4771194/The-m...
I now predict an uptick in people using 'correctbatteryhorsestaple' as their password...
"The Daily Mail coverage is worse"
It always is.
It always is.
> I now predict an uptick in people using 'correctbatteryhorsestaple' as their password...
At least that's slightly better than "correcthorsebatterystaple" which appeared in the XKCD. The really funny part is that I automatically noticed this when reading your comment because I have "correcthorsebatterystaple" so fully committed to memory that I noticed when you deviated.
At least that's slightly better than "correcthorsebatterystaple" which appeared in the XKCD. The really funny part is that I automatically noticed this when reading your comment because I have "correcthorsebatterystaple" so fully committed to memory that I noticed when you deviated.
> I automatically noticed this when reading your comment because I have "correcthorsebatterystaple" so fully committed to memory that I noticed when you deviated.
For me it was the opposite. My brain automatically read it as "correcthorsebatterystaple" despite what was written, just as it would with a small typo in a word.
For me it was the opposite. My brain automatically read it as "correcthorsebatterystaple" despite what was written, just as it would with a small typo in a word.
Accidental deviation. What I wrote IS how I've remembered it apparently. Maybe because a battery horse makes more sense to me than a horse battery. Not sure. either way, I'll start using it as my password and see how long it takes to get pwned.
Oh, but the cartoon has the battery connected into the horse :)
What goes to show something, because most people discussing passphrases do not care to point that it's about mental images, not text. It's either so obvious that it doesn't have to be said, or so non-obvious that nobody gets it, even after reading the XKCD.
What goes to show something, because most people discussing passphrases do not care to point that it's about mental images, not text. It's either so obvious that it doesn't have to be said, or so non-obvious that nobody gets it, even after reading the XKCD.
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...