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.

Yep, I appreciate your comments here. I mean my comment as a generality. And I think that any press release such as this one could put the hashing mechanism in small print at the bottom, or in a link, without confusing the average reader. We shouldn't have to turn to HN to find it.

"We shouldn't have to turn to HN to find it."

Why do you feel that a private company that is communicating with the press and it's users has any obligation to also inform in the same way (the blog post or press release) hackers and security personnel that would like to know the answer to these questions?

Disclosing these things is nice of course but it's not core to kickstarters business in terms of people who use kickstarter (projects or consumers).

Also be aware that in business there are a ton of behind the scenes things I would like to know that would help me. [1] And if your argument is that security information disseminated is helpful to all that's fine and is correct. So that can be disclosed at the companies discretion. But they have no obligation and aren't going to lose business because security people are mad at them or people on hacker news think a certain thing should have happened.

[1] For example more details on the Comcast merger and the back and forth. But Comcast is not in the business serving it's customer base by giving me info that is helpful to me.

I disagree. They do have obligation to tell me how my privacy is being protected. Morally at least. How the passwords and other sensible data are stored should be noted somewhere in the website. This applies to any site, not only kickstarter.

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?

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.

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.

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.

Except that for some people, you only have a SHA1 hash, and for others, you only have an scrypt hash. Since they (I hope) weren't storing the plaintext (pre-hash) passwords alongside the hashed versions, the only time they can change the initial hashing mechanism is when passwords are provided to them during a password change or user login.

Hash all the sha1 passwords with scrypt. Hash all new passwords with sha1 then scrypt.

Your new hash mechanism is sha1 then scrypt.

There is no excuse to do otherwise :)

(ADJUSTED:) Yes, if when you said "hash the password" you meant the result of what they'd done originally and that was stored in their databe. They don't have a copy of the password until and unless the user logs in again. These are all "one way" or "trapdoor" functions, plaintext -> irreversible cyphertext.

Irreversible in that we think mathematically you can't go back.

Read his comment again. Hash the password to SHA-1 using the old system, then apply bcrypt to it. It's a migration pattern I've seen in practice a few times.

Thanks! And updated to try to clarify.

Thanks for your transparency, but can you be more specific about when the switch from SHA-1 to bcrypt occurred?

If it was 6 (or more) months ago, then I think you'll find at least some sympathy here - "break things" sometimes happens after "move fast," and I'm sure we've all put some code in production that, in retrospect, we wish we hadn't. However, your statement is still technically correct if the switch to bcrypt happened late this week (ie, after the breach was made known to Kickstarter), and that worries me.

This is about as reasonable as asking whether they got hacked a year ago, did nothing, and didn't tell anyone. Only now do they tell us that law enforcement informed them. Read between the lines, man. Inhales.

Ha, fair enough - that statement was excessively cynical. Thanks for being a voice of reason on this issue.

Thank you for taking my snippiness in the constructive spirit I now rationalize it as being intended in. ;)

If anyone else, like me, was wondering, bcrypt has a built-in salt to prevent rainbow table attacks.

https://stackoverflow.com/questions/6832445/how-can-bcrypt-h...

If anyone else is still confused, bcrypt concatenates the salt to the end of the hash as opposed to storing it separately.

Thank you. I'm always confused if encrypted is PR-people speak for hashed, encrypted, or, worse, "we trust our engineers to do the right thing and encrypted sounds like we did the right thing".

One suspects that sometimes it's the PR people doing their thing, but that's a dangerous path to walk. If you just got caught with your pants down over a security flaw, following up by demonstrating both that you didn't really understand what was going on even after the flaw was discovered and that you were willing to try to cover it up is strikes two and three in one neat package.

Can you update the blog post to remove the wording "encrypted". That is simply incorrect. There is a clear and incredibly important difference between hashing and encrypting, the latter being designed to be reversible.

I'd appreciate a description of the hashing algorithm being added to the blog post, but that's less important.

If you say "encrypted", I read that as "somewhere we have a key that gives the attacker plaintext passwords, they might have that key as well".

This wouldn't be pedantic if we were discussing communications between cryptographers and other technologists, but this is a public notice, and so the point is very pedantic. For all intents and purposes, the password hash or authenticator of a password is its "encryption", in the layperson's sense.

Exactly.

In business the "simplicity abstraction layer" [1] on a product is essentially taking something that was created by hackers for hackers (or engineers) and making it simple for end users "the layperson".

God knows anytime you can make something easy for a layperson and not make them think there is money to be made. They aren't interested in your Liebert fire protection system and diverse path routing.

It never fails to amaze me how highly technical types simply can't think out of that box. And yet they make fun of "sales types" that can actually speak and sell to end users an inferior product.

[1] I actually just made that up.

But still, you could write "Our passwords are stored securely using the bcrypt algorithm; however, weak passwords..." and not compromise terms.

Hashing is often referred to as one-way encryption.

For example: http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?...

When communicating with the general public, it's useful to use words they understand.

The difficulty of linking to a high level definition of a hash function and its differences to encryption is not very high.

If a customer were to be curious as to what hashing is then that link should clear it up perfectly.

Do you thoroughly research the scientific, business, legal, medical, philosophical, religious, etc. underpinnings of every article you read? Just because you're knowledgable in this area doesn't mean everybody should be. Using the term "encrypted" rather than "hashed" is perfectly appropriate for a general press release. This is a highly pedantic criticism.

Missing the point. Most of the customers do not know or care what the difference is, will never read any definition or explanation of it, and shouldn't have to. If you try to force your customers to understand this stuff, they'll get confused and annoyed, and go with someone else who can make it clear for them.

So do you have both in the same database or were only one type stolen? The difference is very important

Is it possible to "convert" a Kickstart account from a username/password account to a Facebook OAUTH account? I currently connect my Kickstarter account with Facebook, but relied on a username/password for authentication.

Are you updating older password hashes to bcrypt on login? That's the perfect opportunity since you have the users password prior to hashing and comparing.

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

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

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 ), 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.

You are correct; any wise attacker would create accounts with known properties before compromising the database for these purposes.

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.

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.

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.

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.

Disagree for systems. I take adding "security through obscurity" to the normal standard good methods as a defense in depth measure.

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.

"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).

and that is exactly how we get clowns like linkedin storing all of their passwords as unsalted hashes...

See my other comment on starting with "published and studied systems that are thought to be correct". Salting your passwords has been state of the art for so long I can't remember when I first heard of it.

LinkedIn was not adding any sort of reasonable defense in depth security through obscurity, but foundational gross negligence.

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.