The AppSec Reanimated series continues! The first webinar took a journey Out of the AppSec Abyss into modern topics like DevOps and cloud environments.
This one highlights A Promethean Struggle to protect two ancient technologies: credit cards and passwords. It takes a look at what PCI teaches us about handling sensitive data and how we might broaden those lessons to authentication. An underlying theme of this discussion is how design choices influence and are influenced by user behavior and the scale of an app.
Protect, Control, Isolate
In order to reign in fraud, card issuers developed the PCI Data Security Standard. It establishes a baseline of controls and processes for handling card data. Importantly, these requirements aren’t just about a point in time like running a pen test or conducting a vulnerability scan, but also about establishing recurring activities.
PCI’s intent is essentially what you’d expect from a DevOps effort — to design and deploy systems that encrypt and control access to sensitive data. These are hardly controversial ideas. What PCI did was introduce common language and requirements for app to meet and so that adherence to those requirements can be evaluated consistently. To make it more forceful, PCI includes consequences for failing this due diligence.
Of course, it’s possible to meet the baselines of compliance and still be insecure. PCI isn’t a guarantee of security — it’s an exercise in managing risk. In order to fully flesh out a security program, you should turn to something like the NIST Cybersecurity Framework.
At a high level, PCI defines six goals that encompass 12 requirements. The goals may seem overbroad, like “build and maintain a secure network” or “protect cardholder data”. But that’s not much different from the kind of guidance you see in the OWASP Top 10. Over time, the standard has responded to feedback, both in terms of clarifying requirements and keeping pace with new technologies. It’s one of the reasons that in-scope PCI systems tend to have better HTTPS configurations than others.
Passwords, Cards, and Innovation
One area where I believe PCI has been successful is where people have been actively avoiding it. Not only might app owners find dealing with compliance a distraction, but auditing systems requires budget and resources. In practice, apps don’t need the card numbers, they just need an authorization to make charges against them.
Thus, if an app deletes and no longer stores card data, then it significantly reduces its PCI burden. (That doesn’t mean it’s absolved of building a secure app, just that PCI won’t hold it responsible for doing so.)
A payments industry has grown up in response to this. So now instead of handling card data themselves, apps handle tokens that point to third-party systems, and they transparently frame third-party forms that handle the collection card data.
This strategy shifts from handling the identity of the card to handling a temporary authorization to charge it. In the event of compromise, access to the authorization token shouldn’t put the card at risk of arbitrary use elsewhere.
Promote Careful Implementation
Currently, NIST is drafting new Digital Identity Guidelines. The guidelines put design forefront by making three important points: make it easy for users to do the right thing, hard to do the wrong thing, and don’t punish mistakes — make them recoverable. A major motivation for this attention to design is to avoid the kinds of failures in encrypted email documented by the 1999 paper, “Why Johnny Can’t Encrypt.”
Delegating identity with protocols like OAuth 2.0 or using SAML for single-sign-on is similar to delegating card handling to a third party. It’s an effective strategy for transferring risk. And it sets a mentality that credit card numbers and passwords should be treated like liabilities that infect the systems they touch.
Of course, the future isn’t magically improved by delegation. Apps still need to protect tokens. There’s always a risk calculation and it’s always important to go through threat modeling exercises to understand what might be changing.
For example, moving to an identity provider or service-based tokens makes the account recovery and password reset processes more complex. When recovering an account, it would be important to know whether an attacker added a service to it under their control. One solution is to educate users about this, and give them a means to manually revoke tokens. Unfortunately, this returns to the challenge of good interface design.
With luck, we won’t see future research with titles like, “Why Johnny and Janey Can’t Recover Their Digital Identities.”
Instead, we’ll hope for a future where breaches are no longer measured in the millions of records. We’ll hope for a future where identity is resilient to phishing, where exposed passwords don’t lead to immediate account compromise, where strong authentication doesn’t require weakened privacy, and people continue to shop in safety.
