Google recommends pronounceable passwords Google has updated its password manager to recommend pronounceable passwords within its flagship Chrome browser. The experimental feature was the latest development which could make it into the regular versions of Chrome as part of steady improvements to its password capture, storage and generation. Chrome evangelist and …
Generally speaking, hard-to-break passwords are hard-to-remember. But it is not the fate. It would be easily possible to safely manage many of high-entropy passwords with the Expanded Password System that handles images as well as characters.
Each image/character is identified by the image identifier data which can be any long. Assume that your password is “bowbow” and that those characters (treated as images) are identified as X4s&, eI0w, and so on. When you input bowbow, the authentication data that the server receives is not the easy-to-break “bowbow”, but something like “X4s&eIwdoex7RVb%9Ub3mJvk”, which might be automatically altered periodically or at each access if required.
When such high-entropy data are hashed, it would be next to impossible to quickly crack the hashed data back to the original password. Give different sets of identifier data to “bowbow” and the different servers will receive all different high-entropy authentication data. Brute-force attacking of “bowbow” and other similarly silly passwords would perhaps take less than a few seconds with dictionary and automatic attack programs but it could be an exhausting job when criminals have to manually touch/click on the display with their fingers.
I'm not sure what "false premise" Graham Dawson is complaining about (Graham, care to elaborate?), but I agree Schneier's comment about the XKCD method is rather glib:
Modern password crackers combine different words from their dictionaries ... This is why the oft-cited XKCD scheme for generating passwords -- string together individual words like "correcthorsebatterystaple" -- is no longer good advice. The password crackers are on to this trick.
But of course "on to this trick" isn't an objection in and of itself, because of Kerckhoff's Principle: attackers shouldn't be able to determine the password1 even if they know what method you use to create it.
I keep a randomized word list that contains a bit under 100,000 words. Four words drawn at random from that list gives me close to 1020 possible combinations. So attackers can test on the order of 107 ("eight million per second", again from Schenier) to 1010 (supposing a cluster of 1000 such machines)? That still leaves them with, on average, a job that will finish in 5x109 seconds or so. It's a risk I'm willing to run.
Let's say that consciously or unconsciously I actually decline to pick any of 90% of the words in my dictionary, and attackers have exactly the same dictionary to work with. Now I'm down to 1016 possibilities, and the super-attacker with a 1000-machine cluster only needs around 500,000 seconds to determine my password. Why, that's less than a week! What a terrific use of resources by that attacker, in this extremely unlikely scenario.
And, of course, after picking my words I tweak the passphrase a bit, just to add a little to the number of permutations an attacker has to try, and to satisfy ill-conceived "password strength" filters. And perhaps I use five words rather than four. And so on.
Attackers are free to "combine words from their dictionaries" to create candidates for my passphrase preimages. Combinatorial explosion is overwhelmingly still in my favor.
Sure, if you pick from, say, the 100 most common English nouns and the 100 most common English adjectives (a dictionary which, incidentally, misses all four words in "correct horse battery staple"), you're working from a relatively small entropy pool; there are only 2004 possibilities (or 200P4, about 3% less, if you don't allow a word to appear more than once). Even with the measly 8-per-second machine someone could crack that in a second or two, if they have the same dictionary. But increase your dictionary to 1000 words and pick five of them, and you're back to several days' work effort even for a dedicated attacker with a cluster.
It's worth reading the comments to Bruce's post. Many people take exception to his critique of Randall's method.
Of course, it's also worth noting that what Bruce says is the "XKCD scheme ... is no longer good advice". A lot depends on how large the dictionary is, and even more importantly how words are chosen from it. Some people suggest that Randall's scheme (at least as typical users understand it) involves the user trying to think of four random words that can then be visualized. You really want a stronger randomization process - building a dictionary of "words the typical user is likely to be able to visualize" isn't trivial, but it's still a heuristic an attacker could use to prune the dictionary. (And given sufficient input in the form of known passphrases of this type, it would be trivial to train an HMM or similar algorithm to rank words.)
1Or, better, passphrase.
> attackers shouldn't be able to determine the password even if they know what method you use to create it
Yes, if every user applies a cryptographically sound key generation technique this is indeed the theory. I think Bruce's general point is that if you ask the average punter to string 3 words together the amount of entropy is far from what it looks like, and so the algorithm is not cryptographically sound - you either need longer key lengths (more words), or a new algorithm.
> Why, that's less than a week!
I assumed that he's talking about rainbow table attacks working backwards from a website which has leaked a hash, the issue is not processing time (you only have to generate the rainbow table once per salt), but the amount of space it takes to store the tables.
Assuming most users pick from a relatively small pool of words in common use, it's not an insurmountable search space. Yes, the total search space in theory is pretty enormous but, I suspect many people have a password with "Cat" in, and many more with "Dog", and more than a few with "Password". Hackers only have to skim off the 1% of the easiest passwords to get into a system- not the 1% of the geeks with the uber difficult ones which are hard to remember ;P
His example of "This little piggy went to market" shows the problem. That is in my password dictionary. When the "make up a password from the 1st letter of words from a song" started to be popular, I ran a small poll asking people to write a line from 3 Beatles songs and 3 songs by a popular country artists. Several hundred people responded and there were less than 100 unique lines and 10 lines were common to something like 80 or 90% of the respondents. The result of separating the lists based on their likely musical taste resulted in some scary guesses on which lines they would pick. When the same thing was run latter without requesting the specific musicians, the results were tainted by the previous request.
/Black Helicopter since the some of the guinea pigs were supposed to keep them secure
The update is Google's latest encroachment into the territory of online password management dominated by LastPass and 1Password, who could well feel threatened as Chrome builds in functionality they once offered as third-party value adds.
Browses have offered some kind of form fill/password manager for years, and password managers still sell, so I don't see Google's changes as any threat to them.
Personally, I prefer a standalone password manager as they are genuinely cross-browser and cross-platform. (Oh, and in this particular case, not Google. "Don't be evil", my arse...)
Depends on your usage requirements really. Cloud-based is risky; triply so if you're trusting some other bugger's code and encryption.
On the other hand, by maximising entropy and letting a computer remember it for you; you're minimising to virtually zero brute-force and guessing attacks.
That takes me back - it reminds of the hilarious (and I believe genuine?) support call where a user complained that although the password obscenity filter was a useful feature, it lacked internationalisation, then helpfully provided translations to several languages. The footnotes were the best bit - e.g. "the female breast is never offensive in Danish". It would be great if someone still has a copy.
"We had some fun understanding the cultural differences.
One small example was that, if I recall correctly the Swedes had far fewer hangup about bodyparts. For example there was not 'dirty' equivalent for 'breasts' in Swedish, or so we were told by our Swedish friends/peers at the time. ( Or maybe they just wanted to have a few good ones slide past the test? :-) "
And there was me thinking that you were never actually supposed to tell anyone your passwords, making pronouncability meaningless (unless of course you tend to mumble them to yourself whilst typing them). Not to mention ending up with words that are recognisable and so memorable for anyone who may have a view of your keyboard whilst you type and are key-reading.
In two words, "sod that" - I'll keep my shifted and substituted passwords thanks. I can quite easily remember the baseline word(s) from which they're generated, but what gets typed and used is moved from that.
While I, personally, like the "Correct Horse Battery Staple" method from xkcd (with my own modifications), I have had my own, similar, method for a while, which works around some limitations (like stupid sites which insist your password can be no longer than 10 characters, alpha-numeric only).
Firstly, come up with a phrase with 8-10 words (easy to remember), then use the initials of those words, along with some easy-to-remember substitutions.
Example:
"The Register is good for amusing IT news" becomes (without revealing some of my unique rules): "TRig4aITn". I haven't analysed it, but I believe it makes reasonably strong passwords, which are very easy to remember.
This post has been deleted by its author
When I am talking to someone who does not understand that having a single short word with a number at the end is not secure it is great to be able to point them to XKCD. It is succinct, to the point and easily understood. Additionally this can then act as a basis to discuss with them how to create passwords that they can remember and yet be orders of magnitude more secure, however, if all they get out of the process is that they create passwords that improve even slightly, it is still better than where they were.
The secure files are usable on a Wintel PC, WinRT tablets, Android, PocketPC, iPhone, iPad, Mac OSX, Blackberry, J2ME phones, PalmOS, Linux, and that's just what's mentioned on the site.
I can't remember, and don't have to remember secure passwords. More so, I don't have to remember which phonetically-sounding password I used at what point - I have hundreds of the buggers, I can't remember that, and I'm not about to re-use passwords either.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
