In my inaugural post to this blog, I wrote about many of the religious wars that break out today regarding payment security and specifically PCI. In the post I mentioned the OWASP PCI project, which is a solid step in the right direction, but to be clear, payment security encompasses a lot more than just PCI. PCI does a decent job at setting an audit bar for merchants and service providers, but now I'd like to focus on the broader topic of card not present security.
Recently, I was lucky enough to participate and contribute to a new O'Reilly book, Beautiful Security. While I'd love to tell you my chapter out-shined them all, in reality Mark Curphey's contribution on Tomorrow's Security Cogs and Levers was brilliant. Since the publishing, I have been speaking to a lot of people on the topic of payment card security and what I felt were some of its fundamental flaws that needed to be addressed. In my view, the root cause of many of the security pains around online payments is the reliance on a shared secret that is ultimately shared with hundreds or even thousands of parties within the life of a card. If there is a security crack in the armor within even a single organization of these thousands of handlers, the card account may become breached. Within my chapter, I laid out seven fundamental requirements for a new payment security model. They are:
1. The consumer must be authenticated
2. The merchant must be authenticated
3. The transaction must be authorized
4. Authentication data should not be shared outside of authenticator and authenticatee
5. The process must not rely solely on shared secrets
6. Authentication should be portable
7. The confidentiality and integrity of data and transactions must be maintained
OK, so none of these are a revelation, you knew this already. Well that's why I am posting this here. I have since converted my Beautiful Security contribution into a wiki found here. My original writing is a high level design and we now want to take this to the next step. I am certainly not foolish enough to believe there are no flaws within it, nor is it detailed enough yet to implement. This is where the security and payments folks come in. This a call to action to read through the wiki, update it, and begin to flash out the details that could turn this into an actionable payment security system that could be implemented. There's a quick summary of the goals on the wiki home page to address where we are heading. But hey, this is a wiki, so those can change too! If you have some expertise in online payments or information security (I know you do, that's why you're here), please take the time to help out and contribute.
