4 ms·

They still need to change the password everywhere they used it even if eBay used a state-of-the-art password hashing. (Remember that eBay asked users to change

by dchest 12y ago

They still need to change the password everywhere they used it even if eBay used a state-of-the-art password hashing. (Remember that eBay asked users to change passwords?) But even so, the knowledge of password storage scheme in this case is actually harmful! Suppose Alice is reusing passwords, like you said. She learns that eBay used bcrypt, and due to this knowledge thinks her password is safe, and doesn't change her password anywhere apart from eBay. Good? Nope.

hackinthebochs 12y ago
>They still need to change the password everywhere they used it even if eBay used a state-of-the-art password hashing I don't see why you keep saying this. These sorts of one-size-fits-all responses to security is why the state of security to day is so bad. A salted hash in itself is useless if you can't decrypt it. If their hashing technique was properly implemented then a good password will be impossible to decrypt. In this scenario there is no reason to change your password. Personally, the value of an easy to remember password is higher than the miniscule risk of it being decrypted and used for nefarious purposes (which is limited by the fact that nothing of importance is linked to this particular password). I probably won't be changing my ebay password.
- dchest 12y ago
  No, good password is infeasible to brute-force (not "decrypt", hashing doesn't encrypt anything; I invite you to research the topic you're talking about) even if you use non-salted SHA-1. Slow password hashing is there to protect weak passwords. In the event compromise like this, you need to change password regardless, because you can't be certain if, for example, attackers had access to server memory (remember that password is kept there before hashing?) or not. These sorts of one-size-fits-all responses to security is why the state of security to day is so bad. This sentence is completely false.
  - hackinthebochs 12y ago
    >not "decrypt", hashing doesn't encrypt anything; I invite you to research the topic you're talking about You are familiar with a colloquialism, are you not? Imprecise language like this is common among experts in just about every field. You don't not get points for being a pedant when everyone understands what is meant by decrypt in this context. > because you can't be certain if, for example, attackers had access to server memory Which is why I asked about the details of the compromise. Getting full access to memory of a system is a few orders of magnitude more difficult than getting admin credentials to a DB. >This sentence is completely false. Nope. A decade ago the common security advice was "just MD5 it", and we're still suffering through this boneheaded advice today. Teach concepts, not catchphrases.
    - dchest 12y ago
      Imprecise language can be used, but not when two terms mean completely different things. "Just MD5 it" advice was not given by knowledgeable security experts. The practice of using a slow cryptographic function to derive password hashes goes back at least to the 1978 paper "Password Security: A Case History" by Robert Morris and Ken Thompson. (I have collected some implementations of historic password hashes (many of which are weak) here: https://github.com/dchest/historic-password-hashes https://github.com/dchest/historic-password-hashes)

by dchest 12y ago

hackinthebochs 12y ago

>They still need to change the password everywhere they used it even if eBay used a state-of-the-art password hashing I don't see why you keep saying this. These sorts of one-size-fits-all responses to security is why the state of security to day is so bad. A salted hash in itself is useless if you can't decrypt it. If their hashing technique was properly implemented then a good password will be impossible to decrypt. In this scenario there is no reason to change your password. Personally, the value of an easy to remember password is higher than the miniscule risk of it being decrypted and used for nefarious purposes (which is limited by the fact that nothing of importance is linked to this particular password). I probably won't be changing my ebay password.

dchest 12y ago
No, good password is infeasible to brute-force (not "decrypt", hashing doesn't encrypt anything; I invite you to research the topic you're talking about) even if you use non-salted SHA-1. Slow password hashing is there to protect weak passwords. In the event compromise like this, you need to change password regardless, because you can't be certain if, for example, attackers had access to server memory (remember that password is kept there before hashing?) or not. These sorts of one-size-fits-all responses to security is why the state of security to day is so bad. This sentence is completely false.
- hackinthebochs 12y ago
  >not "decrypt", hashing doesn't encrypt anything; I invite you to research the topic you're talking about You are familiar with a colloquialism, are you not? Imprecise language like this is common among experts in just about every field. You don't not get points for being a pedant when everyone understands what is meant by decrypt in this context. > because you can't be certain if, for example, attackers had access to server memory Which is why I asked about the details of the compromise. Getting full access to memory of a system is a few orders of magnitude more difficult than getting admin credentials to a DB. >This sentence is completely false. Nope. A decade ago the common security advice was "just MD5 it", and we're still suffering through this boneheaded advice today. Teach concepts, not catchphrases.
  - dchest 12y ago
    Imprecise language can be used, but not when two terms mean completely different things. "Just MD5 it" advice was not given by knowledgeable security experts. The practice of using a slow cryptographic function to derive password hashes goes back at least to the 1978 paper "Password Security: A Case History" by Robert Morris and Ken Thompson. (I have collected some implementations of historic password hashes (many of which are weak) here: https://github.com/dchest/historic-password-hashes https://github.com/dchest/historic-password-hashes)