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):
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.
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.
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. :)
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.
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.
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).
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
> 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.
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.
> 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.
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.
> 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.)
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.
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.
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.
> 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. :-)
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.
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.
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.
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.
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.
> 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).
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.
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.
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.
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.
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?
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 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.
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.
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.
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.
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).
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 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.
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)
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.
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 :)
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).
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.
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.
> 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.
> 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.
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.
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...