7 ms·

Mildly off topic but: I've never been a fan of password hints, but I'll admit it had never occurred to me that they could be used this way. This is yet another

Mildly off topic but: I've never been a fan of password hints, but I'll admit it had never occurred to me that they could be used this way. This is yet another reason to use an algorithm like bcrypt that will generate different hashes for the same password. I'm also amazed people put such obvious password hints, and some even had their exact password as the hint.

corin_ 13y ago
A basic salted hash would prevent this sort of thing (not saying that bcrypt/etc. aren't worth using). As to people using obvious password hints, it depends how much you care about the account - I don't use hints anywhere, but there's plenty of accounts I have where I really wouldn't care if anyone logged into it, so if I was someone who needed hints, then sure why not?
- 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.
  - 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.
- kevjiang 13y ago
  Amazingly, these aren't even password hashes.. they're encrypted versions of the password. Ars wrote an article on this yesterday [1]. Basically if anyone has the encryption key, they'd be able to decrypt ALL passwords in the list. [1] http://arstechnica.com/security/2013/11/how-an-epic-blunder-by-adobe-could-strengthen-hand-of-password-crackers/ http://arstechnica.com/security/2013/11/how-an-epic-blunder-...
  - anonymous 13y ago
    Actually you maybe don't even need the key. I don't know what algorithm Adobe used to encrypt these passwords, but for most standard ones it holds that if you have two encrypted messages A' and B' corresponding to plain texts A and B, then B = A ^ A' ^ B'. You really only need to find one password of length N to be able to decrypt all passwords with length <= N. Edit: Of course I mean two messages encrypted with the same key and initialisation vector. Do not reuse IVs kids, you'll get hurt.
    - tcas 13y ago
      That's true of stream ciphers, and if they reuse a nonce. It looks like they used 3DES which is for all intents and purposes here, immune to a this kind of attack. EDIT: If they use 3DES in a CTR mode then it could be vulnerable to this, but looking at the base64ed texts in the blog posts, they are multiples of 8 meaning it is almost certainly in a block cipher mode. Would be interesting to see if you can find any block similarities if they used ECB.
      - mischanix 13y ago
        This is really neat. Adobe stated the hashes are 3DES/ECB. So, say I have a two block password with '6aMjgZFLzYg' as the second block... when I just search for that block I see alot of hints that point to '123456789' as a password, implying the plaintext for that block is simply '9'. So now I believe the password is 9 characters long and ends with '9'.
- rmrfrmrf 13y ago
  lol; "should have used a salt" is one of the most hilarious HN memes.
  - corin_ 13y ago
    My point wasn't that using a salt is good practice, just that Adobe's method was so bad that even a salt+hash would have been better.
scottmcleod 13y ago
Same - I like how he solved this 'problem'
sitkack 13y ago
This is also why shouldn't answer "secret questions" about yourself. These can be aggregated and gleaned from other sites. Exactly how Palin's mail was "hacked", dog's name off of a wikipedia page.
- KMag 13y ago
  That's why I use dd if=/dev/random bs=1 count=16 | base64 to rename my dog every 182 days. He gets a bit confused at first, but adjusts quickly enough.
saurik 13y ago
> I'm also amazed people put such obvious password hints, and some even had their exact password as the hint. This password protects something I doubt many people consider something that needs to be very secure. Why, therefore, should they use a complex password, or even feel the need to have a password at all? The risks associated with someone "hacking" your Adobe.com account are going to mostly seem like problems for Adobe, not problems for the user (and even the problems for Adobe are fairly dubious). Meanwhile, it is something you are pretty much never going to log in to. It's like having a filing cabinet at your office that contains nothing but blank paper for the copy machine requiring a ten digit passcode. As the employee assigned a passcode for this cabinet, you are not going to consider the paper very valuable and you are hardly ever going to need to get into the cabinet to get that paper... why would you /not/ end up scrawling your passcode onto a post-it note somewhere (potentially even hiding it near the cabinet). To get people to care about security you need to get them to care about the information being secured. In this case, I can't imagine most people would understand that anything in this account is valuable. Even to a more-trained-than-normal eye, it isn't 100% clear to me: you can read my tech support history (which might tell you more about myself or my work) and you can get my saved billing address (it does not save actual account information). My address (not everyone's, just mine) is already public record. Really, the biggest concern is just that someone is going to change the e-mail address on my account and lock me out of it, preventing me from downloading licenses. I doubt your average normal user is going to even realize that changing the e-mail address on their account is possible, however (given the ways in which developers tend to use e-mail addresses and usernames interchangeably, I don't even blame them: this is a confusing concept and not every site provides the same functionality anyway).
- plywoodtrees 13y ago
  Adobe do cloud photo storage, I believe keyed off the same account. That could be highly sensitive data. People may have created their account and password for low value stuff and then started storing photos. Your general point is of course correct.
- PeterisP 13y ago
  Your filing cabinet example is spot on. If the cabinet for storing blank paper that I don't care about (and it's my cabinet, not something entrusted to me for safeguarding) requires a passcode, then I'd both set the passcode to '0000000' or '123456', and write it on a post-it note right there. Similarly, if some website or forum that I don't care about (and don't fear if someone or everyone accesses my account) starts for me to require an account+password that I don't want - then I'd both set the password to something trivial ('password' ?) and ensure that my browser stores it so I don't have to. In an ideal world, I wouldn't have that account/password at all - most of accounts listed in my browser password-list are accounts where some site forces me to keep a password that I don't want to 'keep an account', do 'personalization', etc. For example, I have a (free) account on Spotify. Is there any good reason why I should have a secure password there? Is there any good reason why I shouldn't tweet that password to everyone, other that Spotify itself might dislike it?
C1D 13y ago
They could've prevented this with using a salt, but instead of using a salt they make it even worse by not hashing but using encryption. Basically if some one got the key they could get the passwords to everything including the FBI Agents and then they could possibly hack their emails.
bobbyi_settv 13y ago
In the screenshot, no one is using the exact password as their reminder, presumably because it isn't allowed. The reminders include 12345, 1234567, 123456789, 654321 and 1to6. The author concludes that the password is 123456.

corin_ 13y ago

A basic salted hash would prevent this sort of thing (not saying that bcrypt/etc. aren't worth using). As to people using obvious password hints, it depends how much you care about the account - I don't use hints anywhere, but there's plenty of accounts I have where I really wouldn't care if anyone logged into it, so if I was someone who needed hints, then sure why not?

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.
- 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.
kevjiang 13y ago
Amazingly, these aren't even password hashes.. they're encrypted versions of the password. Ars wrote an article on this yesterday [1]. Basically if anyone has the encryption key, they'd be able to decrypt ALL passwords in the list. [1] http://arstechnica.com/security/2013/11/how-an-epic-blunder-by-adobe-could-strengthen-hand-of-password-crackers/ http://arstechnica.com/security/2013/11/how-an-epic-blunder-...
- anonymous 13y ago
  Actually you maybe don't even need the key. I don't know what algorithm Adobe used to encrypt these passwords, but for most standard ones it holds that if you have two encrypted messages A' and B' corresponding to plain texts A and B, then B = A ^ A' ^ B'. You really only need to find one password of length N to be able to decrypt all passwords with length <= N. Edit: Of course I mean two messages encrypted with the same key and initialisation vector. Do not reuse IVs kids, you'll get hurt.
  - tcas 13y ago
    That's true of stream ciphers, and if they reuse a nonce. It looks like they used 3DES which is for all intents and purposes here, immune to a this kind of attack. EDIT: If they use 3DES in a CTR mode then it could be vulnerable to this, but looking at the base64ed texts in the blog posts, they are multiples of 8 meaning it is almost certainly in a block cipher mode. Would be interesting to see if you can find any block similarities if they used ECB.
    - mischanix 13y ago
      This is really neat. Adobe stated the hashes are 3DES/ECB. So, say I have a two block password with '6aMjgZFLzYg' as the second block... when I just search for that block I see alot of hints that point to '123456789' as a password, implying the plaintext for that block is simply '9'. So now I believe the password is 9 characters long and ends with '9'.
rmrfrmrf 13y ago
lol; "should have used a salt" is one of the most hilarious HN memes.
- corin_ 13y ago
  My point wasn't that using a salt is good practice, just that Adobe's method was so bad that even a salt+hash would have been better.

scottmcleod 13y ago

Same - I like how he solved this 'problem'

sitkack 13y ago

This is also why shouldn't answer "secret questions" about yourself. These can be aggregated and gleaned from other sites. Exactly how Palin's mail was "hacked", dog's name off of a wikipedia page.

KMag 13y ago
That's why I use dd if=/dev/random bs=1 count=16 | base64 to rename my dog every 182 days. He gets a bit confused at first, but adjusts quickly enough.

saurik 13y ago

> I'm also amazed people put such obvious password hints, and some even had their exact password as the hint. This password protects something I doubt many people consider something that needs to be very secure. Why, therefore, should they use a complex password, or even feel the need to have a password at all? The risks associated with someone "hacking" your Adobe.com account are going to mostly seem like problems for Adobe, not problems for the user (and even the problems for Adobe are fairly dubious). Meanwhile, it is something you are pretty much never going to log in to. It's like having a filing cabinet at your office that contains nothing but blank paper for the copy machine requiring a ten digit passcode. As the employee assigned a passcode for this cabinet, you are not going to consider the paper very valuable and you are hardly ever going to need to get into the cabinet to get that paper... why would you /not/ end up scrawling your passcode onto a post-it note somewhere (potentially even hiding it near the cabinet). To get people to care about security you need to get them to care about the information being secured. In this case, I can't imagine most people would understand that anything in this account is valuable. Even to a more-trained-than-normal eye, it isn't 100% clear to me: you can read my tech support history (which might tell you more about myself or my work) and you can get my saved billing address (it does not save actual account information). My address (not everyone's, just mine) is already public record. Really, the biggest concern is just that someone is going to change the e-mail address on my account and lock me out of it, preventing me from downloading licenses. I doubt your average normal user is going to even realize that changing the e-mail address on their account is possible, however (given the ways in which developers tend to use e-mail addresses and usernames interchangeably, I don't even blame them: this is a confusing concept and not every site provides the same functionality anyway).

plywoodtrees 13y ago
Adobe do cloud photo storage, I believe keyed off the same account. That could be highly sensitive data. People may have created their account and password for low value stuff and then started storing photos. Your general point is of course correct.
PeterisP 13y ago
Your filing cabinet example is spot on. If the cabinet for storing blank paper that I don't care about (and it's my cabinet, not something entrusted to me for safeguarding) requires a passcode, then I'd both set the passcode to '0000000' or '123456', and write it on a post-it note right there. Similarly, if some website or forum that I don't care about (and don't fear if someone or everyone accesses my account) starts for me to require an account+password that I don't want - then I'd both set the password to something trivial ('password' ?) and ensure that my browser stores it so I don't have to. In an ideal world, I wouldn't have that account/password at all - most of accounts listed in my browser password-list are accounts where some site forces me to keep a password that I don't want to 'keep an account', do 'personalization', etc. For example, I have a (free) account on Spotify. Is there any good reason why I should have a secure password there? Is there any good reason why I shouldn't tweet that password to everyone, other that Spotify itself might dislike it?

C1D 13y ago

They could've prevented this with using a salt, but instead of using a salt they make it even worse by not hashing but using encryption. Basically if some one got the key they could get the passwords to everything including the FBI Agents and then they could possibly hack their emails.

bobbyi_settv 13y ago

In the screenshot, no one is using the exact password as their reminder, presumably because it isn't allowed. The reminders include 12345, 1234567, 123456789, 654321 and 1to6. The author concludes that the password is 123456.