Skip to main content

Amazon PayPhrase, a secure way to pay

I've been hearing about Amazon PayPhrase for a while, and finally received official news letter in last month. Here I'll skip the part about what is PayPhrase and how does it work, I'm sure the official website describes it with words thousands times more accurate and understandable than what I can do. Rest of this article talks about why I think PayPhrase is a secure way to pay.

"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.

Comments

Post a Comment

Popular posts from this blog

Spring, Angular and other reasons I like and hate Bazel at the same time

For several weeks I've been trying to put together an Angular application served Java Spring MVC web server in Bazel. I've seen the Java, Angular combination works well in Google, and given the popularity of Java, I want get it to work with open source. How hard can it be to run arguably the best JS framework on a server in probably the most popular server-side language with  the mono-repo of planet-scale ? The rest of this post walks through the headaches and nightmares I had to get things to work but if you are just here to look for a working example, github/jiaqi/angular-on-java is all you need. https://github.com/jiaqi/angular-on-java Java web application with Appengine rule Surprisingly there isn't an official way of building Java web application in Bazel, the closest thing is the Appengine rule  and Spring MVC seems to work well with it. 3 Java classes, a JSP and an appengine.xml was all I need. At this point, the server starts well but I got "No ...
Post a Comment
Read more

Customize IdGenerator in JPA, gap between Hibernate and JPA annotations

JPA annotation is like a subset of Hibernate annotation, this means people will find something available in Hibernate missing in JPA. One of the important missing features in JPA is customized ID generator. JPA doesn't provide an approach for developer to plug in their own IdGenerator. For example, if you want the primary key of a table to be BigInteger coming from sequence, JPA will be out of solution. Assume you don't mind the mixture of Hibernate and JPA Annotation and your JPA provider is Hibernate, which is mostly the case, a solution before JPA starts introducing new Annotation is, to replace JPA @SequenceGenerator with Hibernate @GenericGenerator. Now, let the code talk. /** * Ordinary JPA sequence. * If the Long is changed into BigInteger, * there will be runtime error complaining about the type of primary key */ @Id @Column(name = "id", precision = 12) @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "XyzIdGenerator") @SequenceGe...
4 comments
Read more

Project Euler problem 220 - Heighway Dragon

This document goes through a Java solution for Project Euler problem 220 . If you want to achieve the pleasure of solving the unfamiliarity and you don't have a solution yet, PLEASE STOP READING UNTIL YOU FIND A SOLUTION. Problem 220 is to tell the coordinate after a given large number of steps in a Dragon Curve . The first thing came to my mind, is to DFS traverse a 50 level tree by 10^12 steps, during which it keeps track of a direction and a coordinate. Roughly estimate, this solution takes a 50 level recursion, which isn't horrible, and 10^12 switch/case calls. Written by a lazy and irresponsible Java engineer, this solution vaguely looks like: Traveler traveler = new Traveler(new Coordinate(0, 0), Direction.UP); void main() { try { traverse("Fa", 0); } catch (TerminationSignal signal) { print signal; } } void traverse(String plan, int level) { foreach(char c:plan) { switch(c) { case 'F': traveler.stepForward(); break; ca...
Post a Comment
Read more