11 ms·

From here forward, I will consider any disclosure involving stolen passwords that does not include a description of the password hashing/encryption/etc mechanis

From here forward, I will consider any disclosure involving stolen passwords that does not include a description of the password hashing/encryption/etc mechanism to mean "plaintext-equivalent passwords were taken". Edit: Changed "plaintext passwords were taken" to "plaintext-equivalent passwords were taken"

zavi 13y ago
If they describe how passwords were hashed, it would make it easier for hackers to crack them.
- jwcrux 13y ago
  Shouldn't matter. Something like "We hashed each password using PBKDF2 and a unique salt and a high number of iterations" doesn't help all that much. The attackers will still have a tough time brute forcing those.
- carbocation 13y ago
  > If they describe how passwords were hashed, it would make it easier for hackers to crack them. I don't really agree with you. If you store bcrypted stuff, you see $2a${integer exponent}$hash. If you store SHA1'ed stuff, you see characteristic hashes and can trivially test against known hashes. So on for MD5, etc. I don't need you to tell me "we store SHA1'ed stuff iterated 35 times with the following salt", but keeping that information secret wouldn't usually help you anyway. A determined attacker will test and iterate until they've figured out your scheme (or, if you're unlucky, they won't need to). Telling the attacker "we bcrypted everything" doesn't tell them anything they couldn't plainly see on their own.
- lucastx 13y ago
  That's not how a properly implemented hash -- and cryptography in general -- is supposed to work. This strategy is called "security by obscurity", and is seen as a very bad one. Instead, cryptography aims to provide means to encrypt data in a way that anyone knows //how// it was encrypted, and still doesn't have a clue how to decrypt it -- because they don't have the key, in case of encryption, and because the hash is a "one-way" function, in case of hashing.
  - hga 13y ago
    Disagree for systems. I take adding "security through obscurity" to the normal standard good methods as a defense in depth measure.
    - jleader 13y ago
      Adding "security through obscurity" is only a net win over "published security scheme" if your engineers are substantially better than any engineers who might comment on your published scheme. Even if you've hired world-class security engineers, there could still be some flaw they've overlooked, that an outside commentator might notice. Note that the security of a whole system is harder to get right than the security of any one component; keeping it obscure just makes it much less likely that a white hat will notice the flaw and notify you. A simple example of this is the freshman CS majors' perennial idea that combining multiple PRNGs will yield a "more random" algorithm (it typically makes the result easier to predict). There are plenty of cases of a secure algorithm being used to build a system that ends up insecure because of some obscure flaw that nobody noticed initially.
      - hga 13y ago
        "Adding "security through obscurity" is only a net win over "published security scheme" if your engineers are substantially better than any engineers who might comment on your published scheme." I think that overstates the case. Your engineers don't have to be better, just good enough know what's correct and safe, or do research until they know. My approach is to just add things that are clearly correct to published and studied systems that are thought to be correct. In this case, we're talking about applying multiple or multiple runs of one way hashing functions; I'd actually do some research before trying the latter, but it strikes me as safe, and the former is by definition safe, right? Whereas it would never even occur to me to combine PRNGs ... or not use a hardware source of entropy to begin with in the first place (they aren't that expensive in the scheme of things).
    - yaur 13y ago
      and that is exactly how we get clowns like linkedin storing all of their passwords as unsalted hashes...
- fishtoaster 13y ago
  It seems like there are a number of trivial ways to determine what method was used to hash the passwords. For example, hash a common password like `password` or `password123` with all common hashing schemes and compare see which of the resulting hashes are in the list of hashes you got from kickstarter.
- akerl_ 13y ago
  You may be joking, but for the sake of other people who might read that and not know the reality of the situation: That is not the case. Even just the length makes it pretty clear which hash is in use ( https://en.wikipedia.org/wiki/List_of_hash_functions https://en.wikipedia.org/wiki/List_of_hash_functions ), and even assuming some crazy "security" scheme in use for storing them (hashing and then padding, or some such), someone with the hashes only has to figure out one password to figure out the procedure used. Given the high likelihood of there being "password" or "12345" hashed somewhere in there, that's not so hard.
  - carbocation 13y ago
    You are correct; any wise attacker would create accounts with known properties before compromising the database for these purposes.
- danpalmer 13y ago
  Kerckhoff's principle: "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." This applies here too. If it's secure, which good hashing is, releasing the details should have little to no effect on the security of those hashed passwords. It's also trivial to determine what the hashing scheme is in many cases.
- tptacek 13y ago
  No it doesn't. Attackers can obviously be presumed to have some number of password,digest pairs; for instance, for their own accounts. From that information it should be trivial to figure out the scheme used. This of course leaves aside the fact that, having compromised any significant portion of the app, they are probably ε from source code anyways.
mecredis 13y ago
Hi, I work at Kickstater. When communicating with millions of people its important to balance technical explanations against the desire to communicate your message in common sense terms. That said, we're being very public with how we hashed them: older Kickstarter passwords used using SHA-1 digested multiple times. More recent passwords are encrypted with bcrypt.
- theboss 13y ago
  So do you have both in the same database or were only one type stolen? The difference is very important
- akerl_ 13y ago
  Can you clarify why older passwords were not rehashed to utilize the new scheme? Or are those just passwords of people who haven't logged in since you converted your backend to use scrypt?
  - Houshalter 13y ago
    Couldn't you hash the old hash with the new one even if they didn't log in? I.e. hash the password with the old SHA-1 first, then bcrypt that. I'm not sure if that would work or not.
    - akerl_ 13y ago
      In theory you could, but then the code has to support both login procedures forever (hashing once with scrypt or hashing with SHA1 and then scrypt). That's why, if it were me, I'd likely set it up so if someone with a SHA1-hashed password logged in, it first did the SHA1 comparison, and if that succeeded the login process dropped an scrypted version into the DB.
      - cmircea 13y ago
        You could just always do a hash using SHA1 then feed that to bcrypt. This way you only have one code path, for all users.
roel_v 13y ago
I can't help but get this visual every time there is a data breach, and somebody posts something like the parent: http://goo.gl/J20hUi http://goo.gl/J20hUi (and gets massively up voted). Please, get over yourself already.

zavi 13y ago

If they describe how passwords were hashed, it would make it easier for hackers to crack them.

jwcrux 13y ago
Shouldn't matter. Something like "We hashed each password using PBKDF2 and a unique salt and a high number of iterations" doesn't help all that much. The attackers will still have a tough time brute forcing those.
carbocation 13y ago
> If they describe how passwords were hashed, it would make it easier for hackers to crack them. I don't really agree with you. If you store bcrypted stuff, you see $2a${integer exponent}$hash. If you store SHA1'ed stuff, you see characteristic hashes and can trivially test against known hashes. So on for MD5, etc. I don't need you to tell me "we store SHA1'ed stuff iterated 35 times with the following salt", but keeping that information secret wouldn't usually help you anyway. A determined attacker will test and iterate until they've figured out your scheme (or, if you're unlucky, they won't need to). Telling the attacker "we bcrypted everything" doesn't tell them anything they couldn't plainly see on their own.
lucastx 13y ago
That's not how a properly implemented hash -- and cryptography in general -- is supposed to work. This strategy is called "security by obscurity", and is seen as a very bad one. Instead, cryptography aims to provide means to encrypt data in a way that anyone knows //how// it was encrypted, and still doesn't have a clue how to decrypt it -- because they don't have the key, in case of encryption, and because the hash is a "one-way" function, in case of hashing.
- hga 13y ago
  Disagree for systems. I take adding "security through obscurity" to the normal standard good methods as a defense in depth measure.
  - jleader 13y ago
    Adding "security through obscurity" is only a net win over "published security scheme" if your engineers are substantially better than any engineers who might comment on your published scheme. Even if you've hired world-class security engineers, there could still be some flaw they've overlooked, that an outside commentator might notice. Note that the security of a whole system is harder to get right than the security of any one component; keeping it obscure just makes it much less likely that a white hat will notice the flaw and notify you. A simple example of this is the freshman CS majors' perennial idea that combining multiple PRNGs will yield a "more random" algorithm (it typically makes the result easier to predict). There are plenty of cases of a secure algorithm being used to build a system that ends up insecure because of some obscure flaw that nobody noticed initially.
    - hga 13y ago
      "Adding "security through obscurity" is only a net win over "published security scheme" if your engineers are substantially better than any engineers who might comment on your published scheme." I think that overstates the case. Your engineers don't have to be better, just good enough know what's correct and safe, or do research until they know. My approach is to just add things that are clearly correct to published and studied systems that are thought to be correct. In this case, we're talking about applying multiple or multiple runs of one way hashing functions; I'd actually do some research before trying the latter, but it strikes me as safe, and the former is by definition safe, right? Whereas it would never even occur to me to combine PRNGs ... or not use a hardware source of entropy to begin with in the first place (they aren't that expensive in the scheme of things).
  - yaur 13y ago
    and that is exactly how we get clowns like linkedin storing all of their passwords as unsalted hashes...
fishtoaster 13y ago
It seems like there are a number of trivial ways to determine what method was used to hash the passwords. For example, hash a common password like `password` or `password123` with all common hashing schemes and compare see which of the resulting hashes are in the list of hashes you got from kickstarter.
akerl_ 13y ago
You may be joking, but for the sake of other people who might read that and not know the reality of the situation: That is not the case. Even just the length makes it pretty clear which hash is in use ( https://en.wikipedia.org/wiki/List_of_hash_functions https://en.wikipedia.org/wiki/List_of_hash_functions ), and even assuming some crazy "security" scheme in use for storing them (hashing and then padding, or some such), someone with the hashes only has to figure out one password to figure out the procedure used. Given the high likelihood of there being "password" or "12345" hashed somewhere in there, that's not so hard.
- carbocation 13y ago
  You are correct; any wise attacker would create accounts with known properties before compromising the database for these purposes.
danpalmer 13y ago
Kerckhoff's principle: "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." This applies here too. If it's secure, which good hashing is, releasing the details should have little to no effect on the security of those hashed passwords. It's also trivial to determine what the hashing scheme is in many cases.
tptacek 13y ago
No it doesn't. Attackers can obviously be presumed to have some number of password,digest pairs; for instance, for their own accounts. From that information it should be trivial to figure out the scheme used. This of course leaves aside the fact that, having compromised any significant portion of the app, they are probably ε from source code anyways.

mecredis 13y ago

Hi, I work at Kickstater. When communicating with millions of people its important to balance technical explanations against the desire to communicate your message in common sense terms. That said, we're being very public with how we hashed them: older Kickstarter passwords used using SHA-1 digested multiple times. More recent passwords are encrypted with bcrypt.

theboss 13y ago
So do you have both in the same database or were only one type stolen? The difference is very important
akerl_ 13y ago
Can you clarify why older passwords were not rehashed to utilize the new scheme? Or are those just passwords of people who haven't logged in since you converted your backend to use scrypt?
- Houshalter 13y ago
  Couldn't you hash the old hash with the new one even if they didn't log in? I.e. hash the password with the old SHA-1 first, then bcrypt that. I'm not sure if that would work or not.
  - akerl_ 13y ago
    In theory you could, but then the code has to support both login procedures forever (hashing once with scrypt or hashing with SHA1 and then scrypt). That's why, if it were me, I'd likely set it up so if someone with a SHA1-hashed password logged in, it first did the SHA1 comparison, and if that succeeded the login process dropped an scrypted version into the DB.
    - cmircea 13y ago
      You could just always do a hash using SHA1 then feed that to bcrypt. This way you only have one code path, for all users.

roel_v 13y ago

I can't help but get this visual every time there is a data breach, and somebody posts something like the parent: http://goo.gl/J20hUi http://goo.gl/J20hUi (and gets massively up voted). Please, get over yourself already.