This 'open letter' has a ring of dishonesty to it.
> Clearly, Square is a threat to VeriFone, so it’s intentions aren’t so pure when exposing this potential issue.
That much is obvious. The letter is geared towards 'protecting the consumer', but makes the skimming method extremely public (especially with sq-skim.com)
I'm sure this will result in an increase in credit card theft incidents.
I'm also curious as to whether or not the perceived security threat is a bit overblown—there are many opportunities for my credit card number to be stolen (either when I use it online, or for physical transactions.) There's always a risk, and as such, I generally don't go passing my credit card (or scanning my credit card) to vendors I don't trust. I assume that since you'd need to be physically present to give the card to be skimmed, you'd draw on other internal factors of trust (and not have much of a higher potential for card theft than at any other establishment.)
>"In less than an hour, any reasonably skilled programmer can write an application that will "skim" – or steal – a consumer's financial and personal information right off the card utilizing an easily obtained Square card reader."
Oh, but wait, we already DID IT FOR YOU.
VeriFone, protecting consumers by posting hacked apps to skim credit card numbers.
Were you able to find actually find the app? It seems they (wisely) never posted it.
>Don’t take our word for it. See for yourself at www.sq-skim.com where you can download the sample skimming application and view a video of this type of fraud in action.
Commenting on the YouTube video has also been disabled. I feel like there is some sort of parable about glass houses here...
The comments are spot on on the TC article. Does TC really not think about these things before publishing? If you give me your credit card, I can steal your CC info regardless of whether or not I use a card reader, a camera or a pen/paper. This is just sad.
The comments on the story, and the first round here, make me worry that people are missing the point. Particularly this one:
> VeriFone's point (albeit a stupid one) is that the path from the card reader itself to the iOS device is not secure, so it's a hardware "problem."
That point isn't stupid at all, and is actually a legitimate gripe. It is my understanding that the Square device is only meant to be used with the Square payment software. Is that wrong? If that's the case, it shouldn't be as easy as VeriFone claims it is to skim a number from the device. I don't follow card skimming, but I would think that the point VeriFone is trying to make here is that Square is making it easier for low-tech criminals to implement a skimmer. While it is possible today, I've never heard it described as easy.
Another of the commenters mentioned that professional card skimmers have their own devices. That's fine; that isn't the problem here. Professionals will always do things better than the entry-level criminals. However, from my reading, it sounds like there is the capability here to write a shrink-wrapped iOS app that talks to the free Square reader, and you have skimming for a total investment of an iPod touch (or lack of investment -- you are a criminal, after all). Which is the problem that VeriFone is bringing up, and I halfway agree with given the limited evidence presented to me. We're way too lax with credit cards.
Does the Square app really need to know the card number at all, aside from transmitting it upstream? What is the vector here? It seems like the Square device should be a black box that yields only some kind of payment token, and the app only gets the cardholder name (from their screenshots).
Square's own security page[1] makes this ambiguous, too:
> Card numbers, magnetic stripe data, or security codes are not stored on Square client devices.
I've never used Square, so I might be full of hot air. However, I think instantly painting this as not an issue simply because it came from a competitor is doing a disservice to the potential (real) vulnerability here. Read the information, not the source...
I've never used the Square device either, but I don't see this as a hardware "problem". This is no different (to me) than a USB card reader that operates as a keyboard. You could scan the card into the vendor software, or into Notepad. Either way, it isn't a hardware flaw.
Again, please answer this: why does the Square app need to know the plaintext number? That is what makes it different from a USB card reader that operates as a keyboard. One is designed to accept payments, and the other is designed to steal numbers. We're comparing apples and oranges here.
The path from the Square device to Square's servers should be completely untouchable to any app. That's what VeriFone is saying. Simply because there are alternative black-market products that encourage crime (and cost money, by the way), there shouldn't be a free product that simply hands you card numbers if asked nicely.
It's a matter of cost vs. benefit. Designing an iPhone peripheral that has built-in crypto is extremely expensive (or any embedded system with strong crypto for that matter), especially if the information you're trying to protect is printed on the other side of the friggin card. The fact is, as a consumer, you can't know if the device that's going to read your card is legit. This is true even if you're looking at a state of the art IBM POS system or a tiny plastic widget with a coil of wire attached to a headphone jack.
I think this is the most important point in this thread. Verifone (and the other big players) makes expensive card readers. Square is disrupting that with a card reader so cheap that they can give it away for free. Verifone is using a standard anti-disruption argument: we're not over-engineered because everyone needs this level of complexity (crypto in this case). This would potentially break Square's business model.
Aside from the part where a vendor is required to keep your card number for refunds...
Square (as I see it) is a two part solution: hardware to read your card and software to handle the transaction. The hardware is talking to whatever software is running. As a customer, you hope that software is legit, but you never know. How is this any different from handing your card to anyone else?
USB card readers aren't black market by any means. This is how most POS devices read credit cards. It used to just be straight serial connections. It seems you're under the false assumption that the hardware path from your card to the software was ever secure.
If Verifone really cared about a completely protected path for card numbers, they would disallow all USB card readers and require a secured path from reader to their clearing house. Unfortunately, that would remove credit card processing for many (all?) vendors.
They are blaming Square for a security "flaw" that is present in their own system.
> Aside from the part where a vendor is required to keep your card number for refunds...
Vendors aren't required to retain the full card number. They are required to retain the last 5 digits (or last 4, I'm not 100% positive), as well as the transaction time. When a chargeback or refund comes around, they'll cross reference multiple forms of identification on the transaction, but they'll never have to handle the full card number.
All card readers are a two part solution. A hardware reader (USB, serial, whatever) is useless without some sort of {firm,soft}ware behind it. With Square, consumers will be trusting whoever they hand their card to be running current and legitimate software. How this is any different than me handing my card to an entirely random person at the corner store I don't understand, except this time I could write an alternate application to process the transaction myself without having to use a JTAG cable as I would for one of Verifone's closed systems.
The victim in this scenario is handing their credit card to the attacker. That's game over. It doesn't matter whether the attacker has a Square, a VeriFone device, or a piece of paper for writing down the card number. If you hand your credit card to someone malicious, they can figure out how to do bad things with it.
I'm a big fan of Square, but it's important to remember that their solution doesn't remove the traditional risks of credit card usage. But then, there isn't yet a widely-deployed, field-tested alternative, at least in the US. The advent of NFC payments may put reasonable crypto in the POS flow, but I'm sure it's matter of time before side-channel attacks are discovered in the burgeoning NFC solutions.
Security is hard. But VeriFone isn't talking about security. They're using security as an anti-competitive stalking horse, and that's a disgusting way to do business.
Very, and I will dig my heels in on this. For the record, your point would have been just as clear without this assertion that my point is stupid.
> The victim in this scenario is HANDING THEIR CREDIT CARD TO THE ATTACKER. That's game over. It doesn't matter whether the attacker has a Square, a VeriFone device, or a piece of paper for writing down the card number. If you hand your credit card to someone malicious, they can figure out how to do bad things with it.
So everybody should just stop doing security, since people will figure out ways around it? Why bother? The Square device, as another commenter points out elsewhere in this thread, sets the expectation of a legitimate transaction. It's pushed, it's marketed, it's being set as the new brand of credit card processing.
As such, Square have a responsibility to make sure that their products do not make skimming easier. And guess what? VeriFone found a way to skim, easily, with their product.
This whole "but you can do it on the black market for $20!" argument is, pardon the Latin, fucking ridiculous. I seriously can't believe there are people in this thread, who identify themselves as IT specialists, siding with Square because credit card processing is a lost cause. Internet Explorer 6 is pretty much a lost cause for Web exploits. Does that mean the rest of the browsers should not protect against Web exploits? This argument makes absolutely no sense. Who cares what others are doing? Do your product right.
> I'm a big fan of Square, but it's important to remember that their solution doesn't remove the traditional risks of credit card usage.
True. But there is NO REASON to make the vector EASIER. PERIOD. Simply because there are real risks with the vector means that we should take strides to make the vector harder.
I don't know about you, but when I hand my credit card to somebody, I don't actually check out the brand name of the reader they're using. Whether the little gadget says Square or Circle or Rhombus on it has no effect on my expectation of a legitimate transaction.
If legitimate people using Square could have their numbers stolen because the upstream communication to the server wasn't encrypted, that would be a problem. That would be something to secure.
I mean, if the Square device couldn't read the raw numbers, then people would be complaining about how they own the hardware and they should be able to do whatever they want with it.
"This whole "but you can do it on the black market for $20!" argument is, pardon the Latin, fucking ridiculous."
Nice way to add 'black market' in there to try to dismiss a valid point. You can get card readers from legitimate businesses. They are valid peripherals used all the time. Do a search for 'usb credit card reader' on Google. All those results are not black market.
As an aside, it's funny how you have a problem with GP saying 'Are you serious?' and thinking it implies your point is stupid but then take the exact same dismissive tone for your whole post.
"I seriously can't believe there are people in this thread, who identify themselves as IT specialists, siding with Square because credit card processing is a lost cause. "
The fact of the matter is that people hand their cards over all the time to pay for things and no one ever looks to see what kind of device it is. When you are paying for something in a shop, do you check out the credit card processing machine first to make sure it's secure? When you hand your card over to the waiter to take to the back and pay for your meal, do you follow him to make sure he isn't swiping it into another machine or writing the number down on paper? Nope. And the fact that the square reader is a plaintext device, like a lot of the readers on point-of-sale systems, really doesn't mean anything.
Jed, there are exactly two directions you can go from here, and I advise you to pick one of them instead of standing in the crossroads hollering and waving your arms.
On one road, you make the argument that it is fundamentally unsafe to accept credit cards with commodity mobile computing devices, because there is no way to do chain-of-custody control with insecure magstripe cards. There is a reasonable case to be made here. I'll disagree with it, but you won't automatically lose.
On the other road, you can provide one of more specific steps Square could take to make their commodity mobile card reader device meaningfully more secure. Be careful on this road because it is dangerous; people, myself included, will be standing on the side of the road shooting at you. Remember, anything you come up with must meaningfully improve the security of a device that can only interact with insecure magstripes.
You can also walk your argument back, which is what I'd do if I were in your shoes.
> You can also walk your argument back, which is what I'd do if I were in your shoes.
Good point. I'm just leaving my argument where it is, since I've poignantly lost. The way you summarized it made something clear to me, though, so thank you for your response.
I had a response typed up to the "we need to switch to $X" elsewhere in this thread, then discarded it and went back to work after writing a much smaller one. That's probably the best way forward from the whole mess, since it is indeed true that magstripe technology is outdated and insecure. It's amazing to me that with the prevalence of strong crypto we haven't come up with something better that has been mass-adopted. Until Joe's Gas-n-Snacks in Bimbleberry, Kansas accepts my new-fangled card, I won't consider the replacement mass-adopted.
There's an interesting aside: Square hurts adoption of new-fangled payment technologies because it caters only to magstripes.
However, I still disagree on mere principle with "it's already broken, so no need to do it right for ourselves". That's a dangerous path to take in itself.
I think your perspective on what's broken is an issue.
It's one thing to say "everybody else is crappy, we can be crappy too." I agree, that's bad. Doing better can be a great differentiator.
It's another thing to realize "the input we receive is broken, our output will be too". Garbage in, garbage out.
Square, having decided they are going to be in the business of reading magnetic stripes, cannot make those magnetic stripes any more secure than they already are (not). They could maybe do better/right by being in a different business, but they can't do the business they are in any better.
You know it's not a real security concern because it can't be mollified. The kernel of Verifone's argument requires that nobody ever accept credit cards with little white card reader dongles, because a little white card skimmer dongle is trivial to construct. If Square dongles had googley eyes and pink antennae, Verifone's argument would involve the ease with which criminals can procure googley eyes and antennae.
What's pernicious about this argument is the way they've tried to make it sound as if there's a real technical concern here, when in fact the real issue they're articulating implicates the entire business model.
You're sorta not understanding what goes on in a verifone device. I would advise actually constructing and inserting a rogue verifone PED, it is non-trivial.
First, understand that when you swipe your card at mcdonalds, you're not trusting the guy behind the counter, the manager, the district or anyone else physically present or even mcdonalds. you're not trusting their malware laiden office computers, nor their network, et cetera. You're trusting the terminal. And the terminals, depending on model and service/etc, all have cryptographic MAC addresses "that are burned in" (lol), and they're externally by verifone. So first hurdle is that you can't just get a job at mcdonalds and ebay your way to a better life, when you switch out the device, it gets detected and blocked, and i imagine once the burger flippers figure out that its not broken and someone tried to own them, they pull the cameras, et cetera.
Next, the device has a myriad of tamper-detection qualities which make it non-trivial to get into and still have the damned thing still function. This is again, dependent on which device is in play and so on-- getting in successfully obviously can be done, but you're getting sorta specialized. Next, the card details/pin/etc all get encrypted at the device never to see plain-text again until it's "safely in the cloud".
That's the theory anyways, there's some problems but it's not that joe bubblegum is gonna download an 'app' and extract my credit card details from his employers iphone. If pressed for an opinion, I'd say the entire idea of getting people used to paying by swiping their cards through some guys phone is maligned and going to be horribly problematic. This is sorta like SSL, there's another maligned trust heirarchy that exists and makes sense sorta.
So, basically my point is, verifone is not entirely incorrect here. It's not that "a little white card skimmer dongle is trivial to construct" or any other hyperbole. A PED or other input device that I can dump my card info from is a problem.
There's another entire trust relationship going on here which everyone seems to skip: the most common use-case of dealing with a representative of a third-party who is less trustworthy than the third-party itself ('Alice meet George, embassary of Bob, don't mind the collasped veins, he's legit!').
This is all interesting but it has nothing at all to do with the point I'm making. What I'm saying is, Square could come up with an encrypted obsfuscated reader-to-iPhone protocol that, like Skype, would take the better part of a year to fully reverse. Verifone would then say: "yeah, but how does anyone who looks at the reader know that it isn't a fake Square dongle that doesn't really run that protocol?"
In that respect we are saying the same thing: the entire platform is, by Verifone's standards, unsuitable for accepting cards.
But that's not what Verifone is actually saying. They picked a much more specific argument against Square. There are two reasons that makes sense for them:
(1) because there will be another 57 similar arguments they can make if Square does something to mitigate that first concern, and
(2) because if they made the intellectually honest argument ("It's not safe to accept cards with any iPhone app, Square's or otherwise") the competitive issue driving this complaint would be too transparent.
I think you sorta misunderstood, and but also possibly hold some misguided beliefs (like i dont?).
The first thing is, there's a lot of things Square could do, and we could both live on the moon eventually also. Their current implementation is a skimmer with all of the logic and safety in the software with all the guarantees of PCI network security beyond that (lol, i bet its salesforce or ec2). On Verifone's end, it's not like we're talking some software-based encraption. Think hardware based asset tags to compliment client certs. Surely it's self-evident that the ease of obtaining what at the moment at best could be a client certificate from a phone and recovering the information from a tamper-resistant device that goes dark if you take it offline too long (rendering the information useless). If they took their device and made it less like a mouse and more like something that tried to tunnel through the stupidest medium ever, I could live with it a little more and see the 'they are stupidly insecure' argument as fud.
Second, you realize it took 1 person about a week to reverse, document and develop the PoC for blocking skype (me) and not much longer for a crypto-library from it (accuvant ryan)? A year is a vast over-estimate and im pretty slow at it.
If the overall debate pertains to whether verifone did this right or not, I'd agree with you. Although, I have to admit cheering for them with their 'and we will prove it with an app@#@!' part-- if they were consultants they wouldve gotten invited to speak at blackhat.
If I had to take a stab at it, after looking at square a little bit. I'd say that if they made the honest argument, Square would try to throw lawyers at them. The honest argument is, 'have you looked at these guys? they're bordering on a criminal-enterprise-by-design, albeit rubber stamped by PCI'. I mean seriously? a point and a half more if I don't have the card and want to enter it on your website instead?
(Also the hubris in their research & disclosure policy made my blood boil)
Anyone in the world can make a little white dongle that reads credit card magstripes. What is the point of making an ultra-secure white dongle? How would anybody know you're using the ultra-secure one?
Also as an addendum; the thought process about hardware reversing is not entirely correct. You will run into things like can't build a device that can sniff that fast without a substantial budget; how much is that microscope? That just have no real parallel in software
I take it that VeriFone has never heard of a magnetic card reader that plugs into a keyboard port?
This is a very shaky "security hole", if you ask me. When you hand over your card to someone, there is always a risk for them skimming the number. However, they kind of have to know the number in order to get paid... so how is this a security risk that is exclusive to Square again?
It seems their problem with Square is that it allows you to get the credit card number in plaintext if you use their hardware. Of course, this is nothing new: you can buy a cardreader that acts as a USB keyboard for $20 and use that to read a credit card and output it in TextMate. Square's hardware really has nothing to do with it: if Squary would use something else, you'd still be able to buy one of those reader thingies for $5 from DealExtreme or some other site, and use the same procedure to skim a credit card.
One thing Square could do would be to, say, encrypt the credit card info with a public key, then pass that data on to the app. The app could upload the data to Square, where it could be decrypted and verified. Of course, this wouldn't fit in a $2 reader, and there really isn't a point to do this as long as there are other readers out there that allow you to read the data in plain text.
> and there really isn't a point to do this as long as there are other readers out there that allow you to read the data in plain text.
This is the rub. If we had that attitude to everything in computing, the world would be a much worse place.
Think about what you're saying, and grant me a paraphrasing: devices exist to circumvent traditional card security, so implementing card security is unnecessary. How exactly do you get from A to B, there? Software exists to root iOS; does that mean Apple should give up and stop trying to defend their platform's security?
I strongly disagree with any strategy that says "well, the vector's already been exploited, so why bother doing anything about it in our product? It's cheaper if we don't!"
No, the fix is really easy: you drop the magnetic strip and only use chipped credit card (or similar). And this is what all the CC have been moving to already.
Having worked with many so-called "Mom and Pop" POS systems, I can tell you that it is just not that simple. Most "Mom and Pop" shops are already using integrated hardware/software solutions. How is their iPhone going to transfer transactions into the Accounts Receivable software that is tightly integrated into their register system? There's a lot more to it than just capturing a transaction.
The data on the magnetic stipe isn't encrypted, just encoded. There is no exploited vector. No one has cracked anything. You can read all about the encoding used and implement your own card reader with just a little Googling. You aren't 'hacking' anything to do so.
> It seems their problem with Square is that it allows you to get the credit card number in plaintext if you use their hardware. Of course, this is nothing new: you can buy a cardreader that acts as a USB keyboard for $20
The point is that Square is marketed as a (presumably secure) payment device. i.e. two strangers (merchant and customer) establish trust so that the customer feels comfortable making a payment with the merchant's device.
In the case of a standalone card reader, you can skim your own cards all day, but strangers aren't going to give you their card to skim without a fraudulent premise.
Square's device provides a non-fraudulent premise, which is why the security flaw is a problem.
I don't get it. What's the difference between using Square, swiping a customer's credit card and storing the data, or using a POS system, swiping a customer's CC and storing the data from that? A lot of those packages consist of a windows/mac machine and a simple reader, you could write a kernel module or similar to do just that. Is it that Square advertises as being secure?
Another possible answer: the square device is targeted at merchants with no permanent physical location thus lowering the barrier to entry for thieves.
> What's the difference between using Square, swiping a customer's credit card and storing the data, or using a POS system, swiping a customer's CC and storing the data from that?
Nothing, really. Most POS systems are resistant to data extraction. Square's is less so. My main point was that the USB card reader things are not POS devices. (Or are they?)
A lot of small businesses use card readers plugged into PCs. I'm more worried about trojans on those PCs rather than some crafty salesman with a jailbroken iPhone.
I'm kind of surprised Square didn't include some kind of hardware encryption, but then again, it would probably make the readers a lot more expensive to manufacture.
One of the amazing things about plastic cards is that they were never designed in the 1960s with security or the internet in mind. The card itself (with its Primary Account Number) is an inherently insecure medium. PCI DSS tries to make up for this by layering rule after rule on how you can treat PAN data, but as most professionals in the space know, a system is only as secure as its weakest link. There's really nothing PCI or any other standard can do. By focusing on cards, Square has opened itself up to all of the problems associated with them.
Starting from scratch is the best way, and pretty much the only way, to create a secure payment network in today's environment.
I've just discovered another serious security hole! When you hand your credit card to a waiter, they can see the credit card number totally unencrypted with their eyes! Clearly the solution is to blind all waiters.
The truth is credit card "security" is a bad joke. The only real defense these days is the fact that every payment processor has extremely sensitive fraudulent transaction detection systems because of the consumer protection laws that put fraud liability on the card issuer instead of the consumer. The whole system is a relic from the days before the internet and the only way to fix it is to replace it with something better like NFC.
This is the only relevant comment in this entire thread.
What's more, the 3-digit "security" code (pardon me, whilst I scoff) for these cards is printed on the card! If you hand someone your card, you're already saying that you trust them not to keep your card number and security code and submit false charges. The Square reader isn't making that process any harder or easier; it's totally irrelevant.
The last part is the really sad thing. We have the technology to do it right now, but because credit cards are everywhere and better stuff isn't, there's no motion toward improvement.
The fundamental problem is that the credit card system works by requiring the customer to provide the merchant with all of the credentials necessary to make a transaction. We could have inexpensive devices that receive payment details, display them on cheap LCDs, and digitally sign them if the user confirms. Such a device would be about as complex as a pocket calculator, and as secure as any application of digital signatures. Nobody is moving on them because of the chicken/egg problem.
what this could mean for Square is that since there is no security in practice one could argue they should pay the higher fees applicable to card-not-present transactions or where the number has been entered manually rather than the typically lower rates with verified card presence.
in practice it will boil down to how much VISA/MC like Square. i cannot imagine they see this expansion of CC billing to a new kind of merchants as a bad thing.
I've read that people will attach skimmers to gas station pumps/etc to get card info, so I assume there's more to be skimmed than just credit card numbers. So if you have 1 waiter with a Square-skimmer (or any other kind) and another without, can the first one get any more fraud-ready data than the second?
Looks like a skimmer will get you account number, name, expiration date, and some verification numbers.
> So if you have 1 waiter with a Square-skimmer (or any other kind) and another without, can the first one get any more fraud-ready data than the second?
No, if you give your card to a malicious waiter he can skim all of its data. Because you gave it to him.
It's true that Square's service is no less secure than paying with a Verifone device, sliding your card through the checkout system of your corner store, or handing you card over to the waiter and having them walk away with it in a restaurant. There is one thing that Square has done in a new way though: The service that they are providing, together with their corporate identity, has done a remarkable job at moving the idea of accepting credit card payments from big retail to small businesses and even private people.
While this is an admirable feat, it has has potentially dangerous impact on the users' perception of who is a trustworthy entity to hand their credit card to.
Before Square, I would have never handed over my credit card to a private person that I am doing a one-time transaction with and that I will likely never meet again in my life. With Square's efforts, that emotional barrier is slowly being torn down. Of course, they are not actively telling me to "trust everyone", but it is an inevitable development that they are continuously pushing forward.
Before square, a merchant (a person I would give my credit card to) was usually a person connected to a job in a business entity that was registered, had a (somewhat) fixed location and that was invested into building a long-lasting relationship with me and many other customers (= not interested at screwing me over by doing some credit card scam). None of this applies to an independent person with a square dongle in their iPhone but thanks to Square's efforts, customers feel more and more confident, handing a stranger over their cc for a quick transaction.
This is where there is a problem. It doesn't have to do with Square's technical implementation. It has to do with the inevitable customer's change in attitude, which ultimately, Square is "responsible" for.
I guess they didn't notice that all smart phones have this ability as standard, and call it "Camera". One quick snap, and boom - I've stored your CC number. No need for fancy hardware!
So is their a security flaw in the combination of the Square reader (hardware) and Square app (software)? That would be a problem and VeriFone wouldn't be in the wrong pointing it out.
Or is VeriFone just saying that hardware Square manufactures can be used for skimming? If that's the case, the email is pretty ridiculous. Skimming technology is nothing new and like others have said, readily available.
It comes down to what Square are trying to do, if they want to be "another credit card reader device" then this isn't a security hole.
On the other hand if they want to take the PayPal approach and build a secure payment brand which says "we're a securer way to pay because the end merchant never sees your credit card details", then it is a security hole, because it means you can't trust the Square brand to act as a layer between you and the merchant.
1. This actually does lead to a breach of card numbers, in which case Square will face penalties from Visa/MC/Amex - those penalties can be huge because they are calculated based upon the number of cards that were compromised (check out Heartland's breach last year).
2. Verifone is able to convince Visa/MC/Amex that Square is not PCI compliant and that they should fine Square out of existence (it's not a legal thing, it's at Visa/MC's discretion).
#1 is somewhat likely, on Android moreso than Iphone, there have been android viruses before.
#2 isn't that likely, unless there is actually a breach and it ends up costing Visa and Mastercard money, Square is strategic to Visa and Mastercard because it gives them access to an entirely new customer base (that Verifone hasn't had any luck with).
1. Customers don't give a shit. We hand our cards over into insecure situations all the time without thinking twice.
2. Businesses don't care either - they only care about PCI and security when either their acquirer (in this case Square, which won't do it) or Visa/MC start fining them or threaten to shut them down.
> It doesn't matter if they're using Square, Veri-whatever, or some beige-colored plastic card reader with a register that looks like it's from the 90's -- my data is vulnerable before it ever gets to the card reader.
How is your track (magstripe) data vulnerable without a reader?
The credit card number (and security code, and expiration date, and account holder name -- i.e. everything you need to "use" a credit card) is printed right on the card.
> The credit card number (and security code, and expiration date, and account holder name -- i.e. everything you need to "use" a credit card) is printed right on the card.
This information is not sufficient for a majority of transactions. Ecommerce tends to require VbV/SecureCode and Retail tends to require track data. These developments are a response to your very suggestion.
This attack really struck me the wrong way. I'll never, ever be a verifone customer.
Verifone really went about attacking it's competitor the wrong way.
In the video that demonstrates being able to read the card information with their own iOS app they mention a criminal glass blower buying a TV with your credit card after making a purchase with square.
A glass blower, really, ummmmm let me think when is the last time I made a purchase from a glass blower? Is that a common interaction? I would have thought they would have chosen a common transaction. Street vendor, food stand, but no a glass blower. Very strange.
If you follow startups you'll remember that Jim McKelvey developer of the square hardware in question is a . . . what does he do again . . . oh yeah a software engineer and glass blower.
This appears to be a personal attack on Jim as well as on Square.
I hope verifone enjoys a good laugh on putting a glass blower in their video. Hopefully verifone will be writing Mr. McKelvey a large check after the lawyers are through with this one.
Very poor business practice whether or not
I don't see the download for their skimming app have they taken the app down? Probably a good idea, I doubt the credit card companies will appreciate them providing a skimming app regardless of what reading hardware it's using.
It appears their video has been removed from youtube.com for violating terms of service.
> I don't see the download for their skimming app have they taken the app down? Probably a good idea, I doubt the credit card companies will appreciate them providing a skimming app regardless of what reading hardware it's using.
I imagine that part of the problem was that they were distributing an iPhone app binary along with their in-house enterprise distribution provisioning certificate to the public, which I imagine Apple isn't happy about.
> We believe it is not in the best interest of the consumers, merchants and overall payment industry to publish the details of product designs describing potential attacks however remote those might be. Even if these attacks are difficult to be accomplished it gives the bad guys a leg up on research they would not have to do and encourages bad behavior.
70 comments
[ 3.3 ms ] story [ 118 ms ] thread> Clearly, Square is a threat to VeriFone, so it’s intentions aren’t so pure when exposing this potential issue.
That much is obvious. The letter is geared towards 'protecting the consumer', but makes the skimming method extremely public (especially with sq-skim.com)
I'm sure this will result in an increase in credit card theft incidents.
I'm also curious as to whether or not the perceived security threat is a bit overblown—there are many opportunities for my credit card number to be stolen (either when I use it online, or for physical transactions.) There's always a risk, and as such, I generally don't go passing my credit card (or scanning my credit card) to vendors I don't trust. I assume that since you'd need to be physically present to give the card to be skimmed, you'd draw on other internal factors of trust (and not have much of a higher potential for card theft than at any other establishment.)
>"In less than an hour, any reasonably skilled programmer can write an application that will "skim" – or steal – a consumer's financial and personal information right off the card utilizing an easily obtained Square card reader."
Oh, but wait, we already DID IT FOR YOU.
VeriFone, protecting consumers by posting hacked apps to skim credit card numbers.
>Don’t take our word for it. See for yourself at www.sq-skim.com where you can download the sample skimming application and view a video of this type of fraud in action.
Commenting on the YouTube video has also been disabled. I feel like there is some sort of parable about glass houses here...
Thank you!!
Is this for the iPhone or for the Android phone?
And do you know how it works?
> VeriFone's point (albeit a stupid one) is that the path from the card reader itself to the iOS device is not secure, so it's a hardware "problem."
That point isn't stupid at all, and is actually a legitimate gripe. It is my understanding that the Square device is only meant to be used with the Square payment software. Is that wrong? If that's the case, it shouldn't be as easy as VeriFone claims it is to skim a number from the device. I don't follow card skimming, but I would think that the point VeriFone is trying to make here is that Square is making it easier for low-tech criminals to implement a skimmer. While it is possible today, I've never heard it described as easy.
Another of the commenters mentioned that professional card skimmers have their own devices. That's fine; that isn't the problem here. Professionals will always do things better than the entry-level criminals. However, from my reading, it sounds like there is the capability here to write a shrink-wrapped iOS app that talks to the free Square reader, and you have skimming for a total investment of an iPod touch (or lack of investment -- you are a criminal, after all). Which is the problem that VeriFone is bringing up, and I halfway agree with given the limited evidence presented to me. We're way too lax with credit cards.
Does the Square app really need to know the card number at all, aside from transmitting it upstream? What is the vector here? It seems like the Square device should be a black box that yields only some kind of payment token, and the app only gets the cardholder name (from their screenshots).
Square's own security page[1] makes this ambiguous, too:
> Card numbers, magnetic stripe data, or security codes are not stored on Square client devices.
I've never used Square, so I might be full of hot air. However, I think instantly painting this as not an issue simply because it came from a competitor is doing a disservice to the potential (real) vulnerability here. Read the information, not the source...
[1]: https://squareup.com/security
The path from the Square device to Square's servers should be completely untouchable to any app. That's what VeriFone is saying. Simply because there are alternative black-market products that encourage crime (and cost money, by the way), there shouldn't be a free product that simply hands you card numbers if asked nicely.
Square (as I see it) is a two part solution: hardware to read your card and software to handle the transaction. The hardware is talking to whatever software is running. As a customer, you hope that software is legit, but you never know. How is this any different from handing your card to anyone else?
USB card readers aren't black market by any means. This is how most POS devices read credit cards. It used to just be straight serial connections. It seems you're under the false assumption that the hardware path from your card to the software was ever secure.
If Verifone really cared about a completely protected path for card numbers, they would disallow all USB card readers and require a secured path from reader to their clearing house. Unfortunately, that would remove credit card processing for many (all?) vendors.
They are blaming Square for a security "flaw" that is present in their own system.
Vendors aren't required to retain the full card number. They are required to retain the last 5 digits (or last 4, I'm not 100% positive), as well as the transaction time. When a chargeback or refund comes around, they'll cross reference multiple forms of identification on the transaction, but they'll never have to handle the full card number.
All card readers are a two part solution. A hardware reader (USB, serial, whatever) is useless without some sort of {firm,soft}ware behind it. With Square, consumers will be trusting whoever they hand their card to be running current and legitimate software. How this is any different than me handing my card to an entirely random person at the corner store I don't understand, except this time I could write an alternate application to process the transaction myself without having to use a JTAG cable as I would for one of Verifone's closed systems.
edit: clarification of last paragraph.
The victim in this scenario is handing their credit card to the attacker. That's game over. It doesn't matter whether the attacker has a Square, a VeriFone device, or a piece of paper for writing down the card number. If you hand your credit card to someone malicious, they can figure out how to do bad things with it.
I'm a big fan of Square, but it's important to remember that their solution doesn't remove the traditional risks of credit card usage. But then, there isn't yet a widely-deployed, field-tested alternative, at least in the US. The advent of NFC payments may put reasonable crypto in the POS flow, but I'm sure it's matter of time before side-channel attacks are discovered in the burgeoning NFC solutions.
Security is hard. But VeriFone isn't talking about security. They're using security as an anti-competitive stalking horse, and that's a disgusting way to do business.
Very, and I will dig my heels in on this. For the record, your point would have been just as clear without this assertion that my point is stupid.
> The victim in this scenario is HANDING THEIR CREDIT CARD TO THE ATTACKER. That's game over. It doesn't matter whether the attacker has a Square, a VeriFone device, or a piece of paper for writing down the card number. If you hand your credit card to someone malicious, they can figure out how to do bad things with it.
So everybody should just stop doing security, since people will figure out ways around it? Why bother? The Square device, as another commenter points out elsewhere in this thread, sets the expectation of a legitimate transaction. It's pushed, it's marketed, it's being set as the new brand of credit card processing.
As such, Square have a responsibility to make sure that their products do not make skimming easier. And guess what? VeriFone found a way to skim, easily, with their product.
This whole "but you can do it on the black market for $20!" argument is, pardon the Latin, fucking ridiculous. I seriously can't believe there are people in this thread, who identify themselves as IT specialists, siding with Square because credit card processing is a lost cause. Internet Explorer 6 is pretty much a lost cause for Web exploits. Does that mean the rest of the browsers should not protect against Web exploits? This argument makes absolutely no sense. Who cares what others are doing? Do your product right.
> I'm a big fan of Square, but it's important to remember that their solution doesn't remove the traditional risks of credit card usage.
True. But there is NO REASON to make the vector EASIER. PERIOD. Simply because there are real risks with the vector means that we should take strides to make the vector harder.
If legitimate people using Square could have their numbers stolen because the upstream communication to the server wasn't encrypted, that would be a problem. That would be something to secure.
I mean, if the Square device couldn't read the raw numbers, then people would be complaining about how they own the hardware and they should be able to do whatever they want with it.
Nice way to add 'black market' in there to try to dismiss a valid point. You can get card readers from legitimate businesses. They are valid peripherals used all the time. Do a search for 'usb credit card reader' on Google. All those results are not black market.
As an aside, it's funny how you have a problem with GP saying 'Are you serious?' and thinking it implies your point is stupid but then take the exact same dismissive tone for your whole post.
"I seriously can't believe there are people in this thread, who identify themselves as IT specialists, siding with Square because credit card processing is a lost cause. "
The fact of the matter is that people hand their cards over all the time to pay for things and no one ever looks to see what kind of device it is. When you are paying for something in a shop, do you check out the credit card processing machine first to make sure it's secure? When you hand your card over to the waiter to take to the back and pay for your meal, do you follow him to make sure he isn't swiping it into another machine or writing the number down on paper? Nope. And the fact that the square reader is a plaintext device, like a lot of the readers on point-of-sale systems, really doesn't mean anything.
On one road, you make the argument that it is fundamentally unsafe to accept credit cards with commodity mobile computing devices, because there is no way to do chain-of-custody control with insecure magstripe cards. There is a reasonable case to be made here. I'll disagree with it, but you won't automatically lose.
On the other road, you can provide one of more specific steps Square could take to make their commodity mobile card reader device meaningfully more secure. Be careful on this road because it is dangerous; people, myself included, will be standing on the side of the road shooting at you. Remember, anything you come up with must meaningfully improve the security of a device that can only interact with insecure magstripes.
You can also walk your argument back, which is what I'd do if I were in your shoes.
Good point. I'm just leaving my argument where it is, since I've poignantly lost. The way you summarized it made something clear to me, though, so thank you for your response.
I had a response typed up to the "we need to switch to $X" elsewhere in this thread, then discarded it and went back to work after writing a much smaller one. That's probably the best way forward from the whole mess, since it is indeed true that magstripe technology is outdated and insecure. It's amazing to me that with the prevalence of strong crypto we haven't come up with something better that has been mass-adopted. Until Joe's Gas-n-Snacks in Bimbleberry, Kansas accepts my new-fangled card, I won't consider the replacement mass-adopted.
There's an interesting aside: Square hurts adoption of new-fangled payment technologies because it caters only to magstripes.
However, I still disagree on mere principle with "it's already broken, so no need to do it right for ourselves". That's a dangerous path to take in itself.
It's one thing to say "everybody else is crappy, we can be crappy too." I agree, that's bad. Doing better can be a great differentiator.
It's another thing to realize "the input we receive is broken, our output will be too". Garbage in, garbage out.
Square, having decided they are going to be in the business of reading magnetic stripes, cannot make those magnetic stripes any more secure than they already are (not). They could maybe do better/right by being in a different business, but they can't do the business they are in any better.
You know it's not a real security concern because it can't be mollified. The kernel of Verifone's argument requires that nobody ever accept credit cards with little white card reader dongles, because a little white card skimmer dongle is trivial to construct. If Square dongles had googley eyes and pink antennae, Verifone's argument would involve the ease with which criminals can procure googley eyes and antennae.
What's pernicious about this argument is the way they've tried to make it sound as if there's a real technical concern here, when in fact the real issue they're articulating implicates the entire business model.
You're sorta not understanding what goes on in a verifone device. I would advise actually constructing and inserting a rogue verifone PED, it is non-trivial.
First, understand that when you swipe your card at mcdonalds, you're not trusting the guy behind the counter, the manager, the district or anyone else physically present or even mcdonalds. you're not trusting their malware laiden office computers, nor their network, et cetera. You're trusting the terminal. And the terminals, depending on model and service/etc, all have cryptographic MAC addresses "that are burned in" (lol), and they're externally by verifone. So first hurdle is that you can't just get a job at mcdonalds and ebay your way to a better life, when you switch out the device, it gets detected and blocked, and i imagine once the burger flippers figure out that its not broken and someone tried to own them, they pull the cameras, et cetera.
Next, the device has a myriad of tamper-detection qualities which make it non-trivial to get into and still have the damned thing still function. This is again, dependent on which device is in play and so on-- getting in successfully obviously can be done, but you're getting sorta specialized. Next, the card details/pin/etc all get encrypted at the device never to see plain-text again until it's "safely in the cloud".
That's the theory anyways, there's some problems but it's not that joe bubblegum is gonna download an 'app' and extract my credit card details from his employers iphone. If pressed for an opinion, I'd say the entire idea of getting people used to paying by swiping their cards through some guys phone is maligned and going to be horribly problematic. This is sorta like SSL, there's another maligned trust heirarchy that exists and makes sense sorta.
So, basically my point is, verifone is not entirely incorrect here. It's not that "a little white card skimmer dongle is trivial to construct" or any other hyperbole. A PED or other input device that I can dump my card info from is a problem.
There's another entire trust relationship going on here which everyone seems to skip: the most common use-case of dealing with a representative of a third-party who is less trustworthy than the third-party itself ('Alice meet George, embassary of Bob, don't mind the collasped veins, he's legit!').
In that respect we are saying the same thing: the entire platform is, by Verifone's standards, unsuitable for accepting cards.
But that's not what Verifone is actually saying. They picked a much more specific argument against Square. There are two reasons that makes sense for them:
(1) because there will be another 57 similar arguments they can make if Square does something to mitigate that first concern, and
(2) because if they made the intellectually honest argument ("It's not safe to accept cards with any iPhone app, Square's or otherwise") the competitive issue driving this complaint would be too transparent.
The first thing is, there's a lot of things Square could do, and we could both live on the moon eventually also. Their current implementation is a skimmer with all of the logic and safety in the software with all the guarantees of PCI network security beyond that (lol, i bet its salesforce or ec2). On Verifone's end, it's not like we're talking some software-based encraption. Think hardware based asset tags to compliment client certs. Surely it's self-evident that the ease of obtaining what at the moment at best could be a client certificate from a phone and recovering the information from a tamper-resistant device that goes dark if you take it offline too long (rendering the information useless). If they took their device and made it less like a mouse and more like something that tried to tunnel through the stupidest medium ever, I could live with it a little more and see the 'they are stupidly insecure' argument as fud.
Second, you realize it took 1 person about a week to reverse, document and develop the PoC for blocking skype (me) and not much longer for a crypto-library from it (accuvant ryan)? A year is a vast over-estimate and im pretty slow at it.
If the overall debate pertains to whether verifone did this right or not, I'd agree with you. Although, I have to admit cheering for them with their 'and we will prove it with an app@#@!' part-- if they were consultants they wouldve gotten invited to speak at blackhat.
If I had to take a stab at it, after looking at square a little bit. I'd say that if they made the honest argument, Square would try to throw lawyers at them. The honest argument is, 'have you looked at these guys? they're bordering on a criminal-enterprise-by-design, albeit rubber stamped by PCI'. I mean seriously? a point and a half more if I don't have the card and want to enter it on your website instead?
(Also the hubris in their research & disclosure policy made my blood boil)
This is a very shaky "security hole", if you ask me. When you hand over your card to someone, there is always a risk for them skimming the number. However, they kind of have to know the number in order to get paid... so how is this a security risk that is exclusive to Square again?
One thing Square could do would be to, say, encrypt the credit card info with a public key, then pass that data on to the app. The app could upload the data to Square, where it could be decrypted and verified. Of course, this wouldn't fit in a $2 reader, and there really isn't a point to do this as long as there are other readers out there that allow you to read the data in plain text.
This is the rub. If we had that attitude to everything in computing, the world would be a much worse place.
Think about what you're saying, and grant me a paraphrasing: devices exist to circumvent traditional card security, so implementing card security is unnecessary. How exactly do you get from A to B, there? Software exists to root iOS; does that mean Apple should give up and stop trying to defend their platform's security?
I strongly disagree with any strategy that says "well, the vector's already been exploited, so why bother doing anything about it in our product? It's cheaper if we don't!"
The point is that Square is marketed as a (presumably secure) payment device. i.e. two strangers (merchant and customer) establish trust so that the customer feels comfortable making a payment with the merchant's device.
In the case of a standalone card reader, you can skim your own cards all day, but strangers aren't going to give you their card to skim without a fraudulent premise.
Square's device provides a non-fraudulent premise, which is why the security flaw is a problem.
Nothing, really. Most POS systems are resistant to data extraction. Square's is less so. My main point was that the USB card reader things are not POS devices. (Or are they?)
One of the amazing things about plastic cards is that they were never designed in the 1960s with security or the internet in mind. The card itself (with its Primary Account Number) is an inherently insecure medium. PCI DSS tries to make up for this by layering rule after rule on how you can treat PAN data, but as most professionals in the space know, a system is only as secure as its weakest link. There's really nothing PCI or any other standard can do. By focusing on cards, Square has opened itself up to all of the problems associated with them.
Starting from scratch is the best way, and pretty much the only way, to create a secure payment network in today's environment.
The truth is credit card "security" is a bad joke. The only real defense these days is the fact that every payment processor has extremely sensitive fraudulent transaction detection systems because of the consumer protection laws that put fraud liability on the card issuer instead of the consumer. The whole system is a relic from the days before the internet and the only way to fix it is to replace it with something better like NFC.
What's more, the 3-digit "security" code (pardon me, whilst I scoff) for these cards is printed on the card! If you hand someone your card, you're already saying that you trust them not to keep your card number and security code and submit false charges. The Square reader isn't making that process any harder or easier; it's totally irrelevant.
The law may have put it on the issuer, but the issuers just fob it off on the merchants.
> The truth is credit card "security" is a bad joke.
Word.
[EDIT:] Some additional thoughts: http://news.ycombinator.com/item?id=2305899l
The fundamental problem is that the credit card system works by requiring the customer to provide the merchant with all of the credentials necessary to make a transaction. We could have inexpensive devices that receive payment details, display them on cheap LCDs, and digitally sign them if the user confirms. Such a device would be about as complex as a pocket calculator, and as secure as any application of digital signatures. Nobody is moving on them because of the chicken/egg problem.
in practice it will boil down to how much VISA/MC like Square. i cannot imagine they see this expansion of CC billing to a new kind of merchants as a bad thing.
I've read that people will attach skimmers to gas station pumps/etc to get card info, so I assume there's more to be skimmed than just credit card numbers. So if you have 1 waiter with a Square-skimmer (or any other kind) and another without, can the first one get any more fraud-ready data than the second?
As usual, Le Wik to the rescue: http://en.wikipedia.org/wiki/Magnetic_stripe_card#Financial_...
Looks like a skimmer will get you account number, name, expiration date, and some verification numbers.
> So if you have 1 waiter with a Square-skimmer (or any other kind) and another without, can the first one get any more fraud-ready data than the second?
No, if you give your card to a malicious waiter he can skim all of its data. Because you gave it to him.
(I am a square investor.)
Or is VeriFone just saying that hardware Square manufactures can be used for skimming? If that's the case, the email is pretty ridiculous. Skimming technology is nothing new and like others have said, readily available.
On the other hand if they want to take the PayPal approach and build a secure payment brand which says "we're a securer way to pay because the end merchant never sees your credit card details", then it is a security hole, because it means you can't trust the Square brand to act as a layer between you and the merchant.
1. This actually does lead to a breach of card numbers, in which case Square will face penalties from Visa/MC/Amex - those penalties can be huge because they are calculated based upon the number of cards that were compromised (check out Heartland's breach last year).
2. Verifone is able to convince Visa/MC/Amex that Square is not PCI compliant and that they should fine Square out of existence (it's not a legal thing, it's at Visa/MC's discretion).
#1 is somewhat likely, on Android moreso than Iphone, there have been android viruses before.
#2 isn't that likely, unless there is actually a breach and it ends up costing Visa and Mastercard money, Square is strategic to Visa and Mastercard because it gives them access to an entirely new customer base (that Verifone hasn't had any luck with).
1. Customers don't give a shit. We hand our cards over into insecure situations all the time without thinking twice.
2. Businesses don't care either - they only care about PCI and security when either their acquirer (in this case Square, which won't do it) or Visa/MC start fining them or threaten to shut them down.
How is your track (magstripe) data vulnerable without a reader?
This information is not sufficient for a majority of transactions. Ecommerce tends to require VbV/SecureCode and Retail tends to require track data. These developments are a response to your very suggestion.
Verifone really went about attacking it's competitor the wrong way.
In the video that demonstrates being able to read the card information with their own iOS app they mention a criminal glass blower buying a TV with your credit card after making a purchase with square.
A glass blower, really, ummmmm let me think when is the last time I made a purchase from a glass blower? Is that a common interaction? I would have thought they would have chosen a common transaction. Street vendor, food stand, but no a glass blower. Very strange.
If you follow startups you'll remember that Jim McKelvey developer of the square hardware in question is a . . . what does he do again . . . oh yeah a software engineer and glass blower.
This appears to be a personal attack on Jim as well as on Square.
I hope verifone enjoys a good laugh on putting a glass blower in their video. Hopefully verifone will be writing Mr. McKelvey a large check after the lawyers are through with this one.
Very poor business practice whether or not
I don't see the download for their skimming app have they taken the app down? Probably a good idea, I doubt the credit card companies will appreciate them providing a skimming app regardless of what reading hardware it's using.
It appears their video has been removed from youtube.com for violating terms of service.
I imagine that part of the problem was that they were distributing an iPhone app binary along with their in-house enterprise distribution provisioning certificate to the public, which I imagine Apple isn't happy about.
> We believe it is not in the best interest of the consumers, merchants and overall payment industry to publish the details of product designs describing potential attacks however remote those might be. Even if these attacks are difficult to be accomplished it gives the bad guys a leg up on research they would not have to do and encourages bad behavior.
in response to : PIN Entry Device (PED) vulnerabilities http://www.cl.cam.ac.uk/research/security/banking/ped/