Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

9/2/2009
11:09 AM
Sara Peters
Sara Peters
Commentary
Connect Directly
Twitter
RSS
E-Mail
50%
50%

How Much Would You Pay To Never Have To Store PII?

Imagine a world in which you can do all manner of smooth, rich, user-friendly online commerce with mighty security. You can have complete faith in the validity of customers' login credentials and payment data (thereby reducing fraud costs, for starters). You can protect users' privacy...and never need to worry about securely storing -- or even seeing -- customers' credit card data or other legally protected personally identifiable information. Wait 12 to 18 months, and you might just have that.

Imagine a world in which you can do all manner of smooth, rich, user-friendly online commerce with mighty security. You can have complete faith in the validity of customers' login credentials and payment data (thereby reducing fraud costs, for starters). You can protect users' privacy...and never need to worry about securely storing -- or even seeing -- customers' credit card data or other legally protected personally identifiable information. Wait 12 to 18 months, and you might just have that.That's the estimate provided by Roger Sullivan, vice president of identity management at Oracle and president of the Board of Trustees of the Kantara Initiative.

Kantara is a large collaborative organization of players in the identity 2.0 space trying to create standards, increase interoperability, and generally push claims-based identity forward -- in the form of OpenIDs, infocards and SAML assertions -- until it becomes common practice.

The main ideas behind this identity 2.0 stuff are that the parties requesting identity and access credentials -- we call them the "relying parties" -- are given only the information they need, and that the information they are given is provided with very high assurance. Instead of requiring and requesting the user's name, address, Social Security number, credit card number, CVV code, mother's maiden name, etc., before granting them secure access or allowing them to complete a secure transaction, the relying party simply needs to say something like, "Hey, can you pay for this with an account that's actually yours?" Then the party hopes to get a "yes and yes" response that can be trusted because it come straight from the horse's mouth -- the horse being the financial institution that gave this person the account in the first place.

I'm a big proponent of identity 2.0, claims-based identity and access management, assertion-based identity and access management -- whatever you want to call it.

But it isn't without its weaknesses.

One of those weaknesses is the fact that the infocards/SAML assertions themselves could be considered PII. They may not contain a user's name, address, credit card number, SS#, password, etc., but if that one high-assurance credential is all one needs to complete a purchase, then all an attacker needs to do is get his hands on that one credential to start making purchases.

That said, this one credential would, no doubt, NOT be enough for someone to open a new account. UPDATE: I might be wrong on this point. It really depends upon how much information is contained within the credential and upon how rigorous the bank's process is for opening a new account. If anyone's got more perspective on this, please share it.

So if I were a bank and wanted to significantly reduce fraud, it could be in my best interest to start issuing these high-assurance credentials -- infocards or SAML assertions, what-have-you -- to my customers so they stop spreading their account info all over town.

And if I were a merchant, it might be in my best interest to start accepting these high-assurance credentials -- especially if all I needed to do was look at those credentials, see that they're highly trustworthy, allow the user the appropriate access (or permission to complete a transaction), and either basically hand that credential right back to the user without any need to keep it in secure storage (like a bouncer at a bar would do) or pass it off to a third-party who will keep it secure and give me access to the info I need when I need it...

...for a price.

Sullivan says he sees a big business opportunity here. Just as Visa charges a merchant a teeny fee every time it accepts a Visa card as payment for a purchase, it could charge a similar fee for securely handling that payment data. If the financial institutions themselves wanted to get into the action, then they could not only reduce their fraud costs, but they could bring in some extra revenue for providing that service.

Sullivan says that business plans like this are already stirring, and that within 12 to 18 months such a service may actually be available.

There are, of course, plenty of ways that this could go wrong. But at least today, in theory, it sounds pretty good to me.

Sara Peters is senior editor at Computer Security Institute. Special to Dark Reading. Sara Peters is Senior Editor at Dark Reading and formerly the editor-in-chief of Enterprise Efficiency. Prior that she was senior editor for the Computer Security Institute, writing and speaking about virtualization, identity management, cybersecurity law, and a myriad ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/30/2020
'Act of War' Clause Could Nix Cyber Insurance Payouts
Robert Lemos, Contributing Writer,  10/29/2020
6 Ways Passwords Fail Basic Security Tests
Curtis Franklin Jr., Senior Editor at Dark Reading,  10/28/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How to Measure and Reduce Cybersecurity Risk in Your Organization
In this Tech Digest, we examine the difficult practice of measuring cyber-risk that has long been an elusive target for enterprises. Download it today!
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-5425
PUBLISHED: 2020-10-31
Single Sign-On for Vmware Tanzu all versions prior to 1.11.3 ,1.12.x versions prior to 1.12.4 and 1.13.x prior to 1.13.1 are vulnerable to user impersonation attack.If two users are logged in to the SSO operator dashboard at the same time, with the same username, from two different identity provider...
CVE-2020-15703
PUBLISHED: 2020-10-31
There is no input validation on the Locale property in an apt transaction. An unprivileged user can supply a full path to a writable directory, which lets aptd read a file as root. Having a symlink in place results in an error message if the file exists, and no error otherwise. This way an unprivile...
CVE-2020-5991
PUBLISHED: 2020-10-30
NVIDIA CUDA Toolkit, all versions prior to 11.1.1, contains a vulnerability in the NVJPEG library in which an out-of-bounds read or write operation may lead to code execution, denial of service, or information disclosure.
CVE-2020-15273
PUBLISHED: 2020-10-30
baserCMS before version 4.4.1 is vulnerable to Cross-Site Scripting. The issue affects the following components: Edit feed settings, Edit widget area, Sub site new registration, New category registration. Arbitrary JavaScript may be executed by entering specific characters in the account that can ac...
CVE-2020-15276
PUBLISHED: 2020-10-30
baserCMS before version 4.4.1 is vulnerable to Cross-Site Scripting. Arbitrary JavaScript may be executed by entering a crafted nickname in blog comments. The issue affects the blog comment component. It is fixed in version 4.4.1.