MagSpoof – wireless credit card/magstripe spoofer

Yes, he has quite a resume there. However, maybe I'm just older, but my ideal polymath is not just coding/hacking electronics. I personally think it should be those plus knowing more diverse fields and skills such as: applied mathematics, celestial navigation, biohacking, chemistry, milling/lathe work, building machinery from scratch by smelting and casting [1], animatronics, boatbuilding, horology, mechatronics, music, languages etc... I picked these things, because they are things I personally strive to keep learning. They are not everybody's list. I guess today the emphasis is on coding/small electronics because of the world it opens up to you (except those things that are purely mechanical or require other skills). In any case, my hat is off to him. Impressive!

   [1] http://gingerybooks.com/

It's actually just a wireless network that you connect to and send commands to the Parrot. It makes it really easy to control it from your laptop. There is a library for it that makes it possible to be up and running in under 5 minutes.

Library: https://github.com/felixge/node-ar-drone

The number of times I've seen what seems like the Hackers script got borrowed and applied to real life - people being banned from using computers for an arbitrary length of time - is just silly.

I think the problem with these systems is that "good enough" should be much more "gooder" than it is, due to being a solved problem for most cases.

For example, if you happen to need a unique ID for each card, and you roll your own "random id generator" you might happen to encounter pitfalls that would've been solved by using UUIDs.

Or you try to get some sort of hash value from the card info (to verify validity or whatever) and instead of using a known hashing algorithm you try to roll your own.

And I would guess a long list of etceteras.

So when a system that should be for the most part trivial to implement correctly is full of these holes then people like GP will start poking around and ultimately start finding a lot of issues that would make it actually not "good enough".

I mean sure, keys are just there to keep honest people out, but if you can use a standard key that would foil both honest AND a few opportunistic dishonest people then why are you instead trying to use your own "custom key" that happens to be much easier to defeat? Especially if said standard key is not really that much harder to implement.

Yeah, until a man gains easy access to 17-year-old girls' housing, then everyone will flip out. I mean, it's one thing to break stuff to get in, or conspicuously pick a lock, it's another to casually slide a card like everyone else and leave no trail other than maybe video surveillance or access logs showing the same card being used at two ends of campus faster than possible (which nobody will check until something bad happens and they go looking at that data.)

I had a similar experience at my university. I found easy unauthenticated sourcing of most of the data needed to clone the card of anybody by name. The issue number was the only thing to guess, but easy to bruteforce on something low-stakes like vending machines. The card was used for food, a debit-card-like system, automated door locks to semi-public buildings and on-campus housing.

With the permission and cooperation of the university security, I made a card of a high-level security guy (who could have been targeted using the public/semi-public org chart) and swiped into their datacenter where all the university data is hosted, along with that of some partners with sensitive data. Luckily the innermost parts need an RFID or something which I didn't have access to, but potentially I could have tailgated or social-engineered my way into that. They weren't interested in letting me research whether I could crack the RFID. :(

I was told my demo made a big splash, but IIRC I checked a year or two later and my source for the ID data was still wide open. There's having imperfect locks and then there's leaving all your keys out in public.

I'm pretty sure that, aside from the magstripe security issue, that practice (grades left in public identified by SSNs and/or student ID #s) has been a FERPA violation forever. Or since the 1970s, at least.

If it's the same as it was back in the days of Credit Master 4 for DOS, it bumps up by eights and sixteens.

Either it's only a specific kind of amex, or it's not starting from 0, or this is incorrect information.

I've got 2 AMEX cards - one reissued and ends with 0, another issued the first time and ends with non-0. (I'm ignoring the check digit)

I don't see how this is by design since it only seems to be a vulnerability with Amex and your link doesn't really talk about it.

It's known, I know someone that has experienced the same issue.

The chip is being rolled out to keep up with VISA/Mastercard's deployment of chip. Note however that chip transactions are far slower than proximity or magstripe uses, making it completely redundant except for a malfunctioning magstripe reader.

It would have been as much software update to have implemented PIN and would've brought security to the level of ATM cards.

The generation and provisioning of card numbers is limited by other systems which includes fraud detection, account processing, auditing and other backend systems.

Samsung Pay's pitch is that it is (mostly) backwards compatible with existing card readers. When NFC fails, it does fallback to magnetic strip emulation.

Did they ever think chip & pin wouldn't roll out? I took the magstripe emulation as a bridge play, to be the first truly viable mobile payments option in order to take pole position in the coming mobile payments scuffle.

Couldn't they have thought of a more creative name for their payment service than "s/Apple/Samsung"?

Samsung pay uses tokenization so is considered EMV. However you cannot tell a samsung pay transaction from magstripe relay.

Samsung worked directly with the banks to deploy a tokenization scheme via the magnetic card swipe system so it would be EMV equivalent. It's not sending your actual card number, but a virtual card number provided by the bank that doesn't have the 'chip required' bit.

I live in Canada and that's what happens with all of my visa/debit chip cards. If you attempt to swipe your card and it, as well as the terminal, are chip enabled then it gives you an error and asks you to insert your card into the terminal.

They could definitely do this, but I don't think any of them do (or will for quite a while). It's perfectly acceptable for a business to continue sending magstripe transactions if they want. The business just takes the responsibility for chargebacks. This would just look like a transaction where either the reader didn't have the functionality or the merchant decided not to use it.

Pretty sure this has already happened to me in the USA. Though, I was scattered at the time and don't remember for certain.

> IIRC from some resarch I did, a decent card provider will reject a magstripe transaction from a terminal with EMV capability if a card is known to also be EMV capable... At least, it could in theory.

That's how it works for all countries other than the US. In the US EMV capable terminals are not common so transactions in the US are typically permitted no matter if magstripe or EMV. This is why starting with October this year the US are finally making the switch to EMV and once that roll-out is complete, magstripe transactions could (theoretically) be either disabled or severely limited. For instance you might have to confirm a magstripe transaction with a text message.

Agreed. I think for it to truly work it would require support from the terminal in the form of letting the processor know if the terminal does or doesn't support chip & pin.

If the terminal doesn't support it the processor always lets it through. If the terminal does support it the processor only lets it through if using chip and pin. Then again, maybe there won't be non chip and pin terminal much longer so that won't matter.

> Sure it could check for the actual chip, but credit card fraudsters aren't creating fake cards that include the chip so that wouldn't help either.

Should that read 'credit card fraudsters are creating fake cards that include the chip' ?

I always assumed that chip/pin being used was at least checked by the credit card company. The machine should be telling them if it supports chip/pin, and the cc company independently knows all the information about your card, so... urrrrgh.

It's easy. Make card number ranges that must have chip and pin.

I can't claim to spend a ton of time in a huge variety of countries, but in the past year I've been to Iceland, England, Wales, Scotland, Italy, France, and New Zealand, and I can't remember anywhere I had to use the EMV chip in my credit cards except places like parking garages that didn't have the physical facility for a mag stripe swipe. Every retailer terminal could read a magstripe.

More annoyingly, whether I swiped or dipped, a signature was required. Except, again, where there was no way to sign (parking garages). Then, magically, my PIN was "good enough".

I went out of my way to get EMV cards last year due to upcoming trips, because I had only been overseas sporadically over the past decade and assumed that the magstripe was gone. It was not. If anything, merchants seemed more able to deal with them than 10 years ago, where I occasionally had a clerk who couldn't figure out whether to swipe extremely slowly, or quickly enough to set fire to the equipment.

You're obviously not in America, then. Out of the 6 cards in my wallet only 2 even have a chip yet (my bank promises my most frequently used card has a chip equivalent in the mail).