Slashdot Mirror
Magnetic Stripe Snooping at Home
pbrinich writes "Have you ever wondered what information is actually stored on all those cards you have in your wallet? Well, it turns out you can find out yourself! An excellent project, Stripe Snoop started by Billy Hoffman, a Georgia Tech computer science student, contains schematics, source code and a wide variety of information about the standards used to store all sorts of information on your magnetic cards."
*puts on tinfoil hat*
ROMANES EUNT DOMUS
Gives new meaning to the Capital One tagline "What's in your wallet?"
One man's Funny is another man's Offtopic.
Since one of the listed articles talks about common security blunders with cards, it's time to start the over/under pool on how long it takes before this guy gets shut down by some corporation claiming DMCA violations.
I call one week.
I don't think articles such as this one will bring anything new to those who are in the business of credit card stealing. But it should serve as an eye-opener and for raising awareness for the average card user. Being a little more careful with that card should help a lot, I guess. Besides, I let the bank use my money for a reason, right? They should take the risk on themselves...
Stripe Snoop was discussed in detail by its author on a show called Binary Revolution Radio awhile back. You can download the ep, #56, at: http://www.binrev.com/radio/archive.html/ -enjoy, it's a really good show!
I'm just shocked at what *isn't* on my cards. For example, every time I go to my bank's ATM, I have to indicate whether I want to do business in English or Spanish.
Well, if you were the engineering committee assigned the task of defining the standard data structures to be placed on all ATM cards, thinking about account codes, card verification codes, etc., and realizing that you have limited space to work with without adding more tracks (meaning more expensive readers and perhaps even slightly more expensive cards), would it have occurred to you to put the cardholder's language preference in there?
I can tell yout that it wouldn't have occurred to me. And these data layouts can't be changed without going through a formal standards process, because they have to work in every ATM in the world (and now at many grocery stores, department stores, etc.).
So, I'm not surprised at all that that data isn't there. If you want to be surprised by this, you should probably be surprised that the bank didn't choose to store your language preference in their database and then look it up when you swipe your card. That's the sort of feature that a bank can offer to its own customers at its own ATMs without having to get the rest of the world to agree.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
How easy would it be to edit the data on the strips?
For example, would it be possible for me to take my magnetic bus ticket and easily add another 10 trips to it?
Last I checked, my PINs are by card. My PIN and my wifes PIN are different, but access the same accounts. At least for my financial institution, the pin is stored on the card, but in tripple DES encryption. When I perform a transaction, the pin I enter, and the encrypted PIN are both sent to my bank, which encrypts the PIN I enter with thier key, and compares them. No matchee, no money. When I changed my PIN a few years back, they punched my account data into a terminal, I put in the pin I wanted, and then swipped the card. When I walked back to the loby, my card worked with the new PIN, no problem.
According to PayByTouch, the phone number is used as an index to speed fingerprint matching. The PBT computer located at the point of sale device turns the fingerprint data into a hash on the spot prior to sending the request over the network, so the "clear" fingerprint isn't stored or sent anywhere.
I personally thought customers would find "fingerprinting" to be too Big-Brotherish, but many pilot customers preferred the idea of using a fingerprint over carrying a wallet full of credit cards and shopper loyalty cards. But at the time we looked at them, Visa refused to certify them as being as secure as a mag stripe, so the idea died around here.
John
"Ok, that last part isn't true"
What, your children are ugly? Such honesty is refreshing.
"As God is my witness, I thought turkeys could fly." A. Carlson
It can't be "brute forced" or "cracked", any more than you can tell what the OTP enciphered message "htpn juio gowew" says without the pad. In modern banking systems it's part of a two factor system, in which you need the algorithm plus ANY TWO of the following in order to figure out the third
* Real PIN (typically stored in customer's brain, sometimes also on a PostIt stuck inside their desk drawer)
* PIN offset (stored on magstripe of card)
* Stored PIN from database (stored in a secure machine at the bank, probably along with your current balance)
You can imagine that the function used is XOR, but actually there are various methods that could work, and I've never investigated which one is used. However this system lets several moderately clever things happen...
1. You can have two cards (e.g husband and wife) for the same account with different PINs, yet store only one PIN in the database
2. ATMs can change the PIN by knowing your old and new PIN, then applying the changed offset to the magstripe.
3. By leaving the PIN unchanged and issuing a card with a different offset the bank can send you a new card, with a new PIN, without instantly disabling your old card and PIN.
4. Knowing the PIN, and having a valid card number are not sufficient to validate yourself to the ATM network. You don't know the offset that goes with that PIN, you'd have to steal (or at least read) the customer's card to get a valid offset.
5. The real PIN is never sent over the network. So if you have an opportunity to eavesdrop on bank network traffic you don't learn the PIN for anyone's card.
This is actually pretty clever stuff, the banks can be many things, but they're not stupid, you don't last long in financial circles if you are.
I'm an undergrad student in the University of Maryland system. I managed to write some simple C and Perl programs a while back for a reader I obtained, and ran quite a few cards through them. I found that our university issued ID cards have our social security numbers stored on them, unencrypted. A friend filed some public information request acts requesting to know if the university stored data such as the time and locations of card swipes, and if that data was attached to the student in any way. After initially denying this, the university eventually admitted that they do store data, and sent the guy a copy of his records, which indicate to the second when and where he swiped his card, in addition to when he went to the gym, how much he bought at the dining halls, etc. So much for privacy. I'm no engineer or programmer, and I was able to do this fairly easily; it can't be that hard to build an intercept and install it within a reader that's attached to a door, and voila - hundreds of SSNs. We're trying to contact some people in the school media and administration and have something done.
"Anyone who [rips a CD] is probably engaging in copyright infringement." - David O. Carson
When you key your PIN, the PIN pad accepting it will encrypt the PIN along with other transactional information plus its own serial number using a key injected securely by a representative of the issuing bank.
This blob plus the other data is transmitted to an authorizer, where the account is looked up and a local copy of the blob is created. If it matches the incoming blob, it's a go.
The bank almost certainly did not encode your card in the scenario you described above. Encoding is usually done with a machine-fed stripe writer, and is almost never done by hand-swiping the stripe anymore. (The timing is usually better on machine fed devices.) What the bank most likely did was to generate a blob similar to the one I described above for transmission to their authorizing computer, who immediately stored it and activated it for use.
Yes, the original intent of mag stripes was to enable offline transactions. However, bad guys quickly figured out how to read stripes and forge PINs, so everyone went to strictly on-line authorizing in the early 1980s.
John
wouldn't it be interesting if this were to cause a groundswell of support for the recently proposed RFID credit cards?
First, they're not RFID cards, they're contactless smart cards, which are a very different. Different frequency, different range, different capabilities, different protocols, and very different security.
Second, smart card credit cards are a good thing, and you as a credit card user should want them because they'll reduce fraud. Granted, the banks and merchants mostly bear the brunt of the fraud, not the cardholder, but since all of the money ultimately comes from our pockets that's a distinction without a difference.
Finally, your implied notion ("ack") that contactless smart cards are a bad thing for cardholders shows that you don't know anything about them. A fully-implemented EMV card:
The security in these cards is very well thought-out and banks have zero interest in intruding on your privacy, because it would piss you off. If you don't believe they're careful with your privacy, consider the fact that they already know about every purchase you make with any credit card -- how often do you get marketers calling you because they got information from your bank about a recent purchase you made on your credit card?
If you don't care to believe me about how the security is designed, please review it for yourself. Complete EMV specifications are published on the EMV web site at http://www.emvco.com.
I'm a security expert of sorts -- and fairly paranoid by nature -- and the main concerns I have with this technology will arise if the US banks decide not to fully implement the technology.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Q: Why did you release Stripe Snoop under the GPL?
A: Well, its not because I like Richard Stallman, thats for sure. I don't believe that all code should be Free Software,and think he is pretty much a coding communist. One of the reasons Stripe Snoop was created was the lack of cheap or quality magstripe software, especially that would run on Linux. I have worked very hard on Stripe Snoop, and the last thing I want are the very companies that have expensive, crappy software from using my code and not contributing code themselves. In this regard the GPL provides the protections I want, even if I disagree with most of the creator's politics.
Interesting to see a "security expert" (see earlier post--I can't verify this opinion) who thinks RMS is a code communist.