Skip to main content

Square & VeriFone, My phone accepts payment cards

Square allows you to turn your phone into a payment card terminal.

Cool. For a mere 2.75% overhead, a merchant can accept credit cards using a free magnetic card reader attached to your phone headset jack. Your customers swipe their card and scribble their signature on your iSplat’s screen, your bank account gets a credit.

The obvious questions: How do you secure a mobile application such that it can safely handle payments? Is your Square enabled phone now covered under some sort of compliance regime?

Square says they are secure, but they’ve loaded lots of weasel language into their User Agreement and Commercial Entity Agreement. (I don’t make a habit of reading merchant agreements though, so their language may be typical for the trade, but the part where they exempt themselves from any liability or damages caused by 3rd party trojans would concern me.)

VeriFone disagrees, claiming that the Square system is vulnerable to rogue mobile apps, and claiming to have (in an hour) written an app to exploit Square. But VeriFone is a competitor and FUD works, so we have to ask – is VeriFone any different? From what I read on their FAQ they encrypt in hardware and only use the phone for transmission of encrypted data, so they might be different. As expected, Square disagrees with VeriFone, but in their CEO’s carefully worded letter, makes no assertion as to the security of their application. 

I’d compare Square’s solution to running a card swipe terminal on the USB port of an ordinary desktop operating system & reading the card data with an Internet-downloadable application. The operating system must be presumed insecure (we have no evidence that any general purpose operating system has ever been invulnerable to exploitation), the payment card application hosted on the operating system can not (by definition) be more secure than the operating system, and unless the terminal performed some sort of encryption prior to sending the stream to the application, any compromise of the host OS would result in compromise of the card data.

But it is so convenient.

Update 08/05/2011: And insecure.


  1. Seems fairly clear cut to me, though IANAL and IANAQSA.

    If you are a Square customer who agrees to the Commercial Entity Agreement, clause 1.(e.) pretty clearly obligates you to comply with PCI DSS.

    Which means you must only use PA-DSS validated applications.

    The list of Validated Payment Applications

    doesn't list Square as a company making any validated payment applications.

    And, though I can't dig up a citation, I'm pretty sure I've read that the PCI Council had decided they were not going to be accepting any mobile apps for PA DSS validation until they said otherwise.

    I wouldn't recommend Square to anyone who had to accept the CEA, at minimum. I'm not clear whether the general UA ends up obligating one to PCI DSS compliance.

  2. If either the VeriFone or Square solution encrypts in hardware, and the software only transmits to the processing server (which has the decryption key) then the solutions might go a long way to increasing the level of security in a mobile payment environment. That's not to say either solution wouldn't still be vulnerable to the right mobile malware--which hasn't been written yet--but it'd be better than some of what's going on now in this space.

    As for compliance requirements, quoting the PCI stance on mobile payment applications:

    > Until such time that it has completed a comprehensive examination of the mobile communications device
    and mobile payment application landscape, the Council will not approve or list mobile payment
    applications used by merchants to accept and process payment for goods and services as validated PA-
    DSS applications unless all requirements can be satisfied as stated.

    Both VeriFone and Square are subject to PCI's "PA-DSS", or Payment Application Data Security Standards. Neither can be PA-DSS certified, however, because of their mobile nature. So those applications--and any merchants using them--are not compliant with their PCI-DSS requirements. Which probably means if they get breached, it's on them, regardless of contract language in either application.

    (I'm not a lawyer and I'm not a PCI expert, thankfully.)

  3. Verifone claims end to end encryption, but if they permit manual card entry...

  4. It looks like the PCI folks are taking notice of the issue:,289142,sid14_gci1528926,00.htm

  5. Allowing you to turn your phone into a payment card terminal is such a very convenient method for every consumer. This is indeed a very good application. However, it is safer to use if it's PCI compliant. This will give every user the confidence to pay their bills using this method without any hesitations.

    Vulnerability Assessment


Post a Comment

Popular posts from this blog

Cargo Cult System Administration

Cargo Cult: …imitate the superficial exterior of a process or system without having any understanding of the underlying substance --Wikipedia During and after WWII, some native south pacific islanders erroneously associated the presence of war related technology with the delivery of highly desirable cargo. When the war ended and the cargo stopped showing up, they built crude facsimiles of runways, control towers, and airplanes in the belief that the presence of war technology caused the delivery of desirable cargo. From our point of view, it looks pretty amusing to see people build fake airplanes, runways and control towers  and wait for cargo to fall from the sky.
The question is, how amusing are we?We have cargo cult science[1], cargo cult management[2], cargo cult programming[3], how about cargo cult system management?Here’s some common system administration failures that might be ‘cargo cult’:
Failing to understand the difference between necessary and sufficient. A daily backup …

Ad-Hoc Versus Structured System Management

Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don't know how inconsistent they are, because you've never looked.

In previous posts (here and here) I implied that structured system management was an integral part of improving system availability. Having inherited several platforms that had, at best, ad hoc system management, and having moved the platforms to something resembling structured system management, I've concluded that implementing basic structure around system management will be the best and fastest path to…

The Cloud – Provider Failure Modes

In The Cloud - Outsourcing Moved up the Stack[1] I compared the outsourcing that we do routinely (wide area networks) with the outsourcing of the higher layers of the application stack (processor, memory, storage). Conceptually they are similar:In both cases you’ve entrusted your bits to someone else, you’ve shared physical and logical resources with others, you’ve disassociated physical devices (circuits or servers) from logical devices (virtual circuits, virtual severs), and in exchange for what is hopefully better, faster, cheaper service, you give up visibility, manageability and control to a provider. There are differences though. In the case of networking, your cloud provider is only entrusted with your bits for the time it takes for those bits to cross the providers network, and the loss of a few bits is not catastrophic. For providers of higher layer services, the bits are entrusted to the provider for the life of the bits, and the loss of a few bits is a major problem. These …