How the Bible and YouTube are fueling the next frontier of password cracking | Hacker News Reader

How the Bible and YouTube are fueling the next frontier of password cracking

arstechnica.com

70 pointsTwoFactor32 comments

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.

> 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.

That's something that only the site programmer can do, and end users have no control or even insight into.

If the article is aimed at developers, I agree with what you are saying (see the last line of my post). But it reads to me like it's aimed more at users. If that's true they should emphasize the best thing that users can do to protect themselves -- which is not using the same password in more than one place.

Or they could have done both, instead of neither.

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)

The link goes to page 3, here's page 1: http://arstechnica.com/security/2013/10/how-the-bible-and-yo...

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.

Thanks, I forgot to go back to the first page after I read the article.

<rant>Have to admit, this is really really really annoying</rant>

Still .. interesting article!

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.

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.

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

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.

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...

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...

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

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".

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

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

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.

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

How believable is that?

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

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.

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).

Chances are extremely high that if an attacker gets the hashes, they also get the salts. Since knowing the salt is necessary to authenticate against the hashed password, any application that has access to the hash also has access to the salt, making the salt just as likely to be compromised as the hash. A hash with an unknown salt is just as useless to a legitimate application as it is to an attacker, so there's really no point in trying to store salts "separately."

If someone has penetrated your security enough to get the list of hashed user passwords it's assumed that they've got the salt as well. Salts aren't really considered "secret" and they don't make it harder for an attacker to crack a specific password, they just make it harder for the cracker to reuse his work against all the passwords in existence.

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.

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".

from wikipedia: "A public salt makes it more time-consuming to crack a list of passwords. However, it does not make dictionary attacks harder when cracking a single password. The attacker has access to both the encrypted password and the salt, so when running the dictionary attack, the attacker can simply use the known salt when attempting to crack the password."

one strategy that has occurred to me is to use a secret "master" salt, in addition to random public salts for each password. that way, an attacker would have to obtain the secret salt, as well as the public salts. the secret salt would be stored in the program that does the hashing, and not in the database. this requires an attacker to gain access to the filesystem where the program lives, as well as the database. of course, this offers no guarantees, but does make it harder for the attacker.

I think this occurs to nearly everyone. It's commonly referred to as a "pepper"[1], and is generally considered not all that helpful in most scenarios, as well as being potential evidence that you're a witch^W^WDoing Your Own Crypto, which is bad.

[1] See towards the end of the very comprehensive first answer. http://security.stackexchange.com/questions/211/how-to-secur...

Then go back, read the rest of it :)

thanks for the link. it was a good read. however, i see nothing in there that suggests that using a pepper is necessarily a bad thing.

i think the answer from rory mcclune puts it well: "Another add-on I've seen to this is to also add in what was called a pepper value. This was just another random string but was the same for all users and stored with the application code as opposed to in the database. the theory here is that in some circumstances the database may be compromised but the application code is not, and in those cases this could improve the security. It does, however, introduce problems if there are multiple applications using the same password database."

Since our own tptacek hasn't shown up, I'm going to link to (the only copy I can find of) one of his great blog posts on this subject:

http://www.securityfocus.com/blogs/262

To quote, emphasis his: Using raw hash functions to authenticate passwords is as naive as using unsalted hash functions. Don’t.

I don't know that this is exactly new.

Reply on news.ycombinator.com