Well, that does it. I didn’t want to post on rumor but now numerous legitimate news sites are editorializing and the CEO of Kickstarter, Yancey Strickler has come out and apologized on the company blog I think it is time for us to discuss and perhaps even criticize. Let us look at some of her comments.
“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.”
So not only was the site hacked and data leaked, they had no systems in place to detect such a leak and suffered the embarrassment of a third party – in this case a law enforcement agency – notifying them that their site has been owned.
As for the users – kickstarter has obviously fixed whatever vulnerability allowed access and now recommends that all users reset their passwords. A typical response to such an event by a medium enterprise. After all, this isn’t AMEX or anything remotely worth losing sleep over. That said, credit card data obviously changes hands on the site but we can rest assured.
“No credit card data of any kind was accessed by hackers. There is no evidence of unauthorized activity of any kind on all but two Kickstarter user accounts.”
Wow. Thanks Ms. Strickler I think your users will choose a new password and sleep better tonight. But, hang on…
“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.”
So while by some miracle of luck they used an external payment gateway and thus the card numbers were saved all of the other information is likely floating around on a torrent site in an sqldump.
Realistically how dangerous is this breach to the average user (assuming their password hash isn’t guessed) – more than likely identity thieves would value this information and could likely launch a springboard attack possibly by using social engineering techniques to perhaps call your ISP and request a password reset on your email account. All of the details for phone verification of the user’s identity have kindly be provided. From there who know where access to your mail stream could take him? Sensitive information is routinely sent in the clear over email. Our hypothetical criminal would be best to instead ask the friendly ISP to add a “cc” to an address owned by the attacker so that the mailbox password need not be reset, obviously raising alarm.
I suspect that if we take this data and compare it with other recent(ish) breaches like gawker and Sony we will likely see many of the same accounts. An analysis of this would prove very interesting.
So what should you take from this? Never re-use passwords so that even if they happen to crack your hash (unlikely with a decent non-dictionary password but nonetheless) you are still safe. Understand that your email address if reused can be used to profile your time online and what sites you have subscribed to so perhaps generating some aliases isn’t a bad idea. And I guess the most important lesson is that you don’t matter to these corporate website owners – so be proactive and if necessary feed false data (date of birth, mother’s birth name etc) where you don’t trust the site. Don’t ever rely on a corporation to keep your secrets secret.
This shouldn’t have happened and the CEO’s comments don’t fly with me. Such a large website needs to protect its core asset – its user base. Clearly the users of kickstarter are not worth the trouble.
Since you’ve just alluded to it, I’d like to go a bit further and suggest that people ALWAYS use false information for the password reset identity verification questions sites use. Your mother’s maiden name? That’s on your birth certificate and notice of live birth. Which, if I know your name, I can probably find on ancestry.com or any other public record aggregator. Address where you lived 10 years ago? Probably on your full credit file. Your teacher’s name in 3rd grade? Again, someone skilled at newspapers.com can probably find this.
Where a password reset question asks “What is your favorite food?” I’d be willing to be 25% or more put down “pizza” or “steak”. What percentage will answer this question with “honda civic”? Not many. When it asks for the manufacturer of your first car, do you consider there are probably only a dozen or so choices that account for 95% of the answers? Wouldn’t you rather be in the long tail that answered “sputnik”?
Use random, domain inappropriate answers for these questions. Store them in your encrypted password file, or (better) in another encrypted file. These questions aren’t ones you need to be able to answer from memory. How often do you *really* need to get into that account from work or your phone right this moment and can’t wait til you get home to look up your password and the answers to your security questions? Very rarely.
Mike,
Another week another exfiltration of user data…
The obvious answer is to raise some kind of alert when certain files get accessed in various ways.
However “the obvious” usuall does not work for many reasons, so perhaps we should be asking more obvious questions such as,
Why do we keep this data on systems that can be accessed? or even on a system in the first place?
When analysed the so called compeling reasons are anything but and can in some cases be attributed to lack of forsight, planning or just plain lazyness at day one with a “quick-n-dirty” solution to get things up becoming a legacy lynch pin.
For instance over on Bruce Schneier’s blog the –almost– annual question of, Why are bad passwords and their systems still with us? Came up. With as normal the usual responses of “my password generation/memorisation trick is…” and the real questions of why? not how were largely left unasked.
So I pointed out a couple of issues that don’t normaly get talked about and got a couple of responses which to be honest I rate as a success…
https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html#c4835896
As always a brilliant response. Somehow there needs to be some education that while security engineering by definition will decrease usability, it is a necessary evil to protect the user and that we – the security techs responsible aren’t just evil BOFHs who insist on putting pointless roadblocks in front of them to reduce productivity (one receptionist I dealt with repeatedly at one of my first security consultancy jobs years back kept noting credentials under the keyboard on a post it note)
During the AIDS scare of the 1980s people openly opined on why they wouldn’t use a condom and the bulk of their reasons were complete bunk. I guess in their mind the convenience threshold wasn’t crossed yet.
In closing …. People are stupid. The end. 🙂
PS: my apologies for not being very active both on here and on schneier.com. Have been busy to the point of exhaustion and then had some family issues (extended family is a dirty word around here at the moment) on top of that. I will be back on board soon enough.