Schneier on Security
A blog covering security and security technology.
« HOWLERMONKEY: NSA Exploit of the Day |
| IRATEMONK: NSA Exploit of the Day »
January 31, 2014
Another Credit-Card-as-Authentication Hack
This is a pretty impressive social engineering story: an attacker compromised someone's GoDaddy domain registration in order to change his e-mail address and steal his Twitter handle. It's a complicated attack.
My claim was refused because I am not the "current registrant." GoDaddy asked the attacker if it was ok to change account information, while they didn't bother asking me if it was ok when the attacker did it.
It's hard to decide what's more shocking, the fact that PayPal gave the attacker the last four digits of my credit card number over the phone, or that GoDaddy accepted it as verification.
The misuse of credit card numbers as authentication is also how Matt Honan got hacked.
Posted on January 31, 2014 at 6:16 AM
• 18 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
I think it is absurd that credit card numbers and SSNs are ever treated as any sort of secret. Pretending we are going to safeguard information that we have to give to hundreds of different organizations in a year is crazy. I have to give my SSN to every employer, landlord, medical institution, bank, credit card company, government agency, and so on. Yet this is supposed to remain a secret? That's never going to happen. All the talk of encrypt this and secure that is ultimately going to be futile. The cost of thousands of organizations all doing things properly is just too high, and the probability of them all doing it properly is near zero. The technology exists to eliminate this issue, the problem is the overall level of fraud is too low to motivate us to change the system.
Mother's maiden name, birth town, high school name, favorite teacher, etc. all only provide a tiny shred of security. Do they even get one bit's worth?
At least with Bitcoin you have the option of digitally signing a message, and you don't have to give out any personal information to anyone.
Looking forward to its mainstream use.
This really is just another example of the economics of authentication. Most of us who actually deal with domain registration on a regular basis know how to make a strong password, and keep it safe, so we have no need for this "Credit card authorization" stuff. But sites like GoDaddy have to cater to the masses of folks who have no idea how a computer works, who see an ad during the superbowl or nascar race that tells them how _easy_ and _cheap_ it is for them to buy www.mybusiness.com, and have a website running in _minutes_. 6 months, 12 months, 4 years later, they decide that they want to make some changes, or renew their domain, and suddenly they have no idea what password they used. Was it "Fluffy123"? Was it "monkey"? They call support, and _demand_ that they give them access. The only information that GoDaddy has is the last 4 on the credit card, their address (which is most likely also on the whois record), and their email account (likely some @hotmail.com account that they stopped checking, or started outright _blocking_ all corrospondence from GoDaddy anyways). So what is GoDaddy to do? They want to get paid. What happens if Joe the Plumber starts angrily promoting the notion that GoDaddy has the _worst service ever_? They can't have that. 99% of the time, this works out just fine. Nobody cares to gain control over 99% of domains, so they stay untouched. And thus, this security breach is born.
Perhaps a better description is that they used information available to both parties and lots of others as well? CC numbers (like SSNs, as Jeff points out; and like all those things Bryan points out) are given to lots of parties, not just two.
The trick is that there's no perfect solution to the threat of forgotten passwords. I believe the best solution if delays are acceptable involves active social authentication, where people appoint trustees who assist in getting their passwords back. (As in "It's not what you know, but who you know" by Schecter, Egelman and Reeder, http://research.microsoft.com/apps/pubs/...
Thanks for that link Adam, looks interesting. Your closing parentheses breaks the link, for me at least, so here's a duplicate.
Glad you gave this more publicity. I wonder what will twitter do after this, I think they have to give back the account to the original owner ASAP, and maybe make a public statement about how they react tho this kind of stortion for future events.
@ Brian M
Excellent analysis. A few speculated the RSA token database's existence had the same root cause. Existed for support reasons, was easily accessible for support reasons, and was hacked. I'm sure NSA benefited from it but I doubt it was created for that. Regular business incentives & habits seem to explain both problems.
What I'm amazed by is not just the ease of impersonating people (which is a known problem), but more importantly the difficulty of confirming your identity after the imposters take control of your accounts.
I don't really see a good solution, either, at least not one that works with the aforementioned angry customer. Making "proving" identities easy while impersonating identities difficult is near impossible today.
One would think that the communication chain, possibly cross-checked against Twitter account notes, would be enough to give N back his Twitter handle.
Someone this sophisticated probably can't be tracked from the account info, unfortunately.
Two things that came up in the comments to TheRegister's
article on this:
1) Why could GoDaddy not confirm his "security answers", which the thief had changed, against backed-up previous values?
Having these in the clear would be bogus, but no _more_ bogus than having the _current_ values in the clear, and if they store hashes, they can back up hashes. Revision Control FTW!
2) Are we sure the situation is as described, as opposed to a _prospective_ thief causing enough of a ruckus that Twitter will hand over the handle to him, taking it away from the actual owner (his alleged thief)?
Authentication is hard, let's go phishing!
It's reasonable to give out the last 4digits of the cc ( although giving out any information is never a good idea)
The rule is that the last 4 digits AREN't secret, the rest are normally obscured.
So accepting these as proof of the card is the equivalent of asking for somebody's PUBLIC key as proof of who they are
If you have the last 4 digits of the credit card, and you can figure the first few through the card-type, how many digits are left?
How many credit card numbers do you need to be able to guess the remaining missing numbers and hit a reasonable number of matches?
What about physical mail? Couldn't they mail you something (a reset code for example) that you could use to call back with to verify your identity? Yes, you get a 1-2 week delay, and in today's world, that is probably not too acceptable.
A more detail analysis of the incident:
Interestingly enough, the official PayPal’s response contradicts the attacker's version. In any case, CC numbers are not suitable for authentication, so GoDaddy is the only one to blame here. But then as Brian M correctly noticed, GoDaddy tries to cater to the needs of folks who have no idea how a computer works. Still some other companies offer additional security features, which can be enabled by those who understands more than Joe the Plumber and can tolerate extra inconvenience for a bit more security.
Credit card numbers as "authentication"? How stupid is that?
First, this is shared-secret "authentication", something that is known to be fundamentally flawed. And second, it is globally "shared secret" "authentication", as anybody you aver paid with your card has the number.
I think this qualifies as gross negligence and should make anybody that relies on this fully responsible for any and all damage caused.
The truly shocking part of this story is that someone is still using GoDaddy. They're abusive and terrible people. Stop handing them money!
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.