Unresolved Issues Swirl Around Securing Mobile Payments

CowboyRobot writes "While many mobile payments startups are using both traditional and nontraditional authentication methods, regulatory uncertainty still exists around liability for fraud attacks on customers using mobile payments. Although there haven't been any public attacks from fraudsters on alternative mobile payments providers such as Square, LevelUp or Dwolla, anecdotal stories are already circulating among security experts and regulators of such attacks. One thing that still has to be worked out in this area is regulatory oversight. 'The regulators are not yet clear who owns the regulatory oversight for these environments. These technologies tend to fall through the cracks even in terms of card-present or card-not-present.'"

Comments

Phones

[girlintraining]

Phones aren't secure because most people don't put a password on them, and any app you run for mobile payments on top of that can be hacked, since once you have physical access to the phone, you're pretty well doomed.

Just stick with the damn cards. If you lose it, your bank will send you a free replacement, and it's instantly disabled. The same cannot be said for access to your accounts with your phone, for which you will not receive a free replacement, and you may have to close your account since unlike a card, your login, password, social security number, date of birth, access to e-mail account, oh... and probably the phone number the bank would call you back at to verify your identity... are now all in the hands of the criminal.

Re:Phones

[mlts]

The ironic thing is that this can be easily addressed.

All modern ARM chips have the ability to run multiple "worlds", one secure, one insecure. It would be nice to have the ability to have a secure world just for credit card payments, having it use two forms of authentication on that app (face, fingerprint, and/or PIN.) Then, the other world would have the usual phone apps. This way, even if a thief gets the phone and it is unlocked, the critical banking stuff is protected at a low level, and too many guesses at the PIN will result in the partition with the Square or PayPal app getting erased.

On a more general level, it would allow a device to have one partition for work stuff, one for home.

Re:Phones

[Roogna]

Heck, I would LOVE to see 3 security settings. I keep my phone locked with a reasonable length password, but there's a definite tradeoff between security and convenience. I've wondered for ages why I can't actually have 3 settings:

Apps that are accessible no matter what with no password or anything. I mean honestly, I don't even care if someone uses the calculator on my phone. There's a number of apps I'd drop in here for use at any time.

Apps that require a simple pin. I for instance would put apps that require data usage in this, but don't actually have personal data. But don't need anyone who potentially gets ahold of my phone wasting my battery on burning through costly minutes/data without at least some effort (A pin would slow them down enough that if it was actually stolen I could very likely have already noticed and erased the phone), Turning the phone off and on should also require this at a minimum.

Apps that require a strong password. Banking apps, the web browser, anything that I feel contains personal data. Most of these apps probably also contain their own strong password requirements, and I don't mind having to enter a password to get to the app, to enter a password to verify the service.

While there'd be something to be said for more levels than this, I'd say 3 is something that pretty much anyone could wrap their heads around with a minimal amount of instruction if needed.

Re:Phones

[jbmartin6]

I would love to see this as well. It is ridiculous that I can't make an outbound call while driving without having to risk death by unlocking the phone first. Yes, I know iPhone allows this. Anyway, this shouldn't be too far off the map there are apps already that provide a sandbox for corporate environments. Seems like what you describe isn't too far off that path.

Re:Phones

[Synerg1y]

You mean like Linux's SU system? lol On Android the backbone exists, but it hasn't been implemented for this, IOS too I believe. Of course, if payment isolation were to be taken seriously on the android, all the little unlockers / root apps would have to reconsider how they unlock the phone, or at least give a choice to the user.

Re:Phones

[stephanruby]

Just stick with the damn cards. If you lose it, your bank will send you a free replacement, and it's instantly disabled.

So this won't affect Square at all. Square is for accepting payments, by sliding a card through it.

The same goes for LevelUP, LevelUP is the equivalent of keeping a photocopy of your credit card (both front and back) in your wallet. You lose your wallet, you've obviously lost your card.

The only example where things get dicy is this Dwolla payment solution. Dwolla is for account to account transactions (without going through Visa or Mastercard). It's a lot cheaper because of this, but then, you don't have any of the traditional protections for fraud (unless they're spelled out separately specifically in their terms of use, which honestly, I haven't even bothered to read).

Re:Phones

[Shoten]

The ironic thing is that this can be easily addressed.

All modern ARM chips have the ability to run multiple "worlds", one secure, one insecure. It would be nice to have the ability to have a secure world just for credit card payments, having it use two forms of authentication on that app (face, fingerprint, and/or PIN.) Then, the other world would have the usual phone apps. This way, even if a thief gets the phone and it is unlocked, the critical banking stuff is protected at a low level, and too many guesses at the PIN will result in the partition with the Square or PayPal app getting erased.

On a more general level, it would allow a device to have one partition for work stuff, one for home.

This isn't actually so easy, it turns out. You're describing what's called MLS, or Multi-Level Security. The NSA has tried this on servers, on workstations, and most recently on phones. It's incredibly hard and the underlying system ends up either having security flaws or major usability issues, and either situation costs a fortune. They've ended up giving up on doing it for mobile devices; what they ended up with weighed over a pound and cost thousands of dollars per device. There are some features it has that wouldn't apply here...but the MLS challenge still has yet to be solved in a way that satisfies, on any platform. This "partition" you talk about has to be done in the OS, not the chip.

Separating things in the chip isn't even half the battle. What, do you run two instances of the OS? Have two separate storage areas? IOS has sandboxing of applications built in, but half the point of solutions like Square is that they can run on multiple types of devices...what if it's Android? It's not just a matter of telling the chip, "oh, this is that OTHER reality..." and walking away proud. If there's not a sandbox around access...in storage, transmission (remember, devices like Square use the audio jack) or in temporary processing in memory, then you don't have separation.

Re:Phones

[mlts]

Seconded (thirded).

First, I'd like the OS to prompt for a full password on bootup. This ensures that someone expecting they can reset the device ends up not just dealing with a 4 digit PIN, but a much longer passphrase before they can use the device.

Second, app functionality that can be run from the lock screen. This way, I can tinker with the playlist, read from the Cracked app, or look at a calendar. The apps would work in a restricted context there. If I wanted to add an entry, then I'd have to unlock and run the app.

Third, have extended password protection be part of the OS. One can sort of do this with iOS and locking out restrictions, but that then has to be turned off when the app needs to be used, then back on.

Offer options where the protection can be a common PW across all "enhanced security" apps, or each app can have its own separate PIN/password/passphrase. Then, if it is guessed wrong too many times, the app is deleted, and its data overwritten. The OS could even use a volume key similar to TrueCrypt and create loopback mounts with the passphrase unlocking that, and on erase, ensuring the volume key is unrecoverable.

Another feature of selective protection is the ability to remotely just zap those applications with the high security data, but keep everything else. Someone's progress in Angry Birds is less of an issue than the stuff stored in an Exchange mail client or a banking app. It also allows the user to still be able to track the phone via GPS while making sure sensitive data is rendered permanently inaccessible to the would-be thief.

Re:Phones

[davecb]

MLS isn't hard to build the infrastructure for, or hard to use, but to understand it well enough to sysadmin takes a week course with tons of exercises, and really makes your head ache. Been there, did that, ran Trusted Solaris at home. That eventually got repackaged into zones, to simplify it into reasoning about separate virtual machines.

I run zones and SE Linux these days, which is a Trusted system with the levels and categories left out for a simple single-level system with pretty reasonable results.

Alas, to get the security I'd want for fairly basic banking services, you're back into writing proof schemas to figure out if you have your MAC access rules right. That's harder than just sysadmining the darned things. Unless your name is Ron Rivest, don't go there (:-))

--dave

Re:Phones

[Jane Q. Public]

There are far more severe issues.

NFC, for example, was barely off the shelf before a "security researcher" managed to pull usernames and passwords from them, from several feet away, when they weren't even being used.

Using active radio transmission to make payments is just plain a bad idea. Even if it's "near field". Because it's only "near" when the person next door doesn't have a huge antenna pointed at the place of transaction. (Which the researchers did not have or need, by the way. Just an example.)

I agree with you; just use cards. They are perfectly adequate for the job and far more secure.

Re:2 degrees compared to what? And over how long?

[girlintraining]

Dude, wrong article. Next time, check the title in the tab before you click submit. :/

Re:Money is overrated

[Attila Dimedici]

That is an interesting definition of freedom: a society where the organization that replaces government will tell you what you must do and give you what you are allowed to have.

Re:You don't know what communism is.

[Attila Dimedici]

You apparently don't know human nature.

Re:2 degrees compared to what? And over how long?

[Synerg1y]

Epic fail!

Securing IMMOBILE payments is brutally hard!

[davecb]

A recent article in the Communications of the ACM pointed out that the banks have massive expenses securing and paying for failed security in ATM payments, so expect it to be much worse with mobile.

See Simons and Jones, "Internet Voting in the U.S.", CACM October 2012, p 68, "However, banks routinely and quickly replenish funds lost to online fraud in order to maintain public confidence". This was part of a discussion of why voting is claimed to be safe, based on the fallacious assertion that online banking is safe.

--dave

Re:Securing IMMOBILE payments is brutally hard!

[davecb]

That assumes that PCI isn't the standard the banks are using now, and would be capable of cutting their losses (:-))

Summary wrong

[Firehed]

From TFS:

These technologies tend to fall through the cracks even in terms of card-present or card-not-present

The only way to perform a card-present transaction and get the better discount rates and lower fraud liability is to provide the magnetic strip data. Anything typed in is considered card-not-present, even when you type it in when the card is in your hand (otherwise merchants would just lie and get the better rates).

What this brings about is the question of how merchants are verified as the line between consumer and merchant is blurred... there's no significant change in how things are actually processed behind the scenes, no matter how pretty the UI. It's a bunch of cryptic nonsense based on IBM mainframes from the '70s. Ever seen the integration spec on one of those bad boys? It's nasty - to the point where going truly direct requires a PCI-certified dial-up modem or dedicated leased line installed in your locked cage in your datacenter. Thought using a SOAP API sucks? Try translating your ASCII to EBCDIC before sending it over protocols that predate TCP/IP.

Re:Money is overrated

[scared masked man]

Money is not itself contradictory with a communist system: indeed, if you have any luxury or freedom of choice you need money to ensure fairness. Let's imagine you'd like to play the violin, and I'd like to go golfing. How do we decide what golf clubs are equivalent to your violin? Clearly, it is a question of how much work went into making them, and what raw materials were required. As soon as we allocate a relationship between an hour of work and a lump of iron ore or bauxite or wood, we have money. Now imagine I like running instead: all I need are some shoes and time. Does that mean I can work less, since I am using less of other people's work? If you want lessons, do you need to work more to compensate society for the productivity you are consuming?
Even when it comes to essentials like food and housing, unless we all have the same thing or are fed out of common canteens, we run into the barter problem, so money makes it easier to get a fair distribution.

Of course, if there were no freeloaders and everyone were competent and attentive, everyone could work out the value of their consumption and self-regulate to make sure they didn't exceed their fair share, but in practice having fixed tokens or their electronic equivalent is rather simpler and more difficult to cheat.

(You also need money to mediate external trade.)

Phones need professional system administration

[gweihir]

Just like every networked computer, really. The interesting thing is that for phones that could actually have been done, as they are closed system and can be remotely administrated. Turns out, a) the providers are not that competent themselves, b) things like "app stores" are far more important that mere security of a device many people store their whole life on. I also have observed that app developers are typically clueless about security and development environment makes it even harder to secure things properly. (The latter from an evaluation we did that was implemented by developers that really understood what they were doing. Even they had huge security gaps, but at least they knew and understood them.) And no, iOS is not better than Android either.

security through insurance

[mcelrath]

So payment security comes down to insurance and legal liability? Fuck that. Truly secure transactions are well within or means, and have been for decades. I want neither to lose my money, nor to funnel billions to criminals through insurance premiums.

Try again, you jokers.

hint: chip and pin, two factor authentication, and private keys for cardholders are good starting points.

Re:2 degrees compared to what? And over how long?

[ksandom]

Yup. Apparently I are too much awesumz cereal that morning. My bad.