Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How crackers ransack passwords like “qeadzcwrsfxv1331”

arstechnica.com

Post reply on HN
Print view View original

31–40 of 123 posts

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#31

Post by chongli »

nknighthb wrote: post #23
chm wrote: post #21

Earlier quoted context omitted.

That's what I understood from the article, and why I suggested the salts and hashes should be handled separately. If you give the attacker the salts, difficulty scales linearly. For two identical plaintexts, all that differs is the salt, but it is given to him. If you store the hashes and salts separately (the technical details of which I know nothing about), then you augment the keyspace exponentially. For N byte sa…

The server must have access to both the salt and the hash to verify a password. Therefore, upon compromise of the server, the attacker automatically has access to both the salt and the hash. There is no way around this problem that isn't simply obfuscation.

Not necessarily. With something like a smartcard or TPM chip, one could move the hashes and salts off the server. Both would still be stored together (on the device) but they'd be separate from the server!

Edit: Or one could move just the salts into the device and store an index into them in the password file. Hashing would be carried out by the device but an attacker would only gain access to the indices. Without stealing the device itself it'd be impossible to properly salt the passwords for hashing.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#32

Post by A1kmm »

chongli wrote: post #31
nknighthb wrote: post #23

Earlier quoted context omitted.

The server must have access to both the salt and the hash to verify a password. Therefore, upon compromise of the server, the attacker automatically has access to both the salt and the hash. There is no way around this problem that isn't simply obfuscation.

Not necessarily. With something like a smartcard or TPM chip, one could move the hashes and salts off the server. Both would still be stored together (on the device) but they'd be separate from the server! Edit: Or one could move just the salts into the device and store an index into them in the password file. Hashing would be carried out by the device but an attacker would only gain access to the indices. Without st…

If you have a dedicated cryptography module, you would be better off storing encrypted hashes, and asking the cryptography module to decrypt the hash and verify the password against it. Salting the hash (and using an expensive hash) would still provide a second layer of defence in case the module is compromised (and provide a physical rate limit to online attacks even if the server is compromised).

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#34

Post by nknighthb »

chongli wrote: post #31
nknighthb wrote: post #23

Earlier quoted context omitted.

The server must have access to both the salt and the hash to verify a password. Therefore, upon compromise of the server, the attacker automatically has access to both the salt and the hash. There is no way around this problem that isn't simply obfuscation.

Not necessarily. With something like a smartcard or TPM chip, one could move the hashes and salts off the server. Both would still be stored together (on the device) but they'd be separate from the server! Edit: Or one could move just the salts into the device and store an index into them in the password file. Hashing would be carried out by the device but an attacker would only gain access to the indices. Without st…

If the contents of the device can be dumped, the problem remains. If not, you have no copies of your database, so when (not if) the device or the server it's connected to fails, your site is down, and once you've brought it back up, all of your users must go through a password reset process.

That one server/device is now a single point of failure and a bottleneck in processing logins.

You're also still relying on the security of a computer, just a special-purpose one.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#35

Post by chongli »

nknighthb wrote: post #34
chongli wrote: post #31

Earlier quoted context omitted.

Not necessarily. With something like a smartcard or TPM chip, one could move the hashes and salts off the server. Both would still be stored together (on the device) but they'd be separate from the server! Edit: Or one could move just the salts into the device and store an index into them in the password file. Hashing would be carried out by the device but an attacker would only gain access to the indices. Without st…

If the contents of the device can be dumped, the problem remains. If not, you have no copies of your database, so when (not if) the device or the server it's connected to fails, your site is down, and once you've brought it back up, all of your users must go through a password reset process. That one server/device is now a single point of failure and a bottleneck in processing logins. You're also still relying on the…

I didn't say anything about reliability or single points of failure. I merely pointed out that it was possible to separate the salt from the hashes and gain security that way. Whether this is practical or not depends on how important security is to you.

And yes, it would not be possible to dump the contents of the devices.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#36

Post by lisper »

jacques_chester wrote: post #25
talloaktrees wrote: post #24

I don't know too much about crypto. Would using something like salsa20 stop this?

A password-derivation function has two requirements: 1. Obscure the password in a one-way fashion. 2. Be fast enough for humans, but very slow in computer time. Hash functions can be used to produce an obscured copy of data, but they are also by design very fast. If you wish to protect passwords, don't use a naked hash algorithm. Choosing a different hash algorithm doesn't fix the problem. Instead, use a password-der…

And of these three, scrypt is by far the best choice because it's the hardest one to speed up with specialized hardware.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#37

Post by MichaelAza »

eksith wrote: post #11
grecy wrote: post #5

Earlier quoted context omitted.

> the MD5 case they present is a poor case If guys using vanilla hardware get that kind of success in 1 hour with MD5, you only need to increase hardware and the time required to see it's still completely doable for other hash functions.

The issue is practicality. Which is why pbkdf2 (and increasing the rounds each year) + bcrypt or scrypt is still a better option.

Noob question, but why would you use both pbkdf2 and bcrypt/scrypt? Aren't they all basically doing the same thing?

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#38

Post by jacques_chester »

lisper wrote: post #36
jacques_chester wrote: post #25

Earlier quoted context omitted.

A password-derivation function has two requirements: 1. Obscure the password in a one-way fashion. 2. Be fast enough for humans, but very slow in computer time. Hash functions can be used to produce an obscured copy of data, but they are also by design very fast. If you wish to protect passwords, don't use a naked hash algorithm. Choosing a different hash algorithm doesn't fix the problem. Instead, use a password-der…

And of these three, scrypt is by far the best choice because it's the hardest one to speed up with specialized hardware.

Right. Colin Percival did a clever thing and made it memory-hard, not just computationally hard.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#39

Post by wnight »

chm wrote: post #21
tomku wrote: post #19

Earlier quoted context omitted.

Absolutely not. Like I said, the point of the salt is not to provide a "second password" that needs to be independently stolen. It's to make the results from a cracking attempt on one account useless on the password of another. If you've read the article, you have a pretty good idea of how it works without salting. You have a list of N password hashes, and you come up with candidate passwords. You run each candidate…

That's what I understood from the article, and why I suggested the salts and hashes should be handled separately. If you give the attacker the salts, difficulty scales linearly. For two identical plaintexts, all that differs is the salt, but it is given to him. If you store the hashes and salts separately (the technical details of which I know nothing about), then you augment the keyspace exponentially. For N byte sa…

You can't make the difficulty scale more than linearly by number of passwords. If you could you'd drop back to tackling the problem in pieces and be back to linear scaling with the number of pieces.

What's making it hard for you to analyze this is that you're using the wrong terms. The secret stuff is password - the non-secret stuff is salt. If you want two secret bits, you want two passwords, or to break the password into two pieces for separate storage.

But after all that, you still want a salt, because you're not using it for secrecy but for ambiguation of identical plaintexts.

But splitting the password hash is a bad, or at best neutral, idea because passwords are likely to be semi-human readable and thus a guessable password that matches hash1 is likely the actual password, and will match hash2. This wouldn't be true if we used random passwords, but we don't. So splitting the hash is mostly totally ineffectual, as is having two separate hashes of the same string - the attacker usually doesn't need to examine both.

Post reply on HN