Kickstarter Security Breach Exposes Customer Data 63
New submitter jbov writes "Kickstarter members received an e-mail at about 16:40 EST notifying them of a security breach. According to the e-mail, information including user names, encrypted passwords, mailing addresses, and phone numbers may have been revealed. Kickstarter members were urged to change their passwords. 'Older passwords were uniquely salted and digested with SHA-1 multiple times. More recent passwords are hashed with bcrypt.' Kickstarter claims that credit card information was not accessed during the breach. According to Kickstarter, law enforcement officials contacted the company on Wednesday night and alerted them that 'hackers had sought and gained unauthorized access to some of our customers' data.' Upon learning of the breach, Kickstarter closed the security breach and began strengthening security measures."
Re:They've been a target of CONservatives... (Score:5, Interesting)
Or perhaps the person is simply ignorant of any evidence to support such claims which you apparently seem to possess in such abundance. I actually haven't seen anything to support it either, for that matter, so from where I sit, the allegation strikes me more as being an unprovable conspiracy theory, and I would consider the notion as improbable as well.
Suggesting that someone who simply disbelieves a criticism must somehow be lying to protect them is even at best a variant of ad-hominem, and at worst, indicative of a possibly less than clear grasp of what is actually real and what is not.
Re:No notification yet. (Score:5, Interesting)
The notifications seem to be going out in waves, slowly. I'm not sure why. Across three folks I know (including myself) with Kickstarter accounts, the emails themselves all seem to have gone out within minutes of each other, but one of them arrived just minutes ago.
I'm guessing with the volume of emails, it got throttled along the way. You can see this in the Received: headers:
Received: from o2.e2.kickstarter.com (o2.e2.kickstarter.com. [74.63.202.49])
...
by xx.example.com with SMTP id xxxxxxxxxx
for < username@example.com >;
Sat, 15 Feb 2014 21:49:50 -0800 (PST)
Received: by filter-219.sjc1.sendgrid.net with SMTP id xxxxxxxxxx
Sat, 15 Feb 2014 21:18:46 +0000 (UTC)
Received: from MTEzNDg (unknown [10.42.83.122])
by localhost.localdomain (SG) with HTTP id xxxxxxxxxx
for <no-reply@kickstarter.com>; Sat, 15 Feb 2014 21:18:46 +0000 (GMT)
Notice that the earlier time stamps (corresponding to when the emails were generated) are around 21:18 GMT, but the arrival timestamps are around 21:49 PST, about 8 and a half hours later. And that's about how far apart our emails arrived. I imagine more are in the queue.
(And yay crapflooders for making it impossible to format things usefully in Slashdot comments.)
As far as passwords go, I'm not worried about anyone actually hacking my Kickstarter password. It's a password unique to Kickstarter, and it was generated at random.org as a 13 character mixed-case alphanumeric password. Good luck reverse-hashing that. Even if you do, it won't get you much.
Re:PKI (Score:5, Interesting)
Excuse me? A secret that never leaves my computer, at least not in any plaintext form (encrypt your private keys before exporting them, people!), is *way* more secure than a secret I need to provide over the Internet (even in an encrypted channel) and that the host I'm connecting to needs to store (even in a non-reversibly-encrypted form). If you don't think so, then there is something *very* wrong with the security of your box...
The way we do passwords now, even if you don't re-use the password, a single compromised host gives the attacker enough information to begin attempting to determine the login credentials of every single user on the site (and in many cases, those same credentials can be used on other sites too). Additionally, attacks can be made much faster using common password dictionaries and so on. In the case of a public-key system, all that the attacker would get is the public keys of every user on the site, but without the corresponding private keys - which they will never obtain from the compromised server, because the client never exposes them to the network - they can't obtain any user's login credentials. True, in the case of persistent malware on the server an attacker could hijack a user's session after login, but they would be unable to prevent the user from logging out or to log in again afterward, and they would be unable to try re-using credentials on other sites the user may have accounts on.
In fact, using public-key crypto is almost strictly as secure, or more so, than passwords. Sure, an attacker who targets a specific user's machine could potentially steal their secret key when the user unlocks it to log into a site, or steal it in its at-rest form (hopefully, encrypted with a password) and start brute-forcing that encryption. However, such an attacker could also have stolen a user's password database, or keylogged their password as they typed it into a site. If you just want to attack a single user, and you have the ability to compromise one of their hosts, it doesn't matter which system they use. However, if you can only attack a server (as is usually the case), public-key systems are way safer for the users.
The problem, of course, is how the user moves their secret key(s) from client to client. These days, almost everybody uses a number of different clients (your PCs, your workstations, your phone and/or tablet, your friends' phones, the library's PC, whatever) to access secured resources. There are a number of possible ways to transfer the private key(s) between all those things, but each has downsides. Oh, and the little problem of there not being any standard way (other than TLS client certs, which are not widely supported and arguably not the correct tool here) to use public keys to authenticate with a site right now, so something would need to be standardized and then implemented widely before it would be useful.