

How the Bible and YouTube are fueling the next frontier of password cracking - TwoFactor
http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking/3/

======
bradleyjg
Ars has now done about a dozen of these articles. Unfortunately I think they
are somewhat misleading, in that they don't emphasize what exactly the threat
is that these password crackers represent.

This is an offline attack that allows the attacker to recover the plaintext
from hashes. In the context of the internet, the impact of this type of attack
on the end-user can be almost entirely mitigated by using unique passwords on
each site. A site which has leaked its password hashes is almost certainly
already fully compromised, so having the password to that particular site gets
the attacker not much. It's only when those passwords are reused that
recovering the plaintext becomes a big additional win for the attacker.

The implications of these articles is that you should use some super
complicated random password. Indeed that's a good idea. I personally use
lastpass to generate long random passwords. But if there's a choice between
using one really good password all over the internet versus unique, but
mediocre passwords on each site, the latter is a better choice. After all any
particular site could be a honeypot or store your password in the clear.

On the flip side, if these articles are aimed at developers rather than end
users, then they should be emphasizing using a modern key derivation function
with an appropriate work factor.

~~~
brey
> the impact of this type of attack on the end-user can be almost entirely
> mitigated by using unique passwords on each site

which unfortunately isn't going to happen.

the bigger point missed by the article is that this reliance on 'correct'
usage isn't even necessary if the hashes were created in the right way -
properly salted (per-user, not just a static string for the site) and using a
tunable computationally intensive hash algorithm like bcrypt or scrypt.

~~~
hrktb
To throw that in, there's a whole category of site that use a plain text
password that can be checked by phone/re-sent back to you/printed on some
statement. While from a best practice point of view it's sub standard, the use
case can be legit (in the best case your password only helps to discloses
minor-ish info, and the service value is purely IRL), and you might not know
in advance that they don't intend to keep your password any much safer.

You have to accept that there will be plenty of online service that won't try
to keep high online security and you'll have to use not too complicated,
throwable passwords for every site that don't have enough stakes in protecting
your auth data (I'd say basicly anything that's not monney and mail related)

------
nfg
The link goes to page 3, here's page 1:
[http://arstechnica.com/security/2013/10/how-the-bible-and-
yo...](http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-
fueling-the-next-frontier-of-password-cracking/)

~~~
ColinWright
There's a non-zero chance that happened to avoid the duplicate detector. There
was no discussion on that submission, so no point in sending you to it.

------
dwaltrip
I'm curious what you guys think of my current strategy. I use
passwordchart.com. It requires a generator phrase to create a "password
chart", which is simply a mapping from each alphanumeric character to a
different 1-3 character alphanumeric string. You then type in an easy to
remember password, and it maps that to a far more secure password using the
generated chart. I use the same chart (with a backup printed in my wallet),
and apply the same methodology for every service I use to create my easy-to-
remember password. I read the "how it works" page and it seems pretty secure
to me. For all my password needs I only have to remember two things: the
generator phrase and the method for making the easy to remember password.
There is also little counter party risk (passwordchart.com doesn't know where
the passwords are used, it would be hard to change the chart without me
noticing, and I have a backup). I love not having to think hard when signing
up for something new. In 5 seconds, I have an easy to fetch, secure, unique
password for any service.

------
gamegoblin
I set up an automatic grader for a class I TA so students could submit code
and have results immediately (it just pipes input into stdin and checks stdout
against a set answer). They had to set up little accounts on my grading
website. I told them not to use an important passwords or anything since I am
not doing any sort of security. Upon examining the plaintext passwords, there
is a decent number (maybe 5 out of 73 students) who used things like
"Proverbs22" (number made up) as passwords.

Seems like a good strategy to brute force passwords.

~~~
Phlarp
You cant be bothered the four extra lines it would take to properly salt and
hash these before storage?

~~~
gamegoblin
I knew that students would be forgetting their passwords (already more than 10
have come to me asking me what their passwords were) so rather than making a
password retrieval/changing system, I made the executive decision that it
didn't particularly matter on a system I made the morning before a class that
has no impact on grades or anything else. The system is purely for the
students' convenience at testing code. The only reason there are
usernames/passwords to begin with is so students can view all of their past
submissions to the system.

------
notaddicted
I haven't been following cracking development, is anyone aware of a back of
the envelope analysis of how much using a preconceived mnemonic reduces
entropy versus random letters? I would expect the math has been done, I think
all you need are the 1gram counts for the first letter position[1].

[1]
[https://www.google.com/fusiontables/DataSource?docid=1DlRnW1...](https://www.google.com/fusiontables/DataSource?docid=1DlRnW1jLqZrRqVMlII39sJgWM5qH0hki_KcehSY#rows:id=1)

EDIT: Based on a quick spreadsheet calculation, I think uniform A-Z each
letter is 4.7 bits, and a phrase constructed of random english words each
letter is 4.1 bits, so maybe not all that bad.
[https://docs.google.com/spreadsheet/pub?key=0Ar03cGpoaUJ3dHp...](https://docs.google.com/spreadsheet/pub?key=0Ar03cGpoaUJ3dHpZQU1aUS1YSnA4Q2dMQUZIRDc0anc&gid=0)

------
galapago
"Why passwords have never been weaker—and crackers have never been stronger,"
seems to be tautology..

~~~
gyom
So, in that sense, the accurate claim should be something like "passwords are
getting a little bit better, but crackers are improving by waaaaaay more, and
that shifts the balance".

~~~
galapago
In fact, in this case, the password that they are cracking are already hashed.
They don't get better at all.

------
Sagat
Does that mean that using a diceware password doesn't work?

~~~
bradleyjg
No. These attacks rely on popular phrases, not random combinations of words.

A diceware password of six words from a 7776 (6^5) word dictionary is 1 of 2.2
x 10^23 random possibilities. If your attacker can try 180 billion hashes a
second, then it would take almost 39 centuries to exhaust the password space.

------
darklajid
Is that an actual screenshot? Like, the guy collecting passwords ran a simple
script as root, worked as root?

How believable is that?

------
swalkergibson
This type of dictionary attack is largely mitigated by salting your hashes, is
it not?

~~~
richardwhiuk
Salting defeats rainbow tables, not word lists. This sort of attack is largely
defeated by basic password complexity and using plenty of rounds of hashing in
order to increase the work effort to hash a given size of word list.

~~~
mistermumble
But aren't the password and the salt hashed together?

So a password with different salts will result in a different hashes.
Therefore you have to know the salt in order to guess the password (for
offline matching against a dataset of hashed passwords retrieved from a target
site). Ideally, every password will have a different salt, and the dataset of
salts is stored separately from the dataset of hashes.

Or am I missing something? (Genuine question, because this is not my area of
expertise).

~~~
stonemetal
Salts are usually not stored separately. The password checker needs to access
both the password hash and the password salt. This means that there is one set
of privileges(whatever the password checker has) necessary to get both the
hash DB and the salt DB. Therefore any attacker that has the password hash DB
also has the Salt DB.

 _Ideally, every password will have a different salt,_

More than ideally, the only way it makes any sense at all is if they are
different.

As an example:

User: bob password: password1 password hash: 12345

User: sue password: password1 password hash: 12345

with salt that is the same for all users:

User: bob password: password1 salt: 7 password hash: 22345

User: sue password: password1 salt: 7 password hash: 22345

with salt that is different per user

User: bob password: password1 salt: 7 password hash: 22345

User: sue password: password1 salt: 8 password hash: 32345

Per user salt means that an attacker who has stolen the password db can't
crack one password and unlock 100 accounts because they all have the same
password hash. That is the only point of a salt it serves no other purpose.

~~~
Steuard
_Per user salt means that an attacker who has stolen the password db can 't
crack one password and unlock 100 accounts because they all have the same
password hash. That is the only point of a salt it serves no other purpose._

I wouldn't say _no_ other purpose. A single common salt can at least protect
you from the guy who has a pre-computed lookup table of dictionary words
hashed with a standard, unsalted function. (That is, it prevents a _zero_
-computation attack.) Admittedly that doesn't gain you much these days, but
it's not "zero benefit".

------
DerpDerpDerp
I don't know that this is exactly new.

