Bags are packed, See you in Chandler!

Send me a note or stop by booth #30 if you are planning to attend the 2008 ATM Debit & Prepaid Forum.

Here is a snapshot of what my desk looks like: you can see a magtek USB card reader and a few magnetic striped cards; expired pre-paid credit, gift and merchandise return cards that used for testing purposes here.

I’ve been developing some small tools that allows for us to send transactions via a swipe in a .NET windows based application as well as in a Java Web based version to a test instance of OLS.Switch. I used to (and still do) just pipe binary message dumps over netcat pointed to our OLS.Switch’s configured server port for this specific message format.

for example:

$ cat visa_credit_sale.dump | nc 192.168.1.50 33000

where visa_credit_sale.dump would just be a binary file of the message

$ hd visa_credit.sale.dump

would look like this (intentionally blurred and is a test card number)

Here is a shot of the Virtual Point of Sale System:

and a shot of the Virtual Terminal:

Basically you can swipe a card or key-enter a card on the virtual terminal and depending on the configuration of OLS.Switch - (I’m using bin based routing here in this test setup)

Cards that start with:

• 4 - Visa
• 5 - Mastercard
• 6011 - Discover

go to our FDR North (ChasePaymentTech) Simulator and and return a simulated response.

• 3 - Amex

go to our American Express Simulator

• 7 - Stored Value

go to our Stored Value Systems Simulator

• 6 - OLS Stored Value

get switched to our own instance of OLS.Issuer - our authorization host which is not a simulator.

The vPOS and VT are sending in messages in the Visa K/Visa D or otherwise known and Visa Gen II message format (one of the incoming message formats that we support from the device side) and depending on the card type, we are building the appropriate outbound message according to the interface specs (generally an ISO8583 variant), hitting our simulators to get different responses based on amount prompting or in the case of the OLS Stored Value cards, it uses the card files, velocity and limit checking, card status and other authorization rules to authorized the card.

The neat thing? an end-to end transaction take less then 50ms on a sub $1000.00 test server on a local lan.

Here is a link to a PDF that shows the full transaction flow.

The Payment Systems Podcast has created more then 3 recordings so I consider that a success :)  While we have a pretty specialized focus - we are getting some good feedback and we hope that everyone enjoys the podcasts, we have some good ideas for content, and will try to perform a recording when we are at the ATM Debit and Prepaid Forum or at least one that covers what we heard and saw at the show.

I was recently asked what equipment that I use to create and produce the podcast, my setup is pretty simple, my Macbook using GarageBand and a Samson C01U condenser microphone. The only problem that I’ve dealt with have been some volume issues (addressed in some sound preferences in GB) and setting the microphone as a stereo device rather then a mono - the last 2 recordings were left channel only because of this :)  Here is a snapshot from the recording of episode #2.

PCI DSS version 1.2 was released today, I blogged a little about the changes based upon a earlier PCI 1.2 summary document here and rather then duplicate the excellent work of others, I’ll point you to Mike over at www.pcianswers.com  who does a great breakdown on the changes between PCI DSS version 1.1 and PCI DSS version 1.2 audit procedures.

From the PCI SSC Press release on PCI 1.2:

This latest version is the culmination of two years of feedback and suggestions from its industry stakeholders and is designed to clarify and ease implementation of the foremost standard for cardholder account security. Version 1.2 is effective immediately and version 1.1 of the standard will sunset on Dec. 31, 2008.

Go read the changes here.

Since becoming an Obopay user, I’ve noticed that very recently that they have implemented a multi-factor authentication for transactions initiated from their mobile website.  I needed to pay $2.14 to a friend who picked up a lunch for me yesterday: Monday is $1.00 Maid-Rites :)  When sending the money I received the following (see picture on left) screen, and my phone rang shortly after - requiring me to type in my obopay PIN to complete the transaction.  Very well done!  I know that Chase uses a similar process (out of band verification) for its Internet banking. Authentify is a company that provides a service like this — please leave a comment below if you know of any others.  Also - if you noticed in the picture I’ve updated my Nokia E51 to a Nokia E71 - a very nice phone - (I really missed the QWERTY keyboard)

I picked up a copy of Bruce Schneier’s  "Schneier on Security" this week, I’ve read quite of few of his other books and enjoy how he challenges security practices and conventional wisdom.  The very first book I read from him to help me understand encryption techniques related to payment systems was Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition also known as the cryptography Bible and later Practical Cryptography for a brief refresher. I’ll likely post a review and comment on any payment systems related topics in this book, but I first need to finish my current read: The Snowball: Warren Buffett and the Business of Life.

Scott Fendley writes a good post on Check Fraud and Information Security at the SAN’s Internet Storm Center Handlers Diary after watching Catch Me If You Can which is inspired off of Frank Abagnale Jr.  early life of thievery and deception.

We have developed interfaces to external 3rd party check authorization providers as well as developed a local check authorization module which is a blacklist based on a bad check subscription service, and velocity checking.  But many of Scott’s steps to reduce risk based on his research are not as much based on accepting checks, as much as being the check writer, and are not all logical controls but preventative and detective procedures to reduce risk of check fraud. Some good points here.

Also:

Frank’s Book The Art of the Steal is a good read and add this [SAN's Internet Storm Center Handlers Diary] to your RSS Feeds and regular reading if you are a security manger/analyst.

According to CNet and a few Visa Press Releases:

• Visa and U.S. Bank to Launch Visa Mobile Money Transfer Pilot

• Visa and Nokia Working Together to Deliver Payment Applications for Next Generation Mobile Devices

• Visa to Develop Mobile Payment-Related Services for Android Platform

We see a P2P like money transfer service for card and mobile phone holders:

Under a pilot program with U.S. Bank, which is scheduled to begin by the end of the year, Visa will offer mobile money transfers from one Visa cardholder’s account to another. A U.S. Bank Visa cardholder would use a Web browser on their phone to access funds and transfer it directly to the recipient’s account. The recipient could then withdraw the funds from an ATM machine, or use the money to make purchases.

and working will cell phone manufactures Google Android Platform.

The Visa-Android deal calls for Chase Visa cardholders to use their Android phone for not only transferring money, but also to receive real-time email alerts when transactions happen on their Visa account, receive offers from merchants, and view images on Google maps to find the location of those merchants who are offering the specials. The Google-Visa deal is expected to begin sometime by the end of the year.

and we begin to see the merging between the card and a phone as a contact-less payment vehicle at the point-of-sale.

The Nokia 6212 classic includes integrated Near-Field Communications chipsets (NFC) which lets the mobile device behave like a contactless payment card, where consumers simply wave it within a few inches of a special point of sale reader to complete a Visa transaction. Nokia and Visa first demonstrated NFC technology in December 2005 with the launch of the first large scale NFC trial in the United States at the Phillips Arena in Atlanta.

Andy and I meet with Randy San Nicolas to talk about Card Management in a short minicast.

We reference these diagrams:

Randy’s Blog www.prepaidenterprise.com was inspired by this minicast

Intro & Exit Song: Honcho Graham From Birmingham by Josh Woodward

Standard Podcast [16:30m]: Play Now | Play in Popup | Download

Blogs and email links

Andy’s : www.andyorrock.com

Dave’s : www.paymentsystemsblog.com

Randy’s: www.prepaidenterprise.com
email  : podcast@paymentsystemspodcast.com

I guess it has been almost two years now, that a news story and security researcher blog post, pointed out a vulnerability in certain types of ATM Machines. The vulnerability relates to "PCI requirement #2 - Do not use vendor-supplied defaults for system passwords and other security parameters" with a few brands of ATM machines ( generally the smaller standalone ATM’s you see in convenience stores and sold by ATM ISO’s and their agents ) whose service manuals were accessible online, and ATM operators failing to setup the ATM’s in a secure manner.  I remember googling and finding the default passwords and instructions for these. With the service manual and passwords, a person was able to reprogram the value of the ATM cassettes. telling the ATM Machine that the $5 cassettes had $20’s and doing a withdrawal

Today - Wired notes that the first bust for ATM Reprogramming Scan netted its first two arrests.

It took a high-speed chase and some gunplay, but two men in Lincoln, Nebraska, are the first to face felony charges for using default passcodes to reprogram retail cash machines to dispense free money.

Jordan Eske and Nicolas Foster, both 21, are in Lancaster County Jail pending an October 1st arraignment. They’re each charged with four counts of theft by deception, and one count of computer fraud, for allegedly pulling cash from privately owned ATMs at four stores in the area. The pair allegedly reprogrammed the machines to believe they were loaded with one-dollar bills instead of tens and twenties. A withdrawal of $20 would thus net $380.