Edit: Changed "plaintext passwords were taken" to "plaintext-equivalent passwords were taken"
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.
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.
Your new hash mechanism is sha1 then scrypt.
There is no excuse to do otherwise :)
Irreversible in that we think mathematically you can't go back.
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.
https://stackoverflow.com/questions/6832445/how-can-bcrypt-h...
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".
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.
For example: http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?...
If a customer were to be curious as to what hashing is then that link should clear it up perfectly.
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.
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.
This of course leaves aside the fact that, having compromised any significant portion of the app, they are probably ε from source code anyways.
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.
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.
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.
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).
LinkedIn was not adding any sort of reasonable defense in depth security through obscurity, but foundational gross negligence.