"Secure" is a very mirky word. This morning I went to a website of my favourite croissant store, picked a yummy cranberry cream cheese croissant and checked out. A little PHP page pops up, "select credit card XXXX-XXXX-XXXX-8841 or input a new card". This small page made me nervous for the rest of the day. To improve customer experience of buying a 2$ croissant, this shaky little home-made PHP website decided to keep my credit card information in their tiny MySQL database, probably running on a windows machine in store owner's house, a machine where an 9-year-old boy plays video games. Obviously, even though the URL starts with https, online payment in this croissant store website is not secure. Even if I choose to input credit card number for every check out and never let the website remember my card, I wouldn't feel secure either because my card number would be sent though the network back and forth to the PHP website every day. It seems neither option is secure to me. It seems as long as I have to type in my credit card number in a text box that I don't trust, I wouldn't feel secure.
To solve this problem, many companies came up with a middle man solution where credit card information is input and stored in a middle man that credit card companies certifies as "secure", and a token is created to associate with card numbers and user credential. This way the token, combined with restricted user credential provides enough information for the middle man to process a payment transaction. And the croissant store system can't see anything but the token, and token is not a secret. However this approach has its defects.
- Now on top of user name, password, secret question, birthday and blah, customer has to remember one more thing called token, which is longer and more boring than a credit card number.
- This approach is basically cheating in front of PCI compliance. It moves responsibility of secret keeping from a good PCI compliant middle man, that has to provide all pieces of secrets(card number, expiration date, billing address, CVV2, etc) securely, to the home made PHP system that protects everything with weak user name and password. When user, password and token is compromised, nothing stop fraud no matter how strong the middle man is.
There are all kind of creative and weird ideas companies came up with to walk around these two problems. Some invent another kind of card with token on it. Some invent small physical device with strong encrypted credential and token.
Amazon PayPhrase doesn't completely solve the two problem but it deals with it in a mild and comparatively less risky way.
- The token is a phrase + four digit pin, which is more exciting than a long series of numbers
- PayPhrase is also associated with shipping address and receiver. When it's compromised, hacker can't ship stuff to himself anyway.
- Customer can set limit on PayPhrase. The damage of compromised phrase can be limited.
- And of course, it has the benefit of all the token-based solutions, hiding card information in bullet proof Amazon payments system, which is PCI-compliant. And the merchants integrated with Checkout By Amazon supports PayPhrase genetically.