Hacker News Reader

Comment by mecredis | Hacker News Reader

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.

View on HN

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?

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.

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.

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.

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.

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-pass...

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'.

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.

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

How long ago did you stop using SHA1?

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.

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?

That depends on the value of "multiple". If multiple means thousands, that's one thing; if it means tens, it's pretty bad.

Was the salt constant, or per-password?

Was the salt stored in the same database and also accessed?

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.

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.

Does it matter? The purpose of salts is to thwart rainbow tables, not to be a shared secret.

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

Among whatever other reasons there might have been, the difference between SHA1 and SHA2 is not meaningful for password hashing.

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-2

Reply on news.ycombinator.com