Welcome Guest. | Log In | Register | Membership Benefits
Dark Reading's cs-island Weblog

Topics:   CS Island
  • |   Email this page E-mail
  • |  Print Print
  • |   Bookmark and Share

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.

Sep 02, 2009 | 11:09 AM | 

By Sara Peters
Dark Reading
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.



Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dark Reading encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dark Reading moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Dark Reading further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
Subscribe to RSS









  1. Cookies, Social Media And FireSheep
  2. SMB Guide To Credit Card Regulations, Part 2: The Low-Hanging Fruit
  3. HP And The Scary Corporate Fifth Column Concept
  4. Taking USB Attacks To The Next Level
  5. NoSQL: Not Much, Anyway
  1. Taking Cybersecurity Lessons To The Bank
  2. Researchers See Real-Time Phishing Jump
  3. 'BlackSheep' Sniffs Out Firesheep WiFi-Hacking
  4. Slideshow: Ten Free Security Monitoring Tools
  5. A Different Spin On Sleuthing Stuxnet
  6. M&A Activity Muddles Database Security
  1. Secure Managed Web Hosting Saves 960.gs from Malicious Hackers
  2. Access Governance as a Business Service: An Integrated Strategy for Automation with ITSM
  3. Business Driven Access Management and Governance: Simplifying the Delivery and Governance of Access Throughout
 
 


 
  Ars Technica
Boing Boing
Channel 9 Forums
CRN Blogs
Dr.Dobb's Portal: Blogs
Engadget
Gizmodo
GrokLaw
  Lifehacker
Schneier on Security
Slashdot
TechCrunch
Techdirt
Techmeme
Valleywag
 
  February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
  May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008