Indecypherable Passphrases

Lorrie Faith Cranor: What's wrong with your pa$$w0rd?

18 min.

--
Jeff Liebermann     jeffl@cruzio.com 
150 Felker St #D    http://www.LearnByDestroying.com 
Santa Cruz CA 95060 http://802.11junk.com 
Skype: JeffLiebermann     AE6KS    831-336-2558

Passphrases are not needed for the simple logins she's talking about:

"You don't so much need them for logging into a website or something else o n the Internet. In those situations, you get less benefit from using a high

-entropy passphrase. Attackers will never be able to guess a trillion times per second if each guess requires communicating with a server on the Inter net. In some cases, attackers will own or take over the remote server -- in which case they can grab the passphrase as soon you log in and send it, re gardless of how strong or weak it is cryptographically."

TED talks are disappointing 99% of the time. The topic sounds like it may be interesting but the speaker chosen or the job is usually underpowered.

OK, so ?monkey? it is!!!

Or, in handy comic form:

Matt Roberds

passphrases are pretty easy to find: you get a dictionary and brute force a combination of the word in the dictionary. Arsthenica published a couple o articles on password cracking last year or so (can't find the links right now sorry). At the end the best for now is to use password of at least 16 character chosen randomly like "zcMWSF54Py5FmnK3" and use a password manager to keep track of them. And of course a different password for every website.

Bye Jack

--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

found one: there were others:

Bye Jack

--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

You're confusing passWORDs (which are typically short -- a dozen or so characters) with passPHRASEs (which can be thought of as "sentences", of a sort).

The scheme outlined in the OP encodes about 13 bits into each word. So, 7 words yields about 90 bits of entropy.

If you applied the same *random* (i.e., dice roll) algorithm to selecting passwords (e.g., six coin tosses to select one of the 64 characters from [0-9A-Za-z!@#$%^&*():;] -- encoding 6 bits per character), you'd need about 15 characters to get an equally "random" selection.

The "random-ness" is the aspect that is missing from password/phrase selection. There tends to be a bias towards using more alphas than digits or symbols; certain digits see more use than others; etc.)

Note that there are already (fast) algorithms that will crack "long" passwords -- if the user is naive enough to use all alphas or just alphas and digits. E.g., I think 14 character rainbow tables for LM hashes will fit on a single CD (digits + all alphas). Even adding symbols (assuming they are used "randomly" and with the same probability as any other character) to the list of expected characters means you can store the tables on a DL DVD.

NT hashes need significantly larger tables. But, you can fit a many TB portable drive in a coat pocket!

Of course, this assumes you have access to the hash (not something that is likely for a web based service -- but *trivial* for a "PC"). OTOH, if you use the same password in "locally accessible" places, then cracking it locally gives you access to the "remote" service, as well!

Moral of story is your "secret" is probably not "good enough", despite how "long" you *think* it is!

5 comics later:

People have set up remote monitoring of the vending machines at MIT, so I wish somebody would set up a couple of cameras to do this.

no, that's the problem. You are assuming that a passphrase can be "guessed" only by brute forcing every character, but is not like that, you can just get a dictionary and try a combination of every word in the dictionary, it's much faster. Read the article I linked in my other post.

[CUT]

Moral is: if it's easy for you to remember, it's easy for a computer to find. If it's not easy for you to remember it could be for a computer to find.

Bye Jack

--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

Did you read the article in the OP? The "passwords" that it generates are "truly random" (assuming fair dice are used). So, a cracker must have a dictionary containing 1,237,940,039,285,380,274,899,124,224 different entries -- hashes, in your case -- to address each of the unique passwords that *might* be encountered (assuming "7 words" suggested by the OP).

I don't think *you* read the article! Or, perhaps misunderstood how the attack works.

First, it relies on having already "compromised" the system -- to gain access to the password hashes. Without that, you may as well just sit down and *guess* account names and *guess* their passwords. And, do this through the narrow pipe that the system presents to you (the "login" prompt).

Seeing the hashes has been a known exploit for decades. That's why they aren't intended to be visible! E.g., why "shadow password files" were created (which allow only account *names* to be exposed). Why tools that need to expose portions of those files ONLY expose those portions (e.g., an FTP service).

If you can *see* the hashes (which typically means you see MANY accounts), then you can look for a "familiar" hash -- one that matches a precomputed hash from a list of hashes of passwords that are *likely* to be encountered.

The article you cited is just a restatement of the same old lament: people choose bad passwords -- regardless of how cryptic (or long) you think it is!

The OP's article effectively says "use a random number generator to create your passwords/passphrases". A dictionary attack against *that* is not currently practical (upwards of 90 bits) -- if you assume all possible passwords are equally "likely"!

By contrast, *your* article states:

"So how did they do it? The short answer boils down to two variables: the website's unfortunate and irresponsible use of MD5 and the use of non-randomized passwords by the account holders."

MD5 has been known to have vulnerabilities for a long time. And, "the use of non-randomized passwords" is the crux of the matter. As I said in my reply, users favor lowercase (or uppercase) alphabetics in their passwords, with a few uppercase (or lowercase) alphas for variety; a few digits -- typically things like '4' (for) or '0' ('o') or '3' ('E'), and *maybe* a special symbol.

In a truly random password, you'd stand exactly the same chance as encountering an 'X' as you would an 'a' or a '%'. So, having precomputed the hash for "aaaaaaaaaaaaaaa" in your dictionary but *not* having "XXXXXXXXXXXXXXX" or "aX%Xa%aX%%%aaXX" won't help you.

[Note that the folks in your article couldn't crack *all* the passwords -- as some were obviously "chosen better" than others!]

That's the whole point of the "randomness" inherent in the OP's article! If you rely on "mnemonic aids" in your selection of passwords, you've already caused your choice of password to be much more "predictable" than if you had rolled dice (or flipped a coin) to create the password *for* you.

Play with OPHcrack. Notice how the table sizes increase dramatically as the range of valid characters supported (and, thus, the variety of potential passwords) is increased: Yet, these tables *don't* exploit "mnemonic patterns" in your choice of passwords. They can just as easily discover "W8tiFlSv39Hetj" as they could "MyLongPassword". (you might want to try each of those 14 character passwords for proof; the article you've cited will *probably* find the latter, but not the former -- because the latter is far more "memorable"!)

[Notice, also, how the sizes of the tables changes when you move away from (weak) LM hashes to NT hashes -- for the same level of "performance"]

There are a variety of simple ciphers and individual variants that one can apply to a memorable passphrase, so that if one forgets the gibberish version, one can generate it again easily. A file with brief hints of that sort, intelligible only to the user, gets you over the kind of "let's try this" manually guided attack explained in the article without making you extra vulnerable if the file is compromised.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC 
Optics, Electro-optics, Photonics, Analog Electronics 

160 North State Road #203 
Briarcliff Manor NY 10510 

hobbs at electrooptical dot net 
http://electrooptical.net

yes but there is no point in using this method:

- the maximum length of the password for the majority of website is 16 char or so, so the passphrase is too long to be used in real life.

- it will be still difficult to remember such a passphrase, so you need to write it down somewhere, on a post-it or in a password manager.

- it takes time to create a passphrase you need the word list and a dice , with a password manager you just have to push a button and it gives you the 16 char random password istantly (of course you can implement the worddice alghorithm inside the password manager, but why? with the same amount of character of a passphrase you get a stronger random password).

Bye Jack

--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

I have the passwords for most of my "web accessible" accounts written down (gasp!) in my wallet. Anyone finding my wallet would quickly realize what that slip of paper represents!

But, they wouldn't know the account "names" or even "vendors" associated with each password. Nor would they be able to use the passwords as "stated" in the list even if they *could* sort out the accounts!

Trivial encodings can appear to be black magic to decipher:

- swap each two characters and change the case of ONLY the first -- iff it is alphabetic

- replace every vowel with the "next" vowel (A->E, E->I, etc.)

- remove the i-th character from the i-th password in this list etc. yet really easy to invert on-the-fly.

The point is that the actual password/phrase needs to have no "bias" in its selection.

This is the flipside of the lottery number mentality: folks think "00000" is a *terrible* number! And, that "18429" is somehow "better" (more likely to be a winner). In reality, they are each equally probable and the "goodness/badness" of a number is actually related to how

*few* people are likely to choose it (so you don't have to share the jackpot with as many other winners!).

I use a variant of that approach. My words are not in any dictionary.

It can be a bit embarrassing when you forget an infrequently used password and cannot reconstruct it accurately inside three guesses.

Using MD5 hashes for storing passwords is asking for trouble since the MD5 hash function is too quick to offer decent protection. An attacker can brute force it too easily on modern parallel hardware. And they only have to find something with the same MD5 digest not necessarily the exact same password as the original (which provides another line of number theoretic cryptographic attack).

--
Regards, 
Martin Brown

Depends on the lottery. The Irish lottery famously got the number of smaller prizes wrong and as a result were gamed by a syndicate that used software to buy up every available permutation.

Even though the various balls are all equally likely to come out there is a difference in the number of ways you can expect to share the prize.

All the sucker bets will include the date of someone's birthday or wedding anniversary so you are way more likely to have to share a prize if you include mostly numbers below 32.

--
Regards, 
Martin Brown

Passphrases are used in other places -- where folks have realized that passWORDS are just too insecure (e.g., when I make an ssh connection, I don't type in a 16 character passWORD but, rather, a lengthy passPHRASE)

There's nothing wrong with that. Just don't write it in "cleartext"! Instead, "encode" it in a trivial manner known only to yourself. *And* safeguard it. So, if your list is compromised, the thief still has to try to sort out what it means (e.g., my list doesn't have account names/ids or even vendors/institutions written on it. What does "7df5GRh86jkd6" mean? How can *you* use it to harm me??)

Password managers are, IMO, a bad idea. First, they give a false sense of security. You trust them too easily.

Second, they obviously store *passwords* -- not grocery lists! :> So, a thief knows to look for when trying to hack you. Sort of like looking for a wall safe if you're a burglar (it probably never occurs to you that the jewels may be stored in the clothes dryer!).

Third, they are electronic in nature. They "run code" to provide their functionality. And, in probably 99.999999999% of the cases, there are

*other* applications running on the same device. Now, the security of that device comes into question (and, chances are, it is a commodity device -- a tablet, smartphone, etc. -- WELL DOCUMENTED and/or EXPLOITED)

A friend does IT for a large multinational financial institution. When he visits, he carries an electronic "key" that is little more than a pocket pager in size/complexity. Just a small display that presents a "random" password that changes frequently (it is time synchronized to the systems he administers).

So, an adversary would gain nothing by surreptitiously glancing at the "current password" -- it is likely to expire before he could make use of it! And, stealing the device still leaves him without knowledge of how to *access* the system in question: what's the internet address? what protocol? what user name? etc.

The whole point of the OP's article was that user's use *random* passwords. And, most users can find "fair dice" or "an unbiased coin" a lot easier than a pseudo-random number generator (how "random" *is* the password generator? does *it* have patterns that can be exploited?)

There are ~95 (96?) printable ASCII characters commonly accepted in passwords/passphrases. So, just over 6 bits per character. A "random"

16 character password would then have ~100 bits of entropy.

But, all of that entropy is *exposed* to the user trying to remember that password! Entropy == absence of pattern == absence of predictability (harder to remember).

PassPHRASES work around this by increasing the amount of text used to encode that entropy. E.g., a case-insensitive alphabetic has about 5 bits of information. If you glue many of them together (like 5 or 6) you potentially have 25-30 bits of information capability. If you then limit the choices of these 5-6 character combinations to "pronounceable words" (e.g., from a list of same!), you've decreased the information content to just 13 bits (in the example cited).

*But*, you've made the word more memorable. Now, you can commit to memory 7 or 8 *words* instead of 16 "random" characters. And, achieve the ~same level of security.

Or, as I said, pick an (equally likely) number that folks *avoid* (because it is a "terrible number"). Your chance of winning hasn't changed. But, the expected value of your winnings is higher (if you know how "unfavorably" others view your number!).

Esp if you waste one of those choices by failing to notice if CAPS LOCK is on, etc. :<

I think most "serious" systems use stronger hashes (e.g., SHA512). It seems foolish to "go cheap" with security -- but many firms treat it as an afterthought... just give it some token acknowledgement (and let the *users* bear the costs when it falls down). C'mon, it's not like you're running every transaction through it! Why not spend a few extra milliseconds per session??

[This is especially amusing for HTTPS connections! Burn all those cycles on the *traffic* yet pinch pennies for the authentication??]

MD5 is really only useful, nowadays, as a cheap "file integrity" check (and then, only when you trust the environment in which you're operating).