The problem with password recovery questions is that websites use them at all. What I do is generate a random string for the answers and store those in my password manager as well. So the answer to “What’s your grandmother’s maiden name?” is going to be “xlzy385671L%aiop!”
Is she from Omicron Persei 8?
My preferred method is to use the Passwordcard as pioneered by http://www.passwordcard.org/ to generate a list of possible passwords, which is kept in my wallet, and the key to which password is used where is kept in my Moleskine. I also make sure never to recycle a password, and have a second Passwordcard for throwaway registrations.
The Ars Technica article Mr. Schneier mentioned suggests the XKCD-approach and it boils down to length=security.
After reading the AT article I started using a password manager (Lastpass, because it has plugins for every known Browser on Linux, OSX and Windows) with a 25 characters master-password build with the XKCD approach and using a non-englisch language.
I like to do the first 10 letters of sha1(websitename + personalpassphrase) + arbritaryextracharacters, so for example my paypal password could be
sha1(“paypal” + “mypassword”) + “ABCD” = c101af950aABCD
Easy to remember, different for every site (very important!) and difficult to brute force.
Sorry, I consider most of the article as complete BS.
Just because a strategy is commonly used doesn’t make it bad.
The biggest weakness of the passphrase scheme is when people make syntactically-correct passphrases, so crackers can make things a little easier by guessing “[subject][verb][predicate]” or whatever.
If those words are completely syntactically incorrect, or, easier still, just a string of nouns, then the entropy is preserved.
What happened to using password cards?
You generate an array of random strings and then use a system to pull a password out of it making the password easy to reference, and hard to figure out by thieves using computer systems or someone that just stole your shit.
I’ve started using a password manager not too long ago. It’s a little annoying to have to be at my computer to log into a site instead of using a common password like I used to, but, well, it’s way more safe (duh).
Anyway, the websites that annoy me the most are the ones that don’t tell you the limits of what they accept. Like, they don’t take special characters, but don’t tell you. Or they have a length limit, but don’t announce it. I especially hate the ones that only give you a lower limit: “Password must be at least 6 characters long”, generate a random 24 character password, fails, try 20, fails, try 16, fails, try 12, there you go!
Agreed. The Xkcd approach assumes that you are able to randomly choose four words out of a dictionary of 2048 words. Humans are probably horrible at doing this, but there’s no reason you couldn’t write a password generator that would give you four random dictionary words. And even though they’re dictionary words, you still get Xkcd’s cited 44 bits of entropy.
Just don’t use “correct horse battery staple”
I’m so disappointed that even Schneier referred to the Ars Technica stunt where they cracked a bunch of passwords. They were using MD5 hashes with no salt: a storage form that is incredibly weak and super easy to crack. Who would recommend using that on a significant system?
More recently, the Adobe breaches and others also exposed a lot of passwords. But at the end of the day, the systems for storing passwords were the weakest link, not just the passwords that were selected.
To be clear: The reason something like “qeadzcwrsfxv1331” was cracked in the Ars stunt was because it was stored and disclosed in a decades-old, known-broken format—not because that is a crackable password when used with a proper cryptosystem. And “123456” is always a weak password, regardless of storage system. There’s nothing Adobe could do about the 1M users who used it as a password.
To discuss crackability independent of the storage system/format is simply wrong. It omits the responsibility that software authors have for passwords stored in trivially crackable formats. If an ISP were found storing passwords encoded by Base64, would we blame the user who chose Jennifer4April1992 as his password? I hope not.
Passwords? I like to use hashes of large sequences of transcendental numbers or hashes of jpg pictures (kids / grandkids). I’m pretty sure, they’re unbreakable (2 ^ 128) and as they’re pasted from memory, even key-loggers are ineffective.
i’m shocked, SHOCKED i tell you, that schneier - who created and still uses a password manager that generates passwords - would be advocating methods of choosing passwords.
randomly generated passwords are clearly superior to chosen ones. computers can create and remember passwords much more easily than we can, and it scales better too.
also, what’s this about not reusing passwords for accounts you care about? most people aren’t aware of how their various accounts can be misused so it’s best to simply not reuse any passwords at all.
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.
The attacker will feed any personal information he has access to about the password creator into the password crackers…
This is a plausible argument if you are indeed trying to think up “random” words – which aren’t random at all, as Bruce Schneier points out. The solution is to pick the words randomly. BTW, beware of computer-generated “random” numbers. Google it. Use dice and a dictionary (see diceware).
Even worse are the ones that appear to accept say a 16-character password but truncate it to 8 without telling you. And even that would work if they also truncated it in the same way when you try to log in later. But they don’t.
I ran into that recently, too. When I did the “I forgot my password” thing, they emailed me my password in plain text (!) in the untruncated form. Somehow, the site kept the original password as a check, but truncated whatever I input into the password field when I tried to log in. I don’t even know.
I make it a point not to store my credit card info there…
Like I said above - if (a) the dictionary from which the words are picked is 10,000 words long, and (b) the words are picked at random, then there are 10,000^4 = 10^16 possible passphrases. The passphrase is just a way of representing a random number between 1 and 10,000,000,000,000,000 as something a human mignt remember.
And brute forcing a random number from 1 to 10^16 just isn’t feasible. It doesn’t matter if the attacker knows the method you’ve chosen to uniquely encode it in a human-memorable form - there are just too many possibilities to try them all.
But - picking the numbers truly at random is very important. Get a dictionary and devise a way to pick a properly random page and entry on the page. If you’re using a Windows computer, you can fire up a command window and use a command like “set /a page=%RANDOM% % 1-200” and then “echo %page%” to get a random page number from 1 to 200, that isn’t weighted toward any particular sections of the dictionary. You could look up methods based on dice, or picking cards from a well-shuffled deck.
I was musing about the idea of taking a number string - a phone number I remembered - not my own - perhaps. And then interspersing that number with a word/string combo. For example:
910 - 555 - 1682
forms the password:
While you are pointing out how the system can be strong, I was picking at the weaker links in the chain.
See, if you can figure out and maintain such a complicated method of choosing a password, then you can probably choose any other method and make it safe as well.
But you forget that the strong point of the XKCD system is that its easy to remember a tough password, but when your random dictionary words are defenestrate erinaceous pauciloquent and floccinaucinihilipilification the system becomes self defeating doesn’t it? You might as well memorize “759$0%343,9!@6067!3#%”.
Oh and you forget, just because a password is impossible to crack, doesn’t mean someone won’t try.