6 ms·

A basic salt could be just a fixed string being used. That would not prevent this. The salt would need to vary per hash.

by aw3c2 13y ago

eCa 13y ago
The obvious solution is to salt it with something that is unique to that account: The internal account id, a string randomized at account creation or something like that. An identical password for two different accounts should never encrypt to the same string.
- hag 13y ago
  The salt should always be random. If it's based on some account information it's possible that the salt can be regenerated if that account information would become available, in a DB dump like this for example.
  - eCa 13y ago
    If they had used different salts for every account, and that salt was published in this dump it would have been much more difficult to find identical passwords compared to the current situation. I'm not sure how you can keep the salt random and secret, and still use it when users log in?
    - sillysaurus2 13y ago
      Salts aren't secret. The point of salting a password is to prevent the password (like "alskdjfalsdf") from always hashing to the same result (like "j9p+HwtWWT86aMjgZFLzYg=="). That prevents rainbow table attacks (among others) and it doesn't require the salt be secret.
      - jsmeaton 13y ago
        Right. But the parent comment was replying to a comment suggesting that a user id (or other account information) shouldn't be used as it's not random. I can't see why a user id could not be used as a salt though.
        justincormack 13y ago
        "I can't see why a user id could not be used as a salt though" thats exactly how people break crypto implementations, it seems ok but you dont really know. Don't just invent your own way, use the standard one.
        cbr 13y ago
        If lots of sites all use user ids as a salt and all count up from 1 then a much weaker version of this attack applies: you can identify all the people who have both the same password and the same user id. If this were common, someone constructing a lookup table for password hashes could include ones salted with the first N user ids. A N-times bigger table isn't something you'd be excited about as a cracker, but might still be practical. If your user ids are randomly assigned this should be pretty much the same as generating a random salt. Still, the extra storage of a salt is going to be small compared to whatever else you're storing per-user, so better to do the safe thing and go with what's standard.
    - plywoodtrees 13y ago
      The salt is typically stored in the password db, alongside the salted hash. If Adobe has taken that approach, the intruders would have all the salts, but they would not be able to do this attack of seeing how many people use the same password. However, Snowden's silly password hint would still have given the game away. If that is in fact him.
  - raverbashing 13y ago
    Yes, it should be random but the salt is public information. Exactly because you need it to calculate the hash and compare it.
  - mcv 13y ago
    If it's random, you need to store it, and it becomes just as available on a leak. The salt still works though, because it makes all hashes different. You need to attack each password individually rather than tackling them all with a rainbow table or something. The approach from this article also stops working. What you use as a salt is fairly irrelevant as far as I can tell. If you want to get more security on top of that out of your salt, the only thing I can think is to add some security by obscurity on top: If it doesn't matter which field in the DB you use, just pick an unlikely one and keep secret which one it is. Might be id, email, favourite pet, or something else. Just don't forget to update the hash when the user changes that field.
judofyr 13y ago
This is a common misconception, but a "global salt" isn't actually a salt. Not sure what a "basic salt" is though. > A new salt is randomly generated for each password. In a typical setting, the salt and the password are concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) is stored with the salt in a database. http://en.wikipedia.org/wiki/Salt_%28cryptography%29 http://en.wikipedia.org/wiki/Salt_%28cryptography%29
- aw3c2 13y ago
  Ah, I did not know that. And I wrote some password hashing with a global salt myself. So I stand by my comment with "one laughing and one crying eye". I thought salts were mostly against precomputed rainbow tables for specific hash functions, but of course if my hashes are valuable enough, a global salt makes cracking them easier than if I used a random/unique one per hash.
  - sillysaurus2 13y ago
    This is why programmers should stop trying to write their own password systems.
    - amenod 13y ago
      To be exact, programmers should stop using their own password systems (unless - well, let's not go there :). Writing them is actually an excellent exercise, and humbling one too. Especially if you show your code to some skilled hacker / security expert.
  - jtheory 13y ago
    From what I understand rainbow tables are not really used anymore -- they were useful when it took longer to calculate hashes, but nowadays you just need a decent graphics card to calculate a few billion hashes (MD5 or SHA1) PER SECOND. Per-hash salts don't really slow that down at all, unfortunately. Short-version: don't use the hash algorithms that are designed to be fast for protecting sensitive data; use something solid with a work factor instead.

A basic salt could be just a fixed string being used. That would not prevent this. The salt would need to vary per hash.

by aw3c2 13y ago

A basic salt could be just a fixed string being used. That would not prevent this. The salt would need to vary per hash.

eCa 13y ago

The obvious solution is to salt it with something that is unique to that account: The internal account id, a string randomized at account creation or something like that. An identical password for two different accounts should never encrypt to the same string.

hag 13y ago
The salt should always be random. If it's based on some account information it's possible that the salt can be regenerated if that account information would become available, in a DB dump like this for example.
- eCa 13y ago
  If they had used different salts for every account, and that salt was published in this dump it would have been much more difficult to find identical passwords compared to the current situation. I'm not sure how you can keep the salt random and secret, and still use it when users log in?
  - sillysaurus2 13y ago
    Salts aren't secret. The point of salting a password is to prevent the password (like "alskdjfalsdf") from always hashing to the same result (like "j9p+HwtWWT86aMjgZFLzYg=="). That prevents rainbow table attacks (among others) and it doesn't require the salt be secret.
    - jsmeaton 13y ago
      Right. But the parent comment was replying to a comment suggesting that a user id (or other account information) shouldn't be used as it's not random. I can't see why a user id could not be used as a salt though.
      - justincormack 13y ago
        "I can't see why a user id could not be used as a salt though" thats exactly how people break crypto implementations, it seems ok but you dont really know. Don't just invent your own way, use the standard one.
      - cbr 13y ago
        If lots of sites all use user ids as a salt and all count up from 1 then a much weaker version of this attack applies: you can identify all the people who have both the same password and the same user id. If this were common, someone constructing a lookup table for password hashes could include ones salted with the first N user ids. A N-times bigger table isn't something you'd be excited about as a cracker, but might still be practical. If your user ids are randomly assigned this should be pretty much the same as generating a random salt. Still, the extra storage of a salt is going to be small compared to whatever else you're storing per-user, so better to do the safe thing and go with what's standard.
  - plywoodtrees 13y ago
    The salt is typically stored in the password db, alongside the salted hash. If Adobe has taken that approach, the intruders would have all the salts, but they would not be able to do this attack of seeing how many people use the same password. However, Snowden's silly password hint would still have given the game away. If that is in fact him.
- raverbashing 13y ago
  Yes, it should be random but the salt is public information. Exactly because you need it to calculate the hash and compare it.
- mcv 13y ago
  If it's random, you need to store it, and it becomes just as available on a leak. The salt still works though, because it makes all hashes different. You need to attack each password individually rather than tackling them all with a rainbow table or something. The approach from this article also stops working. What you use as a salt is fairly irrelevant as far as I can tell. If you want to get more security on top of that out of your salt, the only thing I can think is to add some security by obscurity on top: If it doesn't matter which field in the DB you use, just pick an unlikely one and keep secret which one it is. Might be id, email, favourite pet, or something else. Just don't forget to update the hash when the user changes that field.

judofyr 13y ago

This is a common misconception, but a "global salt" isn't actually a salt. Not sure what a "basic salt" is though. > A new salt is randomly generated for each password. In a typical setting, the salt and the password are concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) is stored with the salt in a database. http://en.wikipedia.org/wiki/Salt_%28cryptography%29 http://en.wikipedia.org/wiki/Salt_%28cryptography%29

aw3c2 13y ago
Ah, I did not know that. And I wrote some password hashing with a global salt myself. So I stand by my comment with "one laughing and one crying eye". I thought salts were mostly against precomputed rainbow tables for specific hash functions, but of course if my hashes are valuable enough, a global salt makes cracking them easier than if I used a random/unique one per hash.
- sillysaurus2 13y ago
  This is why programmers should stop trying to write their own password systems.
  - amenod 13y ago
    To be exact, programmers should stop using their own password systems (unless - well, let's not go there :). Writing them is actually an excellent exercise, and humbling one too. Especially if you show your code to some skilled hacker / security expert.
- jtheory 13y ago
  From what I understand rainbow tables are not really used anymore -- they were useful when it took longer to calculate hashes, but nowadays you just need a decent graphics card to calculate a few billion hashes (MD5 or SHA1) PER SECOND. Per-hash salts don't really slow that down at all, unfortunately. Short-version: don't use the hash algorithms that are designed to be fast for protecting sensitive data; use something solid with a work factor instead.