Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Businesses Crime Security The Almighty Buck

Unresolved Issues Swirl Around Securing Mobile Payments 44

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.'"
This discussion has been archived. No new comments can be posted.

Unresolved Issues Swirl Around Securing Mobile Payments

Comments Filter:
  • For anyone else that was curious about this, I found this two links deep [washingtonpost.com]:

    That means it’s becoming increasingly difficult for the world to meet its professed goal of limiting global warming to 2C (3.6F) above pre-industrial levels.

  • Phones (Score:4, Informative)

    by girlintraining ( 1395911 ) on Monday November 19, 2012 @04:46PM (#42032051)

    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.

    • by mlts ( 1038732 ) *

      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 gu

      • by Roogna ( 9643 )

        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

        • 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.
        • by mlts ( 1038732 ) *

          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 unloc

      • 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.
      • by Shoten ( 260439 )

        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 i

        • by davecb ( 6526 )

          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

    • Re:Phones (Score:5, Informative)

      by stephanruby ( 542433 ) on Monday November 19, 2012 @06:07PM (#42033135)

      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 [dwolla.com] 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).

    • 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
  • 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 banki

  • 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 pro

  • 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 p

  • by mcelrath ( 8027 ) on Tuesday November 20, 2012 @02:05AM (#42037591) Homepage

    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.

My sister opened a computer store in Hawaii. She sells C shells down by the seashore.

Working...