
A Really Good Article on How Easy it Is to Crack Passwords - wulfgarpro
http://www.schneier.com/blog/archives/2013/06/a_really_good_a.html
======
cperciva
Remember, security against cracking is a combination of _password strength_
and _key derivation function strength_. Nothing will save you if your password
is "password". Not much will save you if your password is hashed with MD5.

But scrypt can be over 100,000,000 time stronger than MD5 -- so if you're
using scrypt you can afford to use a password which is 100,000,000 times
weaker. "jdtwbv" hashed using scrypt is stronger than "H.*W8Jz&r3" hashed
using MD5.

~~~
raverbashing
""jdtwbv" hashed using scrypt is stronger than "H.*W8Jz&r3" hashed using MD5"

Is it? I'm not sure.

for the first one you're using lowercase letters (and digits, I'm giving you
that 'free')

For the first one we have 36^6 For the second one (all printables) 100^9

Relation between them: ~ 459,393,658. If you're saying scrypt is 100M times
better, in this case the second one is safer

And the relation is important but less as computers get faster. Option B may
take 1Mi times as long as Option A but if Option A takes 1 microsecond, there
goes your Option B as well

~~~
danielweber
People have built _huge_ rainbow tables of MD5 hashes.

I don't really keep up with that game (like WoW, it seems like a fun game, but
only if you are willing to put in a lot of your time), but I think the current
limit is somewhere around 8 or 9 characters if you are pulling from all
printables, meaning that "H.*W8Jz&r3" with MD5 is probably not breakable right
now.

Take off two characters, or wait 3 years, and it probably will be.

~~~
consultant23522
My understanding, and I'm sure that someone else will correct me, is that with
MD5 rainbow tables it's not so much that someone will get your password as
they will get something that hashes to the same value. More than likely this
will be your password, but sometimes not. The point is that it doesn't matter
if your password is 25 characters long.. if there's a 5 character password
that hashes to the same value they could log in with it.

~~~
danielweber
While it's possible to make MD5 collisions, finding something that hashes to
the same thing as a hash of my short password is essentially impossible.

In fact, collisions on short passwords are harder than collisions on long
passwords. The space of all MD5 outputs is way bigger than the space of
12-character passwords.

------
salmonellaeater
> "This is an answer to the batteryhorsestaple thing."

Steube misunderstands the xkcd comic [1]. There's a really good comment which
explains it: "It could be argued that Randall's example of 4 words is too
short -- and indeed, for some applications, it is. However for a typical
dictionary size, and genuinely random selection, it is massively stronger than
"typical" passwords and in fact easily adequte to defeat the above-mentioned
attacks." [2]

Emphasis on "genuinely random selection."

[1] [https://xkcd.com/936/](https://xkcd.com/936/)

[2]
[http://www.schneier.com/blog/archives/2013/06/a_really_good_...](http://www.schneier.com/blog/archives/2013/06/a_really_good_a.html#c1483848)

~~~
dasil003
What makes you think he misunderstands it? For the cracker it's not about
entropy per se, it's a game to come up with algorithms that crack more
passwords for less compute power. The XKCD comic got a lot of mindshare so it
makes sense to target algorithms towards that type of password.

I think Schneier's suggestion of reducing it to the first letter of each word
is vastly preferable because it packs the majority of entropy from random word
selection into the least amount of typing.

~~~
belorn
The algorithm is not targeted against the type of password which the XKCD
comic suggests. The algorithm is designed to exploit common human behavior,
which is similar to the XKCD method but not identical. The significant
difference is that human behavior in picking words is not random, while the
XKCD method requires the word selection process to be truly random. The
"iloveyousomuch" example by Steube is unlikely to be picked randomly.

salmonellaeater is right, Steube misunderstands the comic. The idea of the
comic is to pick a small random selection of the 250,000 distinct words in a
oxford dictionary, rather than 8 of the 95 letters from all ASCII printable
characters. A selection of 3 words has then higher entropy than 8 random
characters, because 250,000^3 is a bigger number than 95^8. The question then
is, will 3 random words really be easier to remember than 8 ASCII printable
characters?

The downside to the Schneier scheme, is that each is a common sentence (low
entropy), with a chosen transformation algorithm added. Thus the quality of
the password will depend on the number of transformation algorithms, and the
quality of each one. If we are to use the one first described to create
"tlpWENT2m", we get a password strength like:

Using strictly the first letter, would only do 2x linear increase in entropy
over just searching for common sentences. Change any occurrence of common
numbers substitutes for words adds (0-2x) entropy increase. Writing one of the
words in all caps means 6x increase in entropy. Combined, tlpWENT2m is
slightly less secure than "This little piggy went to market" \+ two [random
number below 10] or a single letter at the end.

~~~
dasil003
Where are you guys getting this? All I read was this:

> _Steube was able to crack "momof3g8kids" because he had "momof3g" in his 111
> million dict and "8kids" in a smaller dict._

> _" The combinator attack got it! It's cool," he said. Then referring to the
> oft-cited xkcd comic, he added: "This is an answer to the batteryhorsestaple
> thing."_

It sounds to me like he's combining words randomly, not "exploiting common
human behavior".

~~~
barrkel
He found a password by 2 words randomly from two dictionaries of different
sizes, so he only had m * n combinations to choose from, and his n is a lot
smaller than m.

Whereas the xkcd approach is more like m * m * m * m.

In other words, exponentiation > multiplication.

~~~
belorn
Correct. What I meant with "exploiting common human behavior", is that the
dictionaries the attacker used is built from list of old passwords found in
previous attacks. Those dictionary will be order of magnitude smaller than a
dictionary of the English language, but attackers know that people tend to
pick passwords (or in this case, compilation of passwords) that someone else
has already thought of before. Its a simple observed behavior that people in
general tend to think alike, and simply do not think randomly even if
individually, it "feels" random.

------
corin_
' _Also included in the list: "all of the lights" (yes, spaces are allowed on
many sites), "i hate hackers," "allineedislove," "ilovemySister31,"
"iloveyousomuch," "Philippians4:13," "Philippians4:6-7," and
"qeadzcwrsfxv1331." "gonefishing1125" was another password Steube saw appear
on his computer screen. Seconds after it was cracked, he noted, "You won't
ever find it using brute force."_'

If you won't ever find "gonefishing1125" using brute force, how on earth did
they find "qeadzcwrstxv1331"?

~~~
barrkel
Have you looked at the keyboard pattern for qeadzcwrsfxv1331?

I imagine there are a whole bunch of these geometric patterns, and different
combos of them are tried.

------
tilsammans
Passwords are broken and I really wish we would all move away from them.
Persona is a nice idea with regards to privacy and control, but it's still a
password that you need to remember, which can be cracked. Also, people
generally don't use strong passwords.

What irks me is that every OS in use today has support for strong cryptography
and browser vendors could easily integrate that. We would no longer register
for a website, we would simply upload our "Online Identity" or whatever we
called it. This of course is just an id_rsa.pub with maybe name and email in
the comment. The remote site stores the public key and the browser
authenticates using the private key, stored securely in the keychain.

This has the potential to be invisible to users, and thus used by default, and
highly secure since the local keychain can generate incredibly strong keys,
all behind the scenes.

~~~
hvidgaard
And how do you access your identity from a device that isn't your own?

I'm 100% with you, it would be a major step forward - but it's too inflexible
for Joe & Jane.

~~~
xerophtye
and also it kinda destroys the ubiquity of the service. you have to admit, the
ability to access your account from any device anywhere is pretty cool (and
very critical in some cases)

~~~
hvidgaard
It certainly is a difficult sell to the average user. For most Internet
Banking, it's already implemented, but try to get users to accept that when
using Facebook or access to their mail.

In Denmark we have a public system called "NemID". It is a 2-factor
authentication, which relies on a card with one-time codes, or eventually, a
physical key-generator. It is used to anything related to Internet Banking or
access to the public services on the internet, such as application for
university, change in tax return, and the like. Unless you can incorporate
such a system, which ensure that most uses already have the needed physical
token, I not convinced you can pull it off.

------
praptak
I like schemes that have an explicit input of n random bits (or where you can
at least have a good estimate on the entropy.) With the Schneier Scheme I can
not be sure of the actual entropy of my password. Maybe my brain only
generates a relatively small set of sentences which can be reverse-engineered
from my comments on HN? :-)

A good algorithm would take n bits and map them uniquely to a set of strings
that are easy to remember for a human. The apg utility does something like
that.

------
MarkMc
Why not force the user to have strong login credentials?

I'm creating an online system that will store users' sensitive financial data.
When setting up an account, the user will have to choose a password as normal,
but will also be given a passphrase of the form "correct horse battery staple"
that _they must write down_. To log in, the user will need to enter (a)
username; (b) password; and (c) passphrase.

It is effectively a poor man's two-factor authentication - the second factor
being the piece of paper containing the passphrase. I think it strikes a good
balance between security, convenience and cost.

What do others think of this approach?

~~~
mmahemoff
Another issue with this is it breaks password managers, including the built-in
browser password storage. While you might say that's a Good Thing for
security, it's not something you could easily pull off as a startup.

Due to lock-in effects, people have to deal with all manner of usability hell
from their bank, but the same logic doesn't apply to startups. Not that your
idea is usability hell, but you probably don't want to make it any harder than
it needs to be.

I think adding a few characters to the minimum password would be equally
secure and more consistent with tooling, as well as a more familiar model for
users.

Also, 2FA might be easier than you think using a service like Twilio. Or
another way to do it would be to let the user connect via a service that does
support 2FA (e.g. Google or Twitter;and maybe adding your own password if you
want to harden that).

~~~
StavrosK
I recently added 2FA (OATH/Google Authenticator) support to Persowna[1], and
it only took about two hours, 1:55 of which was spent on the UI. It's really
not very hard.

[1] [https://www.persowna.net/](https://www.persowna.net/)

------
Murk
People seem to forget this important fact - That hashes get leaked. Without a
hash corresponding to a user account it's quite hard to break in to a given
account with a moderately reasonable password, even if the hash can be
'broken' in milliseconds.

------
gopi
One benefit of being a indian language speaker (or other language not in
hackers dictionary) is we can easily choose reasonably secure passwords that
are remember-able by simply using native language phrases (combined with
numbers and mixed caps)

~~~
Semiapies
Assuming there aren't any Indians writing password-cracking software...

------
pbreit
The Ars article seemed totally irrelevant to me since it used MD5?

~~~
16s
Microsoft Active Directory servers (used in big business and government all
over the world) uses one round of MD4 (no salt). That's a 4, not a 5.

------
Kiro
I don't understand the difference between "momof3g8kids" and "tlpWENT2m". Why
would the latter be more secure?

~~~
dcuthbertson
Actually, it's hard for a 9-character password to beat a 12-character password
even though the latter has a larger alphabet/key-space (unless I've completely
blown the analysis below, which was done before coffee :).

The first has a key-space of 36^12 (36 possible characters in each of 12
positions), or about 4.7e18. The second has a key-space of 62^9 (62
upper/lower case letters and digits in each of 9 possible locations), or about
1.4e16.

If, in addition to adding the uppercase letters, you added the possibility of
needing to test symbols, such as ~`.,/:;!@#$%^&*-=_+ (another 19 symbols), and
changed the latter password to "tlpW#NT2m", then the searchable key-space for
all 9-character passwords becomes 81^9, or about 1.5e17.

RE-EDIT: Sorry. I should have read the article first. I'm not sure why the
latter would be more secure. Obviously "WENT" would be in a dictionary, so I'd
think that "tlpWENT2m" would fall to a combinator attack very quickly, too.

