NVIDIA Forums & Dev Zone Breached; Up To 400K Password Hashes Taken

8 Comments

View All Comments

• DustinT - Saturday, July 14, 2012 - link

  Great reporting on a very serious issue. My understanding of md+salt hashed passwords is that's it's not possible to reverse the process and obtain the original password. It would be possible for a sufficiently motivated group to generate a list of potential passwords but mathematically impossible to generate the original password with confidence.
  
  Granted, this is a trouble matter and the affected users will need to take stung precautions to prevent further theft of their digital identities.

• Ryan Smith - Saturday, July 14, 2012 - link

  Due to the nature of hashing multiple inputs can hash to the same result, but in practice only one input is going to look like a password while all the other possibilities are gibberish. So while you can't be 100% sure you have the original password, given that most passwords fit some kind of pattern you can be better than 99% sure.
  
  In any case it's all about strong passwords. Anything that can be hit with a dictionary attack with small adjustments (letter replacement, number appendage, etc) would fall to a GPU pretty quickly. Especially since the attackers almost certainly have the salt (salts aren't meant to be secret).

• zanon - Saturday, July 14, 2012 - link

  Ryan, thanks for reporting. These sorts of events seem to be coming up more frequently these days, so it's worth repeating some techniques related to crypto to make sure they're as widely known as possible. A few techniques are things that individuals should be doing, but there is also stuff that really should be taking place server-side but that very, VERY few companies actually seem to do.
  
  On the server, as you note good passwords are certainly important. However, even without those there are still three important ways to help guard them in the case of a breach:
  1. Obviously the absolute utterly most basic is to actually hash in the first place. At this point (attempts at cryptographic hashing are OLD, even MD5 dates from 1992) storing in plaintext is practically criminal negligence, but regrettably there still seem to be places that haven't gotten the message.
  
  2. Salting you mentioned, and it's the second thing. Salting defends against use of rainbow tables, forcing all attacks to fall back to brute force. Memory and storage have increased are far faster rates then computation time, so preventing the use of cpu/memory tradeoffs is both easy and important. No excuse not to do this either.
  
  3. Finally, and the thing that practically nobody seems to do, is to use a proper adaptive hashing algorithm rather then a simple cryptographic one. Basic crypto hashes like SHA-2 are critical for signing, error detection and so forth, but for password storage they're the wrong tool for the job. An example of the right tool would be bcrypt. What algorithms like that (or techniques for keys like PBKDF2) enable is for someone to make the process of hashing arbitrarily slow, and thus tuned for users but against attackers (and to change it over time as systems get faster). Forcing hashing on a fast GPU to take, say, 200ms is something that will be effectively unnoticeable to a user (who will presumably get their password right the first time, or first few times anyway). However, that 200ms delay for each hash test means that, for a simple 10 character alphanumeric (case sensitive) password it would take a 1000 machine cluster working flat out around three and a half days to have a 75% probability of collision, assuming I didn't mess up the math :). That's for every single hash, so bruting hundreds of thousands would take decades. It's still necessary to have a mildly good password, but a proper brute-resistant hash does what it says on the tin and would be a major help. This is all old, well known stuff, and I wish more online services handled it properly.
  
  Of course best of all would be if proper multifactor support became widespread but that's probably still a distant dream sadly. In the mean time for users a password manager is a really, really good idea and makes it easy to use good, one use passwords for every site. Email aliases can be useful too, but those aren't as universally available or convenient right now, and at any rate aren't as important as unique passwords.

• tk11 - Saturday, July 14, 2012 - link

  "However in the age of GPU computing a hash is only as good as the password behind it, so in the case of bad/weak passwords the attackers can recover those passwords from the stolen hashes without too much effort."
  
  Not without first knowing the salt they can't.

• zanon - Saturday, July 14, 2012 - link

  Not without first knowing the salt they can't.

  
  They almost certainly would know the salt, because a salt is typically stored right with the hash. Salts are to defeat computation/memory tradeoff (Rainbow Table) attacks, not brute forcing. They're not meant to be secret.

• tk11 - Sunday, July 15, 2012 - link

  It's very possible that the salt may have also been compromised by the same method used to retrieve the hashes but salts most certainly are meant to be kept secret; at least to the same extent as the hashes themselves. In cases where a single salt is used to generate multiple hashes it's considered bad practice to store the salt in the same place as the hashes.
  
  In addition to the salt being possibly unknown the method used to generate the hashes may also be unknown. If only a simple MD5 was used then brute forcing short or simple passwords is as stated rather easy these days. If however a more complex algorithm, longer key length, multiple iterations, or a combination of the above were used to generate the hashes then even if the salt is known brute forcing once again becomes impractical despite the power of modern GPUs.
  
  Just because it has recently become trivial to brute force short passwords from hashes generated by a couple types of commonly used hashing methods doesn't also make trivial the knowledge of how the hashes were generated and the value of the salt. I guess my point is that the quoted statement is only true under a worst case scenario where a simple method was used to generate the hashes, that method is known to the attacker, the salt is known, and the hashed password is short or common.

• zanon - Sunday, July 15, 2012 - link

  It's very possible that the salt may have also been compromised by the same method used to retrieve the hashes but salts most certainly are meant to be kept secret; at least to the same extent as the hashes themselves.

  
  That of course is implied, but the whole point of them is for what happens when hashes aren't, in fact, kept secret. There isn't meant to be any special level of security for salts: if they have some way to increase protection against hacks or leaks, then they should be using that for the password hashes themselves too obviously. It's completely normal though to just store the salt right with the hash.
  

  In cases where a single salt is used to generate multiple hashes

  
  Design already failed. We're talking about what competent organizations should do in theory, not what incompetent ones may do.
  

  In addition to the salt being possibly unknown the method used to generate the hashes may also be unknown.

  
  It shouldn't matter. This is not a case where obscurity is of much value. As I said, to prevent rainbow attacks a salt is used, and to fight brute forcing use an adaptive hash with an appropriate number of rounds. No secrets are required there.
  

  Just because it has recently become trivial to brute force short passwords from hashes generated by a couple types of commonly used hashing methods doesn't also make trivial the knowledge of how the hashes were generated and the value of the salt.

  
  Compared to just doing it right it does. If someone gains access to a central account database then odds are very likely they're going to either have direct access, or be able to pretty easily figure out, any obfuscating business logic. You say it's assuming the worst case, but that's exactly what security is about. We plan by looking at the bad cases, not the best, at least in theory. The latter practice of course ("best case, we just will never be hacked, why not just store in plaintext!") is certainly what some companies seems to think is the right way :\.

• jwcalla - Monday, July 16, 2012 - link

  Another child having a temper tantrum because he's been separated from his blankie.
  
  Hackers are some of the worst filth out there.
  
  They're the kids on the playground that couldn't behave and force the teachers to cancel recess for everyone.
  
  "Look at me! Look at me! I'm so important!"
  
  Terrorists of a different cloth.
  
  Now I'm all spun up.