6 ms·

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

70 points by TwoFactor 13y ago

nfg 13y ago
The link goes to page 3, here's page 1: http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking/ http://arstechnica.com/security/2013/10/how-the-bible-and-yo...
- ColinWright 13y ago
  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.
- TwoFactor 13y ago
  Thanks, I forgot to go back to the first page after I read the article.
- kiallmacinnes 13y ago
  <rant>Have to admit, this is really really really annoying</rant> Still .. interesting article!
DerpDerpDerp 13y ago
I don't know that this is exactly new.
gamegoblin 13y ago
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 13y ago
  You cant be bothered the four extra lines it would take to properly salt and hash these before storage?
  - gamegoblin 13y ago
    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.
swalkergibson 13y ago
This type of dictionary attack is largely mitigated by salting your hashes, is it not?
- richardwhiuk 13y ago
  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 13y ago
    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).
    - agwa 13y ago
      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."
    - kcorbitt 13y ago
      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.
galapago 13y ago
"Why passwords have never been weaker—and crackers have never been stronger," seems to be tautology..
- gyom 13y ago
  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 13y ago
    In fact, in this case, the password that they are cracking are already hashed. They don't get better at all.
notaddicted 13y ago
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=1DlRnW1jLqZrRqVMlII39sJgWM5qH0hki_KcehSY#rows:id=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=0Ar03cGpoaUJ3dHpZQU1aUS1YSnA4Q2dMQUZIRDc0anc&gid=0 https://docs.google.com/spreadsheet/pub?key=0Ar03cGpoaUJ3dHp...
bradleyjg 13y ago
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 13y ago
  > 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.
  - bradleyjg 13y ago
    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.
Sagat 13y ago
Does that mean that using a diceware password doesn't work?
- bradleyjg 13y ago
  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 13y ago
Is that an actual screenshot? Like, the guy collecting passwords ran a simple script as root, worked as root? How believable is that?
dwaltrip 13y ago
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.

70 points by TwoFactor 13y ago

nfg 13y ago

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

ColinWright 13y ago
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.
TwoFactor 13y ago
Thanks, I forgot to go back to the first page after I read the article.
kiallmacinnes 13y ago
<rant>Have to admit, this is really really really annoying</rant> Still .. interesting article!

DerpDerpDerp 13y ago

I don't know that this is exactly new.

gamegoblin 13y ago

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 13y ago
You cant be bothered the four extra lines it would take to properly salt and hash these before storage?
- gamegoblin 13y ago
  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.

swalkergibson 13y ago

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

richardwhiuk 13y ago
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 13y ago
  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).
  - agwa 13y ago
    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."
  - kcorbitt 13y ago
    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.

galapago 13y ago

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

gyom 13y ago
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 13y ago
  In fact, in this case, the password that they are cracking are already hashed. They don't get better at all.

notaddicted 13y ago

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=1DlRnW1jLqZrRqVMlII39sJgWM5qH0hki_KcehSY#rows:id=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=0Ar03cGpoaUJ3dHpZQU1aUS1YSnA4Q2dMQUZIRDc0anc&gid=0 https://docs.google.com/spreadsheet/pub?key=0Ar03cGpoaUJ3dHp...

bradleyjg 13y ago

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 13y ago
> 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.
- bradleyjg 13y ago
  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.

Sagat 13y ago

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

bradleyjg 13y ago
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 13y ago

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

dwaltrip 13y ago

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.