Yet Another Risk of Storing Everything in the Cloud

A hacker can social-engineer his way into your cloud storage and delete everything you have.

It turns out, a billing address and the last four digits of a credit card number are the only two pieces of information anyone needs to get into your iCloud account. Once supplied, Apple will issue a temporary password, and that password grants access to iCloud.

Apple tech support confirmed to me twice over the weekend that all you need to access someone’s AppleID is the associated e-mail address, a credit card number, the billing address, and the last four digits of a credit card on file.

Here’s how a hacker gets that information.

First you call Amazon and tell them you are the account holder, and want to add a credit card number to the account. All you need is the name on the account, an associated e-mail address, and the billing address. Amazon then allows you to input a new credit card. (Wired used a bogus credit card number from a website that generates fake card numbers that conform with the industry’s published self-check algorithm.) Then you hang up.

Next you call back, and tell Amazon that you’ve lost access to your account. Upon providing a name, billing address, and the new credit card number you gave the company on the prior call, Amazon will allow you to add a new e-mail address to the account. From here, you go to the Amazon website, and send a password reset to the new e-mail account. This allows you to see all the credit cards on file for the account—not the complete numbers, just the last four digits. But, as we know, Apple only needs those last four digits. We asked Amazon to comment on its security policy, but didn’t have anything to share by press time.

And it’s also worth noting that one wouldn’t have to call Amazon to pull this off. Your pizza guy could do the same thing, for example. If you have an AppleID, every time you call Pizza Hut, you’ve giving the 16-year-old on the other end of the line all he needs to take over your entire digital life.

The victim here is a popular technology journalist, so he got a level of tech support that’s not available to most of us. I believe this will increasingly become a problem, and that cloud providers will need better and more automated solutions.

Initial post.

EDITED TO ADD (8/13): Apple has changed its policy and stopped taking password reset requests over the phone, pretty much as a result of this incident.

EDITED TO ADD (8/17): A follow on story about how he recovered all of his data.

Tags: , , ,

Posted on August 8, 2012 at 6:31 AM • 66 Comments

Comments

L Forbes • August 8, 2012 6:51 AM

Well this one at least had a good outcome (we don’t know yet whether he’ll retrieve his digital property), but there are now several articles reporting that both Amazon and Apple have beefed up their policies with respect to phone-up alterations to accounts.
Well overdue. BAD boys both of them, and Phobias et al

Reader • August 8, 2012 6:56 AM

Cloud or not, bad password/access reset processes give access to those who shouldn’t have…

TheLastWilson • August 8, 2012 7:01 AM

I can’t help but feel reminded of the Sony playstation network hack in that it should be a big wake up call to increase security weight in the security vs convenience see-saw

Marti Raudsepp • August 8, 2012 7:19 AM

@L Forbes

we don’t know yet whether he’ll retrieve his digital property

The answer is an almost certain “yes”. Quoting the article:

When you perform a remote hard drive wipe on Find my Mac, the system asks you to create a four-digit PIN so that the process can be reversed

Even if iCloud doesn’t store this PIN code in the cloud, and even if the attacker didn’t divulge the PIN code to the victim, a four-digit PIN contains so little entropy that it can always be cracked.

Joe White • August 8, 2012 7:21 AM

That first snippet is misleading — it says all someone needs is the billing address and last four digits of the credit card number. But everywhere else in the story, including the second snippet, he makes it pretty clear that you also need the e-mail address. He also ignores this little detail when he says the pizza guy can take over your digital life — he couldn’t, not without your e-mail address.

Mmmmm Pizza • August 8, 2012 7:37 AM

@Joe White
I don’t know about Pizza Hut, but the Papa Johns chain uses your email address as the userid to their website. So I think the generalization of the ‘pizza guy’ taking over your digital life isn’t really far-fetched.

Hugo • August 8, 2012 7:45 AM

@Marti Raudsepp the remote wipe process will overwrite the data on the harddisk with garbage so the answer is NOT an almost certain “yes” but he does describe that the wipe process had not yet begun but the delete has been done so data recovery on the harddisk could still retrieve most of the data if the drive is removed and special tools are used but even a simple bootup will write cache files all over the “deleted” data (it’s probably a good thing he didn’t have an SSD because the wipe (actual full erase without any possibility of recovery) on those is done in seconds.

Paeniteo • August 8, 2012 7:45 AM

“will need better and more automated solutions”

Not sure that “more automagic” is the key to success here.

It would not have made a difference if we replace “phoned Amazon” by “filled out a web form at amazon.com” in the story above.
The attack precisely targets the (inevitable) point where the automated processes are unable to handle the issue.

John • August 8, 2012 7:48 AM

I’m confused about why he didn’t take his Mac and other devices offline as soon as he realized what was happening. He clearly had time.

Hugo • August 8, 2012 8:11 AM

It amazes me that people “in the industry” take such a laid back attitude to security.
I use LastPass (after extensive research into how it works) with current technology (and as far into the future as I can foresee) my passwords are safe in that vault (which is only ever decrypted locally!), my access password is very strong and I use 2 factor authentication. Using that has allowed me to have unique passwords everywhere (over 300 passwords in my vault) and those passwords are also strong, average 25chars, some over 100chars just for the fun of it.
The only other password that I choose to remember is my Google account which is also very strong and 2 factor.
I never liked those “security questions” or other password retrieval options, either I’ll remember my password or I’ll reset it to my secure email address, don’t bother me with pet names or my mother.

Jeff Hotchkiss • August 8, 2012 8:15 AM

Whenever the company I work at is called upon to implement any web service, because we’re quite a large one with fun clients like the US Defence Department, we get lots of questions about SAS-70, SSAE 16 and other such standards.

What I’d be interested to know is if any of those audits check such things as password recovery policies, and whether we should be at least suggesting that those compliance checks be beefed up. It won’t solve any circumstance where no audits happen at all, but I’m sure the likes of Apple & Amazon both claim compliance to such standards.

nonegiven • August 8, 2012 8:29 AM

His first inkling that something was wrong was when his iPhone lit up as it was wiped. Sounded like it took about 20 minutes from resetting his email password to completely wiping all his iStuff.

Hugo • August 8, 2012 8:30 AM

@Jackson you just have to make sure that the clock on your device is correct.
I know from experience that there is a tolerance of a few minutes but then the codes on different devices will be different and they should be the same, for backup I have 2 android phones with Google Authenticator

Joe D • August 8, 2012 8:35 AM

The other thing to take away from this is BACK UP YOUR STUFF.

If you’ve only got one copy of something, it is not backed up. Even if that one copy is out in the cloud somewhere, it is still not backed up.

Keep your own set of local backups for everything.

SilverLining? • August 8, 2012 8:36 AM

If he’s not able to recover his data, at least we know that the “deletion” was actually a deletion.

cloudless • August 8, 2012 9:29 AM

@Joe D

I agree. Backup everything locally to 2 hard drives, and burn it to CD/DVD.

stvs • August 8, 2012 9:37 AM

Cloud technology is great, but only if you run your own personal cloud. BS asked about online privacy practices in a recent post. Another one: the nice lock/wipe security features of “Find My Mac” can be had without opening yourself up to corporate breaches using Profile Manager for iOS/android devices.

Privacy and security are both enhanced if you treat all your devices as if they are disposable and controlled in a private enterprise environment. Hit the wipe button at the first snafu and retreat to backups.

tetracycloide • August 8, 2012 9:42 AM

Wasn’t there just an article here but a few days ago about how we, as human beings, irrationally look at specific, uncommon situations like this and assume they’re common?

That said, password recovery has seemed like the biggest loophole in every form of internet hosted service since their inception.

stvs • August 8, 2012 9:46 AM

Technical questions about remote wiping/locking capability in “Find My Mac” and equivalents: I presume this does not securely lock or wipe the hard drive (e.g. cat /dev/urandom > /tmp/junk.dat) and anyone with physical access to an unencrypted drive can just read the sectors and pull off whatever is there. Is this true?

Ditto for WDE (FV2) drives if you have the keys?

Robert • August 8, 2012 9:49 AM

@Mmmmm Pizza,

If you’re ordering online and paying with a credit card, then the kid delivering the pizza doesn’t need your email or credit card info.

Also, anyone who uses their primary email for signing up for stuff like that probably deserves what they get. Doesn’t everyone have a spam-sink email for that purpose? It’s not an email that’s required for this hack; it’s specifically the AppleID.

Robin Boulton • August 8, 2012 10:38 AM

I’d like to know if Google and Microsoft’s cloud offerings suffer from similar weaknesses.

dragonfrog • August 8, 2012 10:43 AM

@stvs

“I presume this does not securely lock or wipe the hard drive”

So, you presume Apple is knowingly engaging in false advertising? That seems unlikely to me.

There may well be some caveats to the process, its duration, or ways of interrupting it midway through (modern HDDs are huge- if the disk is unencrypted to begin with, and you know to power down the computer as soon as you notice the wipe process start, you could probably salvage a lot of data)

Scott • August 8, 2012 10:44 AM

Remote wipe in iOS is irreversible if the device had a PIN or Passphrase because the process simply shreds the hardware-based decryption keys and powers down the device. Game over.

rzdw92 • August 8, 2012 11:11 AM

If you want to use Google’s two-factor authentication and you have a mobile device with apps that need to sign in to your Google account, you pretty much are forced to use application-specific passwords (because most mobile apps are not compatible with two-factor authentication).

So my question is: once you have at least one application-specific password, doesn’t this undermine the whole two-factor thing? How is an application-specific password any more secure than normal authentication with a single strong password? I know you can revoke Google’s application-specific passwords, but this would break your mobile apps that are using them. Additionally, wouldn’t using more than one application-specific password compromise your security even more? It’s like you’re generating more keys that will open the door.

dragonfrog • August 8, 2012 11:12 AM

@stvs

Typically, encrypted copies of the disk encryption key is written in the first sectors of the HDD, each copy encrypted with a passphrase. You don’t know the key – you know a passphrase that encrypts the key.

Disk wipe processes typically start at the first sector – within a second or of starting the disk wipe process, all on-disk copies of the key are likely gone. Your knowledge of a passphrase is made useless, and the encrypted data is already as good as wiped.

dragonfrog • August 8, 2012 11:36 AM

@rzdw92

You’re right, application-specific passwords are something of a compromise.

The idea is, they get better protection than your regular password in that
– you don’t remember them so you can’t be tricked into typing them into a phishing form
– you don’t enter them on a computer other than your own (i.e. less trusted)
– depending on the application they’re for, you enter them into an OS that’s less prone to malware than average (i.e. a smartphone OS rather than a general-purpose PC OS)

The standard web password, lacking all of the above protections, is given further protection of two-factor authentication

J. Peterson • August 8, 2012 12:03 PM

While enabling remote wipe for his laptop was pretty bad, not having any backup at all is just as stupid. Hard to blame the “cloud” for this, as the data he lost was local. A disk failure would have been nearly as devastating.

Mmmmm Pizza • August 8, 2012 12:11 PM

@Robert,

If you’re ordering online and paying with a credit card, then the kid delivering the pizza doesn’t need your email or credit card info.

Yes, he doesn’t need that info, but I guarantee that a company connected computer is back at the restaurant, so it it available to him? A security related question concerning the company’s internal systems. Besides, receipts frequently have the last four digits of the credit card and that was a key component of this social hack.

Also, anyone who uses their primary email for signing up for stuff like that probably deserves what they get.

Bit of a harsh viewpoint, IMO, but it does have some validity. One should take responsibility for one’s actions and behaviors.

Doesn’t everyone have a spam-sink email for that purpose?

Nope, certainly not among the general populace.

It’s not an email that’s required for this hack; it’s specifically the AppleID.

A key component to this social hack was using the email address to gain access to the AppleID. Knowing the billing address was another key component – and he probably just dropped a pizza off at that location.

I stand by my previous assertion that the ‘pizza guy’ (movie?) scenario is not far-fetched.

rzdw92 • August 8, 2012 12:19 PM

I looked into Google’s application-specific passwords a little further and it looks like the real answer is that they have limited privileges (although Google doesn’t specify what).

If they are compromised, the thief can only use them to perform limited functions. Which is bad enough, but they apparently cannot be used to change the Google account password or do other administrative tasks.

boog • August 8, 2012 12:44 PM

I’ve been concerned for years now about the use of the Last 4 Digits (of anything) as a form of authentication.

Just a week ago, I managed to lock myself out of my bank’s website by forgetting the answers to my security questions (I only have to answer them when I log in from a different computer or clear my cookies, I couldn’t find where I’d written them down, and yes, while I provided the correct password they still locked me out because I couldn’t tell them what my favorite movie, song, TV show, etc. were).

So I sent them an email asking them to unlock it. But in addition to unlocking my account, they reset my password to the Last 4 Digits of my SSN. I hadn’t forgot my password, so why did they reset it? And to something that could be so easily acquired? I didn’t even send my “please unlock” email from the address they had on file. I guess some companies just make social engineering too easy.

So I sent another email pointing out the dangers of doing business that way, but never heard back.

posedge clock • August 8, 2012 12:51 PM

What’s as bad as poor security practices is that some cloud providers have no fallback in case you are hacked.

My employer recently accidentally canceled a virtual server account with a well-known provider of hosting services. (Yes, accidental. That alone would make a great user interface story.)

We found out within two hours when the server in question failed to respond. We immediately called the hosting provider for support.

Too late.

Even though the provider sends out an email to the effect that “if this is in error please call us immediately” there is no recourse.

Not only was our server immediately halted and wiped (to be expected), but the backups (stored on a different machine with the same hosting provider) were immediately wiped as well. No recovery was possible.

This, despite the fact that the hosting contract was for a year, that there was unused time on the contract, and that unused time will not be refunded in the event of cancellation. Fair enough – you get a discount for committing to a year and you should not be able to renege on that. However, in return, I would have appreciated the provider keeping the backups for the remainder of the year. Hell, even for just a week.

We would have gladly paid any “recovery fee” the provider wanted simply to get access to the backups.

Admittedly, the accidental deletion was our own fault. However, if a hacker had obtained the admin password for the hosting service, he could just as easily have “canceled” our account. And we would have zero recourse.

Anything in the cloud is not backed up unless the backup is on a device in your physical possession. At which point there is not much point being in the cloud.

ojiikun • August 8, 2012 1:05 PM

It should be pointed out that, like Google, Amazon’s cloud (but not their retail accounts) offers 2FA/MFA for login and API access.

They have for some time, too. The tools are out there; people just need to start using them. This guy even admits at the start of his story he knew he should have done it but didn’t. No sympathy.

Confused • August 8, 2012 1:11 PM

Why is this so hard?

Billing addresses are not secret, because if they were you would not be able to get your bills.

Email addresses are not secret, because if they were you would not get any email.

Credit card numbers are not secret, because if they were you would not be able to charge anything.

Why does anybody treat these non-secrets as secrets? Why is anybody posting on this blog that users should keep these non-secrets secret?

Kevin Marks • August 8, 2012 1:12 PM

You have it backwards. If he’d used the cloud he’d have remote backups.
The real problem here is the remote wipe, which is a feature demanded by enterprise it departments for byod support. Their threat model is that a stolen laptop leaking company data is worse than data loss from accidental erasure.
For Mobile Phones this makes some sense for individuals too, as they are backer up by default these days. For laptops, less so.

Les • August 8, 2012 1:21 PM

Isn’t the real problem the fact that he relied on a single logon to secure his phone, laptop and tablet?

That’s a lot of eggs in the same basket, and a lot of trust in a single vendor.

Doug D • August 8, 2012 1:37 PM

This whole kerfuffle reminds me of how annoyed I am at email providers and service providers who do not consider email subaddresses to be valid.

An awful lot of mail systems will deliver “foo+bar@baz.com” to the same inbox as “foo@baz.com”, regardless of what string is in “bar”. But some email services won’t, and some service providers will reject addresses in this form.

If we could rely on subaddressing support, it would be considerably easier to use a different email address with every single service provider. That way, even if you only have one true email account, the one you have on file with the pizza guy won’t match the one on file with Apple.

(Myself, I “solve” this issue by owning my own domain and hosting my mail servers in my basement, which lets me create and destroy email addresses with pretty much no restrictions and a lot of control. But, I recognize that almost nobody else, percentage-wise, is willing to go that far.)

Clive Robinson • August 8, 2012 2:11 PM

The real issue is not what he did or others did or did not do to get at his account, the real issue is that he thought his data was his and the service provider assumed that the storage of that data was theirs.

That is there is a mismatch of expectations to the user the data was property of tangible use and benifit, to the service provider it was worthless bits occuping valuable space on wht they regarded as “their storage”. It was imeterial to the service provider where the storage actually was it was the provission of the service that counted not the utility of the data…

This “mismatch” will continue as long as users don’t read and understand the service provision/agreement and then mitigate accordingly if they cannot find a service provider who meeets both their requirments and expectations.

Worse nearly all service level agreements at the lower end of this sort of provision have a get out clause of “for technical reasons” and thus the service provider can do very much what they want to.

The fact that this service provider also did not perform adiquate authentication etc is another issues on top.

The key lesson is Your data is only yours if you take the required steps of ownership which begs the question of “why cloud?” and the stupid answer currently is “because it’s sexy”.

Robert • August 8, 2012 3:26 PM

@Mmmmm Pizza,

“A key component to this social hack was using the email address to gain access to the AppleID. Knowing the billing address was another key component – and he probably just dropped a pizza off at that location.”

The email address is the AppleID. The hacker guessed that his @me.com email was his AppleID. If he’d used a different email as his AppleID, their guess would have failed. (My AppleID is an address that is never actually used for email; it just forwards to another account. No amount of social engineering will unlock an account that can’t be identified.)

@rzdw92,

There’s actually a flaw with the GMail device passwords; they’re not actually tied to a specific device, they just appear to be. That is, you can set up a password for your phone, and another for your desktop client, but they’re interchangeable. You only need one device password, which you can use on all your devices. This makes it far less secure than it could be, or appears to be.

The advantage of the device passwords is that the GMail web interface is the most vulnerable. You never have to enter your device password into a web browser or an untrusted computer, and if it is compromised it is of limited utility. It can’t be used to log in via the web interface, and it’s only through the GMail site that passwords can be changed, server-side forwarding set up, etc. The hacker could use a desktop client to read and send emails, but any emails they send will have their sending IP logged in the header.

The 2FA and device passwords is a compromise, but it overall adds security over a single password.

pipTheGeek • August 8, 2012 3:56 PM

I am constantly amazed at just how poorly thought out some password reset systems are.
For example, Barclaycard allow reset of both username and password using only the information from the credit card! So if someone steals my card they can not only use it, but then login to site and use my saved debit card to pay their bill!

Roman • August 8, 2012 3:59 PM

Instead of blaming the user and pimping Google’s 2fa, people who comment on this story should think about more fundamental issues that allowed this hack to get out of control: broken password resets, lack of vertical isolation, security outsourcing.

  1. Password resets should be more, not less secure than normal logins.

  2. Tying many important services to a single account is a bad idea. think about it this way: if one person hacks your email, and then another person hacks your phone, the damage will be much more limited than if the same person simultaneously hacks both.

  3. Exporting security (e.g. completely trusting user’s email provider for password resets) is a bad idea.

Bob T • August 8, 2012 4:12 PM

Cloud schmoud. To an uninformed user it might seem like some nebulous cloud that their devices sync with. To the hacker it’s just another 3rd party data store. The term cloud just gives a misleading false sense of security.

And is it really hacking when a dufus Apple worker doesn’t follow the rules and voluntarily gives out information because, some sweet talker says he forgot what he used on his security questions? That’s called a con-man and a mark.

When the mark doesn’t initially know they are giving out information, then it’s hacking.

Bob T • August 8, 2012 4:17 PM

And anybody who has their passwords and account numbers in their iCloud synced notes on their iPhone and iPad are depending on the same human incompetence as exhibited by the Apple employee to not have those other accounts wiped out or worse.

Perseid • August 8, 2012 4:32 PM

“””The email address is the AppleID. The hacker guessed that his @me.com email was his AppleID. If he’d used a different email as his AppleID, their guess would have failed. (My AppleID is an address that is never actually used for email; it just forwards to another account. No amount of social engineering will unlock an account that can’t be identified.)”””
@Robert:
So you’re saying additionally to the password the username should be a secret, too? That breaks a lot UI expectations.

MingoV • August 8, 2012 4:36 PM

Plenty of blame to go around.

Tech journalist: Had his head in the clouds: his entire life was on his laptop, but he had not backed up to accessible media (hard drive or optical disks) in over a year.

Amazon.com: Should not allow telephone changes to an account unless the call is made from the phone number associated with the account AND the caller answers non-trivial security questions.

Apple: Violated its telephone security policies.

Google: Encourages users to link everything possible to their e-mail accounts, but makes it too easy to hijack an account unless the user chooses phone-based authorization. (My Google e-mail account has nothing linked to it: no other e-mail addresses, no phone numbers, no social media accounts, etc.)

foosion • August 8, 2012 7:22 PM

Apple: Violated its telephone security policies.

Wired says it was able to reproduce the problem, it’s far from clear that Apple wasn’t following its standard practice.

Robert • August 8, 2012 7:23 PM

@Perseid

Why need does any other site have to know what your AppleID is? There’s no need to expose that information.

I’m just saying that an account is harder to hack if the hacker doesn’t have the userid or password than if he’s just missing the password. I think that’s fairly self-evident, no?

In this case, the hacker was trying to gain access to the victim’s Twitter account. That led to an attack on the GMail account (which they found via his home page, linked from the Twitter account). The GMail account was set to send password recovery messages to a @me.com email. The hacker guessed that that @me.com email was also the victim’s AppleID and went after the Amazon account to get the credit card information that he needed to exploit the Apple customer support person.

Break any link in that chain, and the hack doesn’t work. If the GMail account on the home page was a different one from the one linked to Twitter, if he used something other than the @me.com email for his AppleID, if he had 2FA on the GMail account, if he didn’t have the same credit card on file with Amazon and Apple.

Amazon and Apple were both lax with their security (which has probably helped more people than it’s hurt, but the people who’ve been hurt have been hurt a lot), but so was the victim. The lack of backups alone is enough to erase any sympathy I might have had for him. If you don’t have it backed up, it’s not anything you care about.

Godel • August 8, 2012 7:39 PM

@Bob T

The Apple employee DID follow Apple guide lines. The email address and last 4 digits of the credit card were enough to provide identification.

Leolo • August 8, 2012 9:38 PM

The problem is that Apple thinks the last 4 digits of a credit card are a valid authentication token, but pretty much everyone else doesn’t and shows it in various scenarios.

It might have been better for Apple to require all the credit card number and compare its hash to a hash of the known credit cards in a DB available to the support personnel.

Zaphod • August 8, 2012 10:37 PM

So, what’s a good password reset policy for outfits without the resources to implement something like G2FA?

Z

jake • August 9, 2012 4:29 AM

most online backup/storage providers are clowns when it comes to security.

the ease with which email addresses and web logins can be compromised should be reflected in storage providers’ processes for granting access to accounts in this manner. is it really that hard to request a full CC number and associated information over the phone then have someone check that the card actually bills correctly through their CC gateway interface?

storing your data in the cloud in an unencrypted format is also something i’d not recommend since in addition to it getting deleted the attacker may very well have a copy of it.

check out cyphertite if you’re interested in online data storage with people who care about security.

Anderer Gregor • August 9, 2012 4:46 AM

Although I still consider Apple using the last four CC digits as authentifying information the main problem here: Why did Amazon take a unverified CC number that had been entered just a few hours (or minutes) ago to be an authentification instead of a sure sign that something sinister is going on? Don’t they even see in the call center if some of the information had been changed recently?

A, say, 2 weeks quarantine on information that had been changed in a potential unsafe setting would certainly not make these kind of hacks impossible, but they would take much more patience, and increase the risk of them being uncovered (provided, of course, there is something who I can call when I find a CC number I have never seen before listed in my Amazon account …)

Jeff H • August 9, 2012 5:28 AM

Personally I’d never allow user IDs to directly be email addresses, or allow major account changes over the phone. Note that a lot of this described attack was via phone calls. If all else fails (e.g. main email address is claimed to be bust), mail (as in the posted letter variety) the user about changes, or call them back on their existing registered phone number, and handle changes of those with some verification via the old registered information. Actual password recovery is pretty rare vs, say, account unlocking.

@Zaphod – At the risk of going off-topic, I’d start by asking if you need to handle passwords at all. If you can get users to sign in via someone else’s OAuth/OpenID (like Google themselves) then you’ve delegated most of your security problem to someone else with probably much more resources. Equally, why not use an existing 2FA module (e.g. Google Authenticator)? Other than that, password reset isn’t far removed from any other challenge of authentication & identification.

Roger • August 9, 2012 7:07 AM

There are numeorus “WTFs” in this incident, ranging from Honan’s own laziness and naivete, to laughably poor security policies by both Apple and Amazon (and also Google, although their failings were tiny compared to the other two.)

But what really surprises me are the commenters who see nothing wrong with using knowledge of a credit card number as an authenticator! It doesn’t make any difference whether they use the last 4 digits, the first 4 digits, the whole number or a hash: CREDIT CARD NUMBERS ARE NOT SECRETS!!

The credit card number is provided (generally to strangers) every time you make a purchase, on-line or off-line. Not just to one merchant; all of them! Most people have absolutely no idea how many copies are floating around. Plus, it is stamped on the front of the card, and exposed every time you open your wallet. It is straightforward for family, co-workers and acquaintances to discover these numbers. On my accounts, the conditions of use don’t even suggest keeping it confidential.

Because this archaic protocol works so badly on-line, we keep seeing attempts to treat credit card numbers as secrets. And just as in this case, they always end in disaster.

confused • August 9, 2012 9:35 AM

What roger said.

And the same for names, addresses, email, birthdays, SSN and pets names.

These are not secret; They cannot perform their intended function if they are kept secret. Where did security people get the idea that they could take public information, declare it secret and then blame the user? Hangings too good for them.

boog • August 9, 2012 10:34 AM

@Roger

…using knowledge of a credit card number as an authenticator! It doesn’t make any difference whether they use the last 4 digits…

Certainly not, but I will say that it concerns me (not from a security standpoint, but from a person-with-a-brain standpoint) that the part of the field they use for authentication is the same part they expose whenever masking the field.

Thinking a non-secret field is secret is just ignorant. Exposing part of a field (secret or not) and then treating that part as secret is pure stupidity. As someone who has a brain, I’m concerned that so many people who clearly have no brains are in charge of securing my money, data, identity, etc.

Roman • August 9, 2012 11:55 AM

@Jeff H

The guy was screwed over because he had entrusted large chunk of his digital life to just a couple of entities and because many websites he used outsourced security of account resets to a third party (his email providers). So what are you proposing as a response? Centralize everything even further! Outsource all security! That is bad advice.

Sure, 2fa would have stopped a part of this hacking rampage. But so would a lot of other measures, and many of them have much fewer side-effects.

Julien Couvreur • August 9, 2012 12:39 PM

Given the difficulty of authenticating people online for various recovery scenarios (lost password, hijacked account, etc.) I am surprised not to see brick and mortar solutions emerge.

For example, you could imagine Apple taking advantage of its physical presence (Apple Stores) to strengthen it’s authentication solution.

As Bruce pointed out in his video on identification and ID security, identification is a system and only a part of the broader system of security: http://www.youtube.com/watch?v=dy4VJP-lZpA

Why should we have two separate sets of solutions for related problems in the offline and online space?

vexorian • August 10, 2012 10:50 PM

“Application-specific” passwords can’t really be application-specific. Because google would need to somehow make the application support their verification system so that they can identify the app. But if they could do that, then it would be as easy to use the 2-factor verification on that app and the app specific password wouldn’t be needed.

2fa does not really have that many side effects, unless I guess you travel a lot and have to constantly rely on public computers.

and also Google, although their failings were tiny compared to the other two.)”

What exactly did google did wrong (in this specific case)? The hackers entered the google account because they controlled the apple email account that was used for recovery. Recovery email accounts are bad design, but that’s why google revamped things to use 2fa. But if the user did not enable 2fa, then what can google do besides letting the recovery email address work?

Vexorian • August 10, 2012 10:57 PM

The problem is that Apple thinks the last 4 digits of a credit card are a valid authentication token,

I found this hard to believe because every service in which I used a card keeps telling me the last four numbers of my card constantly. As means of letting me identify the card without giving me the whole number.

John U • August 16, 2012 3:58 AM

Good to see Wired grasping the inititative by rolling out a load of questionable advice on “how to avoid ending up like Mat”…

Jeff H • August 16, 2012 4:01 AM

@Roman You seem to be taking my advice a touch out of context. Zaphod strongly implies in their query that they won’t/can’t implement security well due to resource issues. In that case, outsourcing it makes sense. Outsourcing it does not automatically translate to outsourcing it to idiots you wouldn’t trust with a toothbrush.

Your alternative appears to imply that everyone everywhere should invent their own password storage, their own password reset system, etc., and time and time again, history has shown us that this is usually done on a budget, badly, and not sufficiently peer reviewed by people who actually know anything about security. A good article on password resets aptly demonstrates all of what a good site must do. Is that a better ideal? I would say no.

Possibly this is a tension between the security field and the software field. The advice in the software field is ‘never reinvent the wheel’. When it comes to security, that means don’t write your own, especially if you lack the resources to do it properly. If there are good frameworks out there that do it for you that aren’t OAuth & OpenID, let’s hear them, but advice of ‘do it yourself, do it right’ just isn’t going to cut it in my view. It certainly hasn’t worked.

Barry • August 22, 2012 5:45 AM

@Anderer Gregor: “A, say, 2 weeks quarantine on information that had been changed in a potential unsafe setting would certainly…”
For a new credit card number it’s not a quarantine that’s needed but a successful purchase. That would at least ensure that the card has been truly verified with its issuer.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.