Will you at some point consider telling us how the compromise happened? This information is useful even at a very high level; it's useful to know whether companies are breached by leaked admin passwords, or inadequately protected admin consoles, or in-app appsec faults like SQLI.
Best of luck dealing with this incident. You're in great company, unfortunately. :|
Over the many hacks (breaches, as companies prefer to call them) we’ve come to see, as a user who at times felt nervous about how I was affected, I have tried to write a simple guide for how companies can disclose a hack in a way that will assuage my concerns in the best way possible: https://gist.github.com/ndarville/5072091.
I originally intended to convert it to a disclosure generator, but I haven’t had the time.
I hope it can be of some help to you in dealing with this awful situation, and I’m terribly sorry this happened to you.
The sentiment of your comment is that transparency is somehow generous; and I could not disagree more. As user whose information has been potentially compromised, i expect nothing less.
You can expect whatever you want, but the norm in industry is for that sort of information to end up in a silo inside the company, and external exposure to it is permitted only under NDA or equivalent guarantees (e.g. sharing with law enforcement).
What you urgently want is a cultural change on behalf of industry. This guy is part of the change you want. Biting his fingers is not the optimal path to accomplishing your goals, even if it is viscerally satisfying.
Perhaps regulation needs to move from mandatory disclosure when credit card/payment data is leaked/lost to mandatory disclosure when credential data is lost as well.
I too want urgent cultural change on behalf of industry; I'll settle for regulation though.
Be careful what you wish for. Very few practitioners in this industry really understand what kind of regulatory honeymoon they're enjoying right now. Given the impact of the work we do to society, it is kind of a miracle we don't all have to be certified.
Perhaps regulation needs to move from mandatory disclosure when credit card/payment data is leaked/lost to mandatory disclosure when credential data is lost as well.
This is already the case in the EU with the Data Protection Directive.
"Upon learning this, we immediately closed the security breach and began strengthening security measures throughout the Kickstarter system."
..and
"We have since improved our security procedures and systems in numerous ways"
Perhaps when you do the blog post you could elaborate on what simple things (that were implemented in a few days?) were done especially why they didn't exist in the first place? An example being "we didn't do x because we thought y but now know that isn't the case so we are taking z extra precautions".
Also did you have outside security auditors and could they have done a better job? And if not, why not?
Making statements like "we don't store credit-cards" and "no credit card data was breached" are feel good statements to minimize brand impact. I find them difficult to accept and a bit disingenuous. How do they know their logs were not modified? Are they sure the attacker didn't insert their own markup or JavaScript to hijack the login or payment form or present a fake payment page? That type of attack can be done via SQLi, XSS Type 2, and a number of other vectors. I understand where they are at & I've been there, but when I was there, I recognized that sometimes there are no answers and all that can be done is to apologize and tell people to change their passwords and watch out for unauthorized charges.
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"
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.
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.
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.
(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 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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
Ugh. That reset procedure did not play well with LastPass.
I logged in (old password), hit change password (old password), then had LastPass generate a new password, which it handily saved over the old one in LastPass. Hit Save. And then the site asked me for the old password a third time.
Yep, I had almost exactly the same thing using a different password manager. I had to find another copy of the password storage file on a different machine and bring the old password over from it.
Note to Kickstarter: It is not good UX to ask for the new password, and then the old password. But that's likely the least of their worries right now.
Note to Kickstarter: It is not good UX to ask for the new password, and then the old password.
That is at least debatable. It might be a good idea to warn users that this will happen, if it's not immediately obvious from the form layout, but reauthenticating at the end of a lengthy or multi-step process is often a sensible precaution. Every system I use where security really matters (transferring significant amounts of money to another party from my bank account, filing statutory tax returns, etc.) does this.
(This isn't to say that a process for resetting a password that required the old one three different times would be sensible. But I don't accept your general-looking claim that it's bad UX to ask for the old password after the new one.)
I take the point that this may not be as general as I thought, and that warning up front is an alternative.
But in this case (or any password change case, really), it is not a "lengthy or multi-step process" and putting the old password at the end has surprised a number of people in a bad way.
Not just here, I've seen the exact same thing mentioned on twitter. See https://twitter.com/blowdart , "Wow, the kickstarter change password process is AWFUL. Prompt for existing password after? Screws up lastpass flow" - it has multiple retweets and "me too" replies.
I would have no problem with entering my password at the end of a lengthy high-value transaction, so long as that transaction hasn't also changed my password to something else earlier. Which it shouldn't.
A rule of thumb is that if a lot of people find the process is broken then the UX is probably bad, and needs a redesign.
A rule of thumb is that if a lot of people find the process is broken then the UX is probably bad, and needs a redesign.
That is true, though in this particular case it's not clear whether it really is "a lot" of people or more a vocal but possibly small group who are also using another specific tool, which might itself be the problem because it isn't flexible enough to do the job here. It sounds like you have a password generation/management tool where it is easy to delete a valuable password before you're done with it and with no way to get it back, which I would argue is probably a much more serious usability problem!
Ideally the change password process would be made clear for everyone and avoid the problem entirely, of course, and if we're just talking about a simple old/new password form (I haven't seen it) then surely that should be possible here. I'm not defending the status quo (again, I haven't seen it). I'm just saying I don't think this issue is quite as simple as you previously suggested, and possibly Kickstarter aren't the only ones with room for improvement here.
> more a vocal but possibly small group who are also using another specific tool
This has now been mentioned as a problem in 4 different tools: LastPass, KeePass, iCloud password manager and RoboForm.
While it is sadly still true that people who use password managers are a small minority, they are among the most security-conscious and technically literate users.
> It sounds like you have a password generation/management tool where it is easy to delete a valuable password before you're done with it
You could look at it that way. But I think that would be myopic. It's IMHO closer to the truth that this website is perverse about when you are done with the old password. And no other website that I have come across shares this defect.
> if we're just talking about a simple old/new password form (I haven't seen it)
Wow. So much invested in evaluated something you haven't experienced, but could easily.
>For additional help with password security, we recommend tools like 1Password and LastPass.
It's really too bad that they are recommending expensive, proprietary, commercial apps for this when free, open source alternatives like KeePass exist. If users are unconvinced on the value of a password vault, charging money for it certainly isn't going to encourage adoption.
It's really too bad that you recommend an app that is practically garbage user-experience-wise compared to LastPass and 1Password.
If users aren't convinced of the value of a password vault, a god-awful piece of software certainly isn't going to encourage adoption even if it's "free"
If users "aren't convinced" of the value of a password vault after seeing all these breaches they don't deserve security.
KeePass is perfectly usable if you spend 5 minutes figuring it out. It's also open source and thus analyzable for flaws, leaving one fewer vulnerability (proprietary code) for those who actually care about security.
I guess many people think it’s too expensive, but I have found the price for 1Password (~USD 20 IIRC) to be very reasonable for all the value it provides.
I have used lastpass for years, and recommend it to my friends.
It's easy to use, has a free options, though I opt to pay, and is a good combination of friendly and secure.
How secure is that? Couldn't they just as easily figure out your KeePass password (providing they know you are using it, and that reversing the KeePass hash isn't any more difficult than reversing the normal one.)
No, they can't. The websites allow anyone in the world to make a guess at a password. Keepass doesn't since it requires having the private database file which you store locally.
The websites allow for a vulnerability in third party code to expose you. Keepass, even if it has a vulnerability, can't be exploited remotely since the database is stored only locally.
The websites are in the browser and encourage browser extensions. Browsers suck for security... that's a massive attack surface and they are, by their nature, integrated with the network. Keepass is a dedicated application with a tiny surface that barely communicates with the internet at all and has no need to. A whole class of attacks miss it.
Yes it is secure in that area, I mean for the specific attack this post is about where a hash of your password is hacked. All keepass would do is make your password the product of two hashes instead of one. I wasn't sure if that was that significantly more secure (if it was why aren't websites doing it automatically?)
Of course that implies the attacker knows you used KeePass, security through obscurity and being in the minority should protect you.
No, the point is not to make your password more secure in case of a data breach like this (although it can, since you can store a password that is very long and composed of random characters)
The idea is that even if your password for kickstarter gets compromised, since you are using a password manager that password should only ever be used in kickstarter, so you can just change your password there and carry on
1) If you mean could they crack your keypass file where you keep all your passwords:
Presuming you're using the program well, that's possible but very unlikely. There are reasons to believe this would be more difficult than attacking any of your normal passwords individually though:
- The database for your passwords is not stored on a server they're likely to have been compromised, (it's a local file on your machine unless you place it somewhere else or your machine itself is compromised.)
- By having only one database, you can use an approach like a long diceware pass phrase. Which would allow you to generate a password for the database that's likely to be far harder to guess than any individual password that you might otherwise have used for the sites in the database.
- It's plausible to direct more processing towards making dictionary and guessing attacks against your database's password harder than a server would be likely to direct towards each individual user's password.
In case
2) If you mean could they crack the password for the website that you keep in the keypass file, by attacking the hash that they got from the server attack:
Theoretically, yes. However, again, there are several qualities in favour of the keepass approach:
- Generation is automated. People are usually bad at generating hard to guess passwords. We think that we're making something hard to guess by inserting letters and numbers into a few words and then going 'presto!' but in reality we tend to follow fairly common patterns in what words we pick, what letters we replace, and so on. We also tend to duplicate them across sites.
- Remembering and entry are automated. (We tend to be bad at remembering things that don't follow common patterns.) Thus making these generated passwords more practical to use.
Those two factors combined address the main weaknesses of passwords. It's not something innate about the database that does this, mind. You could do much the same yourself if you had a perfect memory, or a notebook, and were willing to sit there throwing dice to get a good entropy source. However, I've yet to meet a human who remembers a significant number of dice-generated pass-phrases for all their accounts, and writing your passwords down represents its own potential problems (loss, compromise, speed of entry when reading the things.) The way to bet is that this is going to give you a harder to attack password than you'd come up with by yourself.
They also reduce the impact of a compromise. If a password for a site is compromised, then that compromise is limited to that website, and relatively easily rectified as compared to a more general breach if you reused your passwords.
For instance, my hacker news password until shortly before this post was:
But that's worthless information now. I told my password prog to generate another string, and now it's something else. Took less than a minute.
#
Of course, if your keepass vault itself is compromised, then you may be dealing with a worse situation. However, considering the general weakness of passwords, and the degree to which they get duplicated, and the additional security features around things like banks that protect some of the more vital stuff, I'm not sure that even putting all your eggs in one really well guarded basket makes you significantly more vulnerable if it is broken into.
But regardless, the cost of attacking an individual user goes up dramatically, whereas the rewards don't seem to scale in line with that. If someone thinks you're interesting enough to attempt to compromise your computer, get the database, and then invest resources in guessing your database password... you've probably got more serious problems anyway.
I'm pretty active on Kickstarter, backing multiple projects.
What's really worrying is that the Kickstarter folk didn't detect the breach themselves. It was law enforcement (I'm assuming FBI) who contacted them about it.
On the security notice, Kickstarter writes they "set a very high bar" on how they serve their community. What a load of crock!. If they had a high bar this would never have happened. I wish they wouldn't rub salt in the wound by publishing such blatant rubbish.
I'm extremely disappointed with Kickstarter right now.
You should prepare to be extremely disappointed by almost everyone you do business with online. At least Kickstarter was alerted by law enforcement and not Pastebin.
Exactly. You are in horrible shape if it's the police alerting you to this. My policy is "You lose my info, you lose my business". I deleted my account.
"No credit card data of any kind was accessed by hackers. "
Ironically there is at least a clearly defined system and procedure setup to mitigate a stolen credit card number. Essentially most if not all credit card companies will wipe out any malicious charges and cheerfully replace your credit card. And hopefully if you have more than one card that's not even a problem that you have to wait.
All the other information though that is:
"some information about our customers was. Accessed information included usernames, email addresses, mailing addresses, phone numbers, and encrypted passwords"
...well to me that's actually more of an issue. Ironically.
Kickstarter requests access to "your public profile, friend list, email address, hometown, current city and likes" from Facebook on logon. With stolen access tokens the attackers could query Facebook for that information with limitations:
1) only available until the tokes were revoked
2) if enabled, attacker must also obtain the 'app secret' and sign requests
3) if enabled, attacker must use the tokens from a white-listed IP address
The post only makes reference to encrypted passwords. Not sure if Facebook access tokens are included in that or not.
It means the tokens are no longer valid. It's as if the user has disconnected the Kickstarter app from their Facebook account. To log in with Facebook again, they have to reconnect, thus generating a new token.
On Wednesday night, law enforcement officials contacted Kickstarter and alerted us that hackers had sought and gained unauthorized access to some of our customers' data. Upon learning this, we immediately closed the security breach and began strengthening security measures throughout the Kickstarter system.
No credit card data of any kind was accessed by hackers. There is no evidence of unauthorized activity of any kind on your account.
While no credit card data was accessed, some information about our customers was. Accessed information included usernames, email addresses, mailing addresses, phone numbers, and encrypted passwords. Actual passwords were not revealed, however it is possible for a malicious person with enough computing power to guess and crack an encrypted password, particularly a weak or obvious one.
As a precaution, we strongly recommend that you change the password of your Kickstarter account, and other accounts where you use this password.
To change your password, log in to your account at Kickstarter.com and look for the banner at the top of the page to create a new, secure password. We recommend you do the same on other sites where you use this password. For additional help with password security, we recommend tools like 1Password and LastPass.
We’re incredibly sorry that this happened. We set a very high bar for how we serve our community, and this incident is frustrating and upsetting. We have since improved our security procedures and systems in numerous ways, and we will continue to do so in the weeks and months to come. We are working closely with law enforcement, and we are doing everything in our power to prevent this from happening again.
Kickstarter is a vibrant community like no other, and we can’t thank you enough for being a part of it. Please let us know if you have any questions, comments, or concerns. You can reach us at accountsecurity@kickstarter.com.
1. Have you leaked physical addresses that were provided to completed projects for shipping of the rewards?
2. Given the wording - "access to some of our customers' data" - will you provide a way to check if specific account was affected? Or was it "possibly all customer data"?
Hashed Passwords, layman don't know what a "hash" is so they use the term encrypted since most people know what that is (even if it's incorrect terminology) It's pretty clear when they say that a weak or obvious password would be easier to crack, hash tables.
I had an incensed reaction to their email, which had only stated that the passwords were "encrypted". Not until I searched these comments here for the text "encrypt" did I learn that they actually hashed with bcrypt.
I humbly suggest all security notices like this that are sent in the future, if written with the word "encryption" rather than "hashing" for the layperson's sake, have an asterisk next to the word "encryption". At the bottom of the email, the explanation "hashing with {{algo}}" where "hashing" links to [1] would be included. Laypeople get their simple explanation, technical people don't get too angry. And some laypeople may click through the link and learn something.
Yeah. We don't know the detail yet. It could also be a credit company advised the customer to talk to law enforcement for record. We don't know. Let's hope there is more detail.
Has anyone received this as an email (or any other notice besides reading it on their blog / news sites)? It looks like it may have been emailed to people running Kickstarter campaigns, but this really ought to be sent to all people with affected information (which sounds like all users). If they don't do that and/or expire passwords currently stored to require that users reset them, it's highly likely that a lot of users won't ever notice or change their credentials.
EDIT: I did just talk to someone who is not a campaign owner and received an email regarding this, so it does look like they're in flight.
Couldn't agree with you more. They have no problem sending me emails about new campaigns or other activity on the site. I feel like a message about a possible security issue would have been a decent thing to do.
When will big companies value personal information enough to encrypt it along with credit card information and hashing passwords? We encrypt all personal information at Miniand, and I do realise it makes it very difficult to query data, but I believe that's an inconvenience that needs to be accepted.
We recommend you do the same on other sites where you use this password. For additional help with password security, we recommend tools like 1Password and LastPass.
Please don't make such recommendation. This won't change the fact that password is stored in your database. In a security breach, don't ever make such recommendation.
In fact, the alert doesn't tell me exactly what happened. Are just two accounts stolen from phishing attack? Or was it a server breached? We need that detail.
For disclosure, please do the following:
1. time of incident reported and the time of impact.
2. how the incident was reported
3. the severity of the incident
4. how the incident happened
5. resolution
I don't mind having a first notice and then follow up by a more detailed post, but don't forget...
Huh? I don't follow this at all. Why should they not recommend password managers? More people should, in fact, be using them.
We'd all like answers to every question we could have about the compromise. As you can see upthread, they've already committed to providing some of those answers. In the meantime, they're probably slammed with other things, and you aren't actually entitled to answers to all of your questions. You are obviously free to take your business elsewhere if their answers aren't satisfactory.
To be fair, GP did say he didn't mind if they delayed answers until they've remediated the issue.
>you aren't actually entitled to answers to all of your questions. You are obviously free to take your business elsewhere if their answers aren't satisfactory.
I would agree, generally. But this is an issue wherein the company has failed the trust that was previously placed in them by the customer. The customer already made the decision to give the company his business and so could incur harm, even if he subsequently chooses to take his future business elsewhere.
So, I believe customers are certainly "entitled to answers". Judging from the way Kickstarter is handling this, it appears that they agree.
"But this is an issue wherein the company has failed the trust that was previously placed in them by the customer. The customer already made the decision to give the company his business and so could incur harm, even if he subsequently chooses to take his future business elsewhere."
Seriously? You think this is going to materially impact kickstarter? [1] That all of the sudden people will stop having projects and people will stop funding projects. That this is like the Corvair and "unsafe at any speed" or Audi unintended acceleration? To things like this a typical end will think "happens to everyone yawn what's for dinner".
[1] If anything the publicity of the break will help kickstarter if it gets any national media attention (I don't think it will but other security breaches have). Things like this are usually bad for well known brick and mortar companies (say Target) but not the same for a company at the lower level of brand awareness of Kickstarter. Very familiar to all of us on HN but in terms of the general public in fly over country not that well known. Remembering early stories of nasty stuff on ebay and craiglists that got mentioned that only helped them.
Sorry, while you are certainly more knowledgeable about security, I have to disagree with you.
We don't yet know what is going on and recommending password manager makes no sense until we know the actual problem. And deferring security breach to an external tool is not a recommendation anyone should make.
So having a password manager would solve a SQLi? It might be the case that this is just some stolen account from phishing attack. But do we know? We don't. So now using LastPass makes the user more confident about his or her password security inside KickStarter? How can anyone be happy with that conclusion?
Secondly, password managers don't make your password more secured. Maybe I should rephrase: don't even consider any online password manager. Storing multiple passwords in a single database that someone else owns? I don't see how that's going to make me feel better about password security. If anything, decentralized means we don't give a single person all the identity. Now we do. We tell LastPass here are the list of passwords I use. Great. I probably will be slightly happier with an offline password manager, but in the end, your brain can function and scale better than a service.
Sorry, fundamentally and practically I will have to disagree with you. And I stand by my own view and there is nothing wrong with my view and any downvote just seems ridiculous. In fact, I think people should think deeply before utilizing ANY password manager. If you have a security breach, focus on disclosure and tell people what went wrong because that's the only thing can tell people how to do better with their account.
Nothing in this comment constitutes an argument for password managers being a bad thing, or even simply not an unalloyed good thing. I am if anything more confused about what your argument is now.
I think you're confused -- 1Password is a local client, with no online component run by 1Password (well, by Agile Bits, the makers of 1Password). They have good clients for OSX and iOS, and kind of shitty clients for Android and Windows (IIRC).
1Password does have some sync functionality between devices, using third-party services (dropbox, iCloud) and LAN-local using wifi. Or you could otherwise copy your own encrypted password database between machines.
It won't prevent SQL injection but it makes it trivially easy to use a different password for each site so that when Kickstarter gets hacked you can just change that password.
People should use different passwords for different sites anyway but we both know they don't and most people wouldn't be able to handle that.
"however it is possible for a malicious person with enough computing power to guess and crack an encrypted password, particularly a weak or obvious one."
I own my domain, and use distinctive user names for registering at sites like this. I'll have to start checking my spam folder for the address I used (which I hadn't just cleaned it out...).
Time to get LaunchKey (https://launchkey.com). Seriously, any Kickstarter employee wants to talk about integration and protecting users contact us. LaunchKey is password-less multi-factor authentication. These user data breaches don't have to include the password hysteria and weaknesses.
Didn't store my credit card info with them, used a long, random, unique password from a password gen, not terribly concerned. The peace of mind this buys me is absolutely worth the hassle of setting it all up, and the accusations of paranoia from more relaxed friends and family.
So I received a mail from Kickstarter and I changed my password and went on with my life. I don’t think the intruder will find any use for the bcrypt hash[+] of my password. Especially as that password has never been used for any other site.
* Changing it is pretty much trivial: generate new password, plug in site, save
* I may have set it before KS started using bcrypt, and I'd rather not have third parties log in my KS account, even if (as far as I can see) there's nothing they can do with it
Personal information will always be leaked in various ways. Major web sites without any breaches can probably be counted on one hand. People who cannot tolerate this should probably get a post-office box, provide a false identity and/or keep their user account registrations to a minimum.
As a longtime Kickstarter user, I'm going to have to delete my account. If they couldn't handle security and rake in Millions if not Billions in annual revenue. What else were their priorities?
If my security is an afterthought to you, then you don't deserve my business.
That'll sure show them. Next time, I'm sure they'll start a business that does security better than any other company in the world, including banks, payment processors, the NSA, &c. Since, after all, that's apparently where the bar is set.
I wouldn't have cared if it was just CC info that had been leaked as I could've easily remedy that. My personal info + password hashes are what pushed me over to this decision. I've personally given them over thousands of dollars of business and was helping others launch their projects on there.
The list of companies who have meaningful numbers of users and haven't been hacked is growing vanishingly small. You'll also notice that no payment information was breached, substantially better than most other similar events.
Plus, I'm not sure where you possibly got billions in annual revenue? They're incredibly public about their statistics and business model. They take 5% of successfully raised projects. They report $842M successful dollars on the site, for a lifetime revenue of $42 million in the 5 years since they were founded.
Do they handle people's money? I thought that all went through AMZN.
In any case: if you're setting the bar for "handling transactions online" at "must be the first to detect any compromise", you're probably good with using Amazon and... hm, probably nobody else.
I suppose I wouldn't be surprised if the actual use in the industry of effective intrusion detection systems was negligible, but I'd hope otherwise. I'd note that we wouldn't likely hear about many intrusions discovered by the entity itself, they'd ideally stop them before anything major was lost, at worst case keep it quiet.
And, you know, outside of computer stuff where I send my money to NewEgg, I do by default prefer Amazon to all others.
(NewEgg has good prices, superb shipping of bare hard drives, the very best and informative reviews, and now a question and answer system, which sends email to people who've bought a product in case they can answer them. Or so I've found with a fan I recently bought, and helped two people, in one case whipping out my micrometer.)
(That is not asked out of idle curiosity, and I've been told the worst intrusions hack the kernel so tripwire would likely be useless, but don't know if those are widespread.)
I operate from the assumption that any serious compromise starting at SQLI injection equates to kernel compromise, so I don't spend a lot of time thinking about host-IDS either.
Tripwire is not a total waste of time, like a network IDS would be, but for most startups a minute spent setting up Tripwire is a minute that could be better spent on appsec.
That is quite a leap to assume root access. A user mode database should have write access only to partitions that are mounted noexec. That would make getting root privileges quite hard even on a vulnerable kernel.
Also with proper hardening you can prevent the kernel from being modified even by root. Things like FreeBSD securelevel that once enabled blocks writing to kernel memory and raw disk devices.
Tripwire is just file integrity. It can help to detect the installation of a backdoor. But that doesn't help at all if the backdoor is just memory resident (or installs at kernel level). It also doesn't help if the attacker breaks in, grabs your data and leaves for good.
File integrity is also a pain in the ass. You have to keep a database of good file hashes and it can't be stored on the server (or the attacker modifies the known good hashes). Generally you also should not even have the file integrity software on the live server filesystem.
Similarly Network IDS has the flaw that you must have well defined profiles of "normal behavior" so it can identify abnormal behavior. The other option is signature-based but that would only detect known exploits.
How can snail mail addresses and phone numbers be obtained through kickstarter, since credit card info is 'safe'? Are there instances, other than customers providing this information for rewards to be sent, in which this information can be accessed?
Since credit card info is safe, is there a way for names, addresses and phone numbers to be obtained through kickstarter other than through customers providing it to projects so they can have rewards sent to them?
When the data that was stolen crops up on a forum somewhere, can someone please make one of those stub-websites that helps you check if you got stung by the breach?
How is it that databases of password hashes can be stolen in te first place? It seems that you need a pretty severe firewall and server breech for that to occur.
Usually because the password database is able to be compromised by some code injection bug (e.g. SQLi). In order to prevent this you should be using a library the makes it impossible to mix code and input data like that.
SHA-1 has been considered weakened since 2004 and it is recommended not to use it in new cryptosystems. It's not the worst hash out there, by far, but it can be calculated relatively quickly which may make finding collisions easier as new insights and faster technology becomes available. Bcrypt has a variable number of iterations in the algorithm. Increasing the number of iterations makes the hashing a lot more computationally intensive. Sufficiently so to make brute force attempts intractable for now. And even when somebody has the computing power to easily calculate your hash, increasing the number of iterations will negate that advantage.
I was trying to go 60 days without posting on HN. I't been 42 days. This is important enough to break my silence and at least make a request.
Kickstarter: You deal with personal and financial data. Could you please enable two things for those of us who understand security issues and want better security:
1- Give me the option to not use my email as the login user id.
I've warmed-up to the idea of using randomized user names on sites that allow it. Something like "aoc4sour*!Z". On such sites I have completely different and randomly generated user id's and passwords. Pretty much impossible for an intruder to associate those accounts with any other accounts.
...unless...
They can access personal information such as real name, email, mailing address, phone and other personal identifying data that could contribute towards social engineering into other sites.
hence...
2- Please enable an option to choose two factor authentication.
This should be there as a firewall to access any personal data at all, even email and real name. It should also be required for any financial transaction, including pledging any amount on a project.
I'd say make it optional because the less informed (or less paranoid) might not want to bother.
finally...
3- I love questions such as "What's the name of your first pet?". How about some of those?
I am being a bit sarcastic here. When answered honestly these questions are really dangerous. It doesn't take a lot of social engineering to figure out most of them when armed with enough personal data.
However, I like to answer such questions with a random set of words. So, the name of my first pet might be "blue ladder tent aquifer". In other words, pretty much impossible to guess even if I gave you access to my facebook and linkedin accounts.
When used in this fashion these questions, I think, are actually useful. I'd venture to guess that most people don't do it this way because they don't understand the implications of providing straight answers.
These kinds of breaches have been accelerating. At least that's the feeling I'm getting. This to the point that I had a sit-down security meeting at home to make sure everyone at home understands what's going on and the fact that we need to make sure we use different passwords for every site and service and even different user names where possible. Pain in the ass but far less so than having your life turned upside-down by one of these idiots.
Any thoughts, comments or improvements on the above will be highly appreciated.
BACK TO LURKING:
In the meantime, I am going to see about going back into mostly lurking mode on HN. I found it quite revealing to take a real break from reading and posting on HN. For the last 42 days I've checked HN's first page nearly daily and only scan a few threads very quickly, dismiss most of them and refrain from posting comments (until this one).
ON ANOTHER TOPIC: HELL-BANNED?
I wanted to initiate a thread to share my observations and reflections after, well, now 42 days of just glancing at HN and not posting. However, either I am the subject of a strange hellban or something is broken. I can post comments all I want but I don't seem to be able to start new threads. Not sure how to fix it. Too bad.
For #1, the answer is to own your own domain and use an email service that allows anything@your-domain.com. I use Fastmail, and my Kickstarter account had its own "anything" ... although I hadn't thought of randomizing (a portion of) it. Good idea!
2: Two factor only helps the sites that use it. A less careful user might use the same password at every site, including those that require a 2nd factor.
3: Yep, that can be an issue. I've found as of late many sites offer enough questions that social engineering would utterly fail. And see #2, this doesn't address other sites.
The first trick is to not let your site get compromised, and for any data gained to be of little use. Any site like Kickstarter that handles Other People's Money (e.g. credit cards in the U.K.) should be very, very paranoid: https://news.ycombinator.com/item?id=7245666
I got too involved in a number of threads involving politics. I probably went counter to the ideology supported by those moderating HN and eventually got chopped-off at the knees.
I say "rightly so" because after taking a 42 day break from HN I look back at this community with different eyes. It should be about tech and startups with as little extraneous stuff as possible. That's where HN delivers value.
Taking several steps back and looking at what I've seen over the last 42 days it is obvious that most discussions that stray far away from tech are pretty much pointless whining from one side or the other of the argument. Most of these are a total waste of time. In a lot of cases they blow out of proportion because the average HN poster/reader is younger and lacking enough real-world experience. So you have worlds colliding with nothing of any measurable use being produced.
Even with technical discussions there's a lot of wasted typing on HN. Everyone is responsible of this to one extent or another. I am not excluding myself from any of these characterizations. Over the last 42 days I've clicked through threads and, more often than not, I tend to dismiss them as "typical difficult programmer nit-picking" which is what I typically see when discussions between programmers turn into endlessly going back and forth on fundamentally insignificant details. Programmers are some of the most difficult people to argue with. It must be the automatic "if-then-else" and "switch" statements that you develop over the years.
Anyhow, it sucks to be able to comment but not initiate threads. On the other hand, it's also a nice way to limit the time one devotes to such things. Would I like to have my thread starter privileges restored? Of course. Am I going to get into political or minutiae discussions? Nope. Waste of time, for all involved.
Best of luck dealing with this incident. You're in great company, unfortunately. :|