Posts Tagged ‘payment’
In 2010 I was less focussed on programming articles on the blog than previous years, still I have managed to create some interesting articles with code in 2010. This is an overview of the activity:
The only questions that are asked in the Daily Scrum, aka Stand-Up, are: What…
UPDATE: GMail has introduced my number 3. YEAH! (Gmail introduces Priority In…
I like YouTube, and often subscribe to new channels and unsubscribe after a w…
Since I started working for my company I’ve been exposed to PCI DSS (Pa…
I don’t understand why url expansion after url shortening is such an is…
VeriSign – Personal Identity Portal is a OpenID provider with multiple …
Image source D’Arcy Norman
Since I started working for my company I’ve been exposed to PCI DSS (Payment Card Industry Data Security Standard), “It was developed by the major credit card companies as a guideline to help organizations that process card payments prevent credit card fraud, hacking and various other security issues.“1 There are only a small amount of requirements that need to be implemented, although these can be pretty substantial for some customers. I can also be difficult to understand the details of these 12 requirements for compliance.2
Being a programmer by nature I’ve often been told that the nuts and bolts of what I do, the part I enjoy, are a little complex. PCI is something different, everybody can understand that credit card data needs to be protected from unauthorized access. Not just credit card data, but all data that could potentially be used in identity theft. Which means that a policy or control needs to be implemented to control this, and note any non-compliance.
PCI is just about protecting your “Cardholder Data“:
I know first hand that most of the banks in the Netherlands, and in most of the world, are quick to discover credit card fraud. They are also quick to payout and correct the issue for the customer, because the chance that customers will loose faith in the bank is high if they don’t. Yet ultimately these customers are still paying for all the fraud committed with all the credit cards. Banks, payment service providers or retail merchants, who have your Cardholder Data, have all the data needed for this kind of financial identity theft and fraud, and more…
It may seem obvious that this data is stored securely, credit card use is ubiquitous. Yet the large banks have had the same problems with data leakage as small retailers, which means the data must be secured from the customer right to the bank who finally processes the payment to avoid this type of leakage. The problem is that payment service providers or merchants have traditionally not done this. They may handle the temporary authorization requests for the PAN or use the Bank Identification Number (BIN) from the card number for routing the payments to the specific issuer, so they may need the number. That’s fine, as long as they store the data securely and have a log of who accessed the data and why the data was accessed.
Now that’s out of the way I can tell you what I’m doing, I’m playing with RSA Database Security Manager [now EOL'd] and RSA Key Manager. Simply put DBSM is a framework which encrypts the data as in goes into the database and decrypts it as it comes out. It’s something that anybody who is paranoid like me had already been doing for a while, but the way I was doing it required me to write custom fragments of code for every application which needed to access the data. DBSM does it transparently, while at the same time checking the users who try to access it, so only the correct users gain access. RKM hooks into this by providing a framework for the policies or controls which grants the correct people/devices/programs a key to lock-up or unlock the data, different policies can be implemented for different types of data or device.
Now you know what I do.
Originally appeared here.
I mentioned the insecurity of mobile payment systems before in Rabobank has insecure SMS banking. Apparently the RBI has the same reservations I do. In the article RBI puts a temporary halt on Mobile Payment Services explains.
They haven’t stopped regular services such as requesting bank balance, but they have halted signing off on permitting projects to go life until the final guidelines have been issued, micropayments and larger transactions.
From the draft guidelines:
It is suggested that the banks issue a new mobile pin (mPIN). [...] Banks and the various service providers involved in the m-banking should comply with the following security principles and practices with respect to mPIN : [...]
Protect the mPIN using end to end encryption
They don’t seem to require One Time Passwords, which I would certainly have as a requirement, and I hope they don’t consider A5 to be end-to-end encryption. Nokia and Visa already started working on a secure payment system in 2007 using RFID.1
First I’ll go through the list that was published earlier on Mashable here. The only ones that seem to be dead are eHotPay.com, FastCash.com, LibertyDollars.org, Netpay.com (Search Engine Trap), paychest.com (became flushaway.com, I prefer the Mooncup), payingfast.com, Postepay.com, Qchex.com (Under preliminary injunction from FTC) and sendmoneyorder.com
They missed iDeal, the Dutch system which is based on the knowledge collected when the Dutch banks had their own deals with PayPal. At that time PayPal was so full of holes that it never would have passed European Banking Regulations.
Read the rest of this entry »
The Rabobank has a new service called Rabo SMS Betalen, the purse can be accessed by SMS.
- Alice sends a message to 6689 with the phone number and amount in the body, either +316-<number> or 06-<number>
0612345678 15 Thanks for the money, Bob.
- Alice receives a confirmation SMS from 6689 with an OTP (One Time Password)
- Alice sends the OTP back by SMS to 6689 confirm the transaction
- Bob, the recipient, receives a confirmation SMS from 6689 that money has been transferred from Alice’s phone number
There are a number of issues with this, primarily that it is possible to perform a man-in-the-middle attack on this system with less than $1000 worth of equipment.
From GSM Security:
GSM uses several cryptographic algorithms for security. The A5/1 and A5/2 stream ciphers are used for ensuring over-the-air voice privacy. A5/1 was developed first and is a stronger algorithm used within Europe and the United States; A5/2 is weaker and used in other countries. Serious weaknesses have been found in both algorithms: it is possible to break A5/2 in real-time with a ciphertext-only attack, and in February 2008, Pico Computing, Inc revealed its ability and plans to commercialize FPGAs that allow A5/1 to be broken with a rainbow table attack. The system supports multiple algorithms so operators may replace that cipher with a stronger one.