3 ms·

Hi! I work at Kickstarter. To answer everyone's question regarding the encryption used for our passwords: old passwords used salted SHA1, digested multiple time

Hi! I work at Kickstarter. To answer everyone's question regarding the encryption used for our passwords: old passwords used salted SHA1, digested multiple times. More recent passwords use bcrypt.

carbocation 13y ago
Thanks for sharing. Curious: at the time of conversion, why not run everything through bcrypt, rather than keeping a dual system? (This way, the old passwords get validated with ->SHA1->digest->bcrypt, and the new passwords get validated with ->bcrypt, but either way everything in the system is bcrypted.) My guess is that it was a CPU cost decision but I'm curious anyway.
- fosk 13y ago
  My guess is to avoid asking every user to change their password. From a UX perspective, it's not a nice thing to ask. This has nothing to do with security, where I agree that having one system is certainly better.
  - phpnode 13y ago
    There is a way to improve the security of weakly hashed passwords without having to ask the user to change their password - http://blog.jgc.org/2012/06/one-way-to-fix-your-rubbish-password.html http://blog.jgc.org/2012/06/one-way-to-fix-your-rubbish-pass...
  - kleiba 13y ago
    Nobody would have to change their password, the suggested change would only affect Kickstarter's internals. You'd still have two different systems in place like in the solution that was actually implemented, but both of them would contain a 'brcypt'.
  - deserted 13y ago
    The point of carbocation's technique is to avoid requiring users to reset their passwords, but to protect every user with bcrypt. The existing SHA password hashes could be used as the input to bcrypt.
falcolas 13y ago
Was the salt constant, or per-password?
- Nogwater 13y ago
  Was the salt stored in the same database and also accessed?
  - daeken 13y ago
    If it's per-password, then that doesn't matter. Salts for passwords should be stored as part of the hash itself, as with bcrypt, scrypt, and others. The purpose of a salt is to defeat rainbow tables (either global, as in unsalted MD5, or site-specific in the case of a fixed salt for a whole site); nothing more.
    - Nogwater 13y ago
      That makes sense. Wikipedia says "The primary function of salts is to defend against dictionary attacks and pre-computed rainbow table attacks." So, I guess I was thinking that if salts were stored separately, then that would help on the dictionary angle.
  - cheald 13y ago
    Does it matter? The purpose of salts is to thwart rainbow tables, not to be a shared secret.
RyanZAG 13y ago
Thanks for the info, salted+multiple digest means this isn't nearly as bad as it could be. Any chance you could give us information on what kind of attack vector was used?
- deleted 13y ago
  [deleted]
- tptacek 13y ago
  That depends on the value of "multiple". If multiple means thousands, that's one thing; if it means tens, it's pretty bad.
itafroma 13y ago
I see that when I log into Kickstarter, there's a banner that recommends changing my password. That's pretty good, but why not take it a step further by invalidating all the passwords and forcing a password change when someone logs in?
- eridius 13y ago
  Possibly because that's quite user-hostile? I may not be in a position to generate a new password and save it on a given arbitrary login to the site. Fundamentally, this isn't a high-risk situation. If the password controlled something vital, then sure, force the reset on everyone. But what's the worst someone can do with my Kickstarter credentials? They certainly can't spend any of my money, that requires my Amazon password as well.
  - shdon 13y ago
    Also, they say that "For pledges to projects outside of the US, we store the last four digits and expiration dates for credit cards." Isn't that the information that resulted in Amazon and Apple accounts being compromised last year? Perhaps those two have fixed their procedures to prevent that from happening again, but other companies may not have been pro-active. And even if proper procedures are in place, all it takes is one little screw-up.
lettergram 13y ago
Any reason you don't use SHA2? Just old software/compatibility issues, or...?
- tptacek 13y ago
  Among whatever other reasons there might have been, the difference between SHA1 and SHA2 is not meaningful for password hashing.
  - lettergram 13y ago
    Actually, SHA-1 has several security flaws, SHA-2 fixed some of those issues. With a salt SHA-2 should be fine, double salt would be better... http://en.wikipedia.org/wiki/SHA-1 http://en.wikipedia.org/wiki/SHA-1 http://en.wikipedia.org/wiki/SHA-2 http://en.wikipedia.org/wiki/SHA-2
deleted 13y ago
[deleted]
r0muald 13y ago
Why resetting passwords is an optional step left to users? Wouldn't it be more rational to reset all passwords?
tmoertel 13y ago
How long ago did you stop using SHA1?
- tptacek 13y ago
  I wanted to know this too, just because I was curious whether my password was bcrypted. But if they're in the middle of remediating problems, I don't want to know so much that I'd ask them to go look something up.

Hi! I work at Kickstarter. To answer everyone's question regarding the encryption used for our passwords: old passwords used salted SHA1, digested multiple times. More recent passwords use bcrypt.

carbocation 13y ago

Thanks for sharing. Curious: at the time of conversion, why not run everything through bcrypt, rather than keeping a dual system? (This way, the old passwords get validated with ->SHA1->digest->bcrypt, and the new passwords get validated with ->bcrypt, but either way everything in the system is bcrypted.) My guess is that it was a CPU cost decision but I'm curious anyway.

fosk 13y ago
My guess is to avoid asking every user to change their password. From a UX perspective, it's not a nice thing to ask. This has nothing to do with security, where I agree that having one system is certainly better.
- phpnode 13y ago
  There is a way to improve the security of weakly hashed passwords without having to ask the user to change their password - http://blog.jgc.org/2012/06/one-way-to-fix-your-rubbish-password.html http://blog.jgc.org/2012/06/one-way-to-fix-your-rubbish-pass...
- kleiba 13y ago
  Nobody would have to change their password, the suggested change would only affect Kickstarter's internals. You'd still have two different systems in place like in the solution that was actually implemented, but both of them would contain a 'brcypt'.
- deserted 13y ago
  The point of carbocation's technique is to avoid requiring users to reset their passwords, but to protect every user with bcrypt. The existing SHA password hashes could be used as the input to bcrypt.

falcolas 13y ago

Was the salt constant, or per-password?

Nogwater 13y ago
Was the salt stored in the same database and also accessed?
- daeken 13y ago
  If it's per-password, then that doesn't matter. Salts for passwords should be stored as part of the hash itself, as with bcrypt, scrypt, and others. The purpose of a salt is to defeat rainbow tables (either global, as in unsalted MD5, or site-specific in the case of a fixed salt for a whole site); nothing more.
  - Nogwater 13y ago
    That makes sense. Wikipedia says "The primary function of salts is to defend against dictionary attacks and pre-computed rainbow table attacks." So, I guess I was thinking that if salts were stored separately, then that would help on the dictionary angle.
- cheald 13y ago
  Does it matter? The purpose of salts is to thwart rainbow tables, not to be a shared secret.

RyanZAG 13y ago

Thanks for the info, salted+multiple digest means this isn't nearly as bad as it could be. Any chance you could give us information on what kind of attack vector was used?

deleted 13y ago
[deleted]
tptacek 13y ago
That depends on the value of "multiple". If multiple means thousands, that's one thing; if it means tens, it's pretty bad.

itafroma 13y ago

I see that when I log into Kickstarter, there's a banner that recommends changing my password. That's pretty good, but why not take it a step further by invalidating all the passwords and forcing a password change when someone logs in?

eridius 13y ago
Possibly because that's quite user-hostile? I may not be in a position to generate a new password and save it on a given arbitrary login to the site. Fundamentally, this isn't a high-risk situation. If the password controlled something vital, then sure, force the reset on everyone. But what's the worst someone can do with my Kickstarter credentials? They certainly can't spend any of my money, that requires my Amazon password as well.
- shdon 13y ago
  Also, they say that "For pledges to projects outside of the US, we store the last four digits and expiration dates for credit cards." Isn't that the information that resulted in Amazon and Apple accounts being compromised last year? Perhaps those two have fixed their procedures to prevent that from happening again, but other companies may not have been pro-active. And even if proper procedures are in place, all it takes is one little screw-up.

lettergram 13y ago

Any reason you don't use SHA2? Just old software/compatibility issues, or...?

tptacek 13y ago
Among whatever other reasons there might have been, the difference between SHA1 and SHA2 is not meaningful for password hashing.
- lettergram 13y ago
  Actually, SHA-1 has several security flaws, SHA-2 fixed some of those issues. With a salt SHA-2 should be fine, double salt would be better... http://en.wikipedia.org/wiki/SHA-1 http://en.wikipedia.org/wiki/SHA-1 http://en.wikipedia.org/wiki/SHA-2 http://en.wikipedia.org/wiki/SHA-2

deleted 13y ago

[deleted]

r0muald 13y ago

Why resetting passwords is an optional step left to users? Wouldn't it be more rational to reset all passwords?

tmoertel 13y ago

How long ago did you stop using SHA1?

tptacek 13y ago
I wanted to know this too, just because I was curious whether my password was bcrypted. But if they're in the middle of remediating problems, I don't want to know so much that I'd ask them to go look something up.