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.


01:44 AM
Sara Peters
Sara Peters
Connect Directly

Information Cards Are Awesome; But Are Identifying Parties Really Ready To Do This Right?

Perhaps the greatest thing about information cards is that they might finally free us from the purpose-defeating and idiotic practice of using Social Security numbers as a nigh-universal identifier. But it won't work unless the Identifying Parties find a way to balance security with portability, and can smartly manage distribution, expiration, and destruction.

Perhaps the greatest thing about information cards is that they might finally free us from the purpose-defeating and idiotic practice of using Social Security numbers as a nigh-universal identifier. But it won't work unless the Identifying Parties find a way to balance security with portability, and can smartly manage distribution, expiration, and destruction.As InformationWeek reported, Microsoft released a white paper calling for all hands on deck to support an "Information Card system that uses an interoperable vendor-neutral framework for identity management and provides end users with direct control of their digital identities."

Here, freakin, here! Nevertheless, there's still a ways to go before information cards are really a viable solution -- most of the barriers are merely administrative peccadilloes that need to be sorted out by the parties providing and verifying identity data.

A few words about Social Security numbers... As I've griped about before, the big problem with using SSNs in identity management is that we tend to use them as though they're a "something-you-are like" -- like your fingerprint or your retina, valued for being individual, unchangeable and nigh-impossible to copy -- but in actuality an SSN is just a "something-you-know," like a password....

...Except that an SSN is worse than a password, even worse than useless as an identifier. First of all, it's easy to brute force: always nine characters (unless it's truncated, and then you may only need four) and only 10 possibilities for each character. Second of all, unlike a fingerprint, (or a driver's license number, or a bank account number, or really just about any piece of personal data) there is no way to verify that the Social Security Number you've provided is actually yours.

Why is it impossible to verify? Because the Social Security Administration will not tell anyone what SSN belongs to whom, apparently because it would jeopardize individuals' privacy and the security of the numbers.

The administration won't even tell Fair Isaac, the company that maintains all those records that TransUnion and Equifax use when calculating your credit score. This is at the root of the whole financial fraud conundrum. Right now, Fair Isaac might very well have credit report data for three different people, with three different names, all using the same Social Security number. Fair Isaac knows that at least two of those are fraudulent, but there's no way of knowing which one, because the Social Security Administration will not tell them. The only really legitimate way of proving that SSN is yours is by providing, in person, a hard-copy Social Security card -- which, by the way, never expires, carries none of the anti-spoofing technology now in driver's licenses or passports, and isn't even considered a valid proof of U.S. citizenship when you're applying for a passport.

The beautiful thing about information cards is that they make this SSN nonsense disappear, by using an entirely different logic (translation: they use logic, period) than that used by the Social Security Administration and those parties that accept/require SSNs as proof of identity. With an information card, the information itself isn't very important -- in some instances it might actually be entirely unnecessary. The important part is that the information has been verified by a trusted identifying party. "An information card from a bank may not need to contain the user's account number. All it needs to do is provide a digitally signed confirmation from the bank that says "yes, I really am the bank, and yes, this user really is who he says he is, and yes, indeed, he does have an account with us [and maybe even] yes, he's got the money to pay for whatever it is he's purchasing through your Web service." An information card from the Department of Motor Vehicles might not need to give a gambling Web site your birthdate; it simply needs to say "I'm the DMV and I confirm that this person is at least 18 years old."

In this way it's better than the hard-copy IDs in your wallet. The relying party gets the information it wants, without forcing the user to toss around personal data willy-nilly.

However, the trouble with information cards is that they're simply digital files, which means they can be copied by someone other than the identifying party, stored on several devices, and transmitted over insecure channels.

InfoCards, like encryption keys, must be both transmitted and stored securely. (Can one never escape the slings and arrows of key management?) If an attacker gets hold of those InfoCards, then the identifying (verifying) party will, unknowingly, attest to the fraudulent claims of the attacker without the attacker needing to know a single piece of the victim's personal information.

So, first off, the user and the relying party must exchange InfoCards over a secure connection to avoid a nefarious man in the middle from snatching a copy of that card. Hopefully, encrypted communication of keys is something relying parties are doing already.

Second, those InfoCards must be locked up tight while they're simply at rest. The "InfoCard" folder residing on a user's desktop could be encrypted, or the InfoCards could be stored and encrypted in the client machine's TPM chip (Trusted Platform Module).

The trouble there is that -- unlike the cards in your wallet -- you're not willing to strap your machine to your back and carry it with you everywhere you go. (Though some of us -- and I'm not naming names -- kind of do lug our machines everywhere, even to that concert I went to last week.)

The infocards must be portable, so it's likely they'll be stored on a smartcard or an encrypted USB stick.

Yet they must also be secure -- so that portable device containing the issued information card should be obtained in-person, directly from the identifying party. (If you lose it you have to go back in person, just like if you lose your driver's license or your birth certificate.) Further, privileges to create, copy, or edit that information card should be exclusive to the identifying party

However, you don't really want to loop a zillion USB sticks alongside your house keys. So it would be great if you could put them all on one stick. However, if you're not permitted to copy all of those information cards onto one handy USB stick, then you must hope that the identifying parties will agree to place the data onto the USB stick you provide.

It sounds like all this calls for interoperable standards. Hopefully the collaborative work being done by Microsoft and the Information Card Foundation will help us move in that direction.

InfoCards are awesome, far better than the current options and entirely worth the effort. But, like many of our most promising security technologies, administrative hurdles must be overcome before the technology can really take off.

(More on this stuff in our Identity 2.0 Summit at CSI 2008: Security Reconsidered.)

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
I 'Hacked' My Accounts Using My Mobile Number: Here's What I Learned
Nicole Sette, Director in the Cyber Risk practice of Kroll, a division of Duff & Phelps,  11/19/2019
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-11-21
Multiple cross-site scripting (XSS) vulnerabilities in Chyrp before 2.1.2 and before 2.5 Beta 2 allow remote attackers to inject arbitrary web script or HTML via the (1) content parameter to includes/ajax.php or (2) body parameter to includes/error.php.
PUBLISHED: 2019-11-21
The web administrative portal in Zhone zNID 2426A before S3.0.501 allows remote authenticated users to bypass intended access restrictions via a modified server response, related to an insecure direct object reference.
PUBLISHED: 2019-11-21
Multiple cross-site request forgery (CSRF) vulnerabilities in Synametrics Technologies SynaMan before 3.5 Build 1451, Syncrify before 3.7 Build 856, and SynTail before 1.5 Build 567
PUBLISHED: 2019-11-21
rConfig 3.9.2 allows devices.php?searchColumn= SQL injection.
PUBLISHED: 2019-11-21
An issue was discovered in Oniguruma 6.x before 6.9.4_rc2. In the function gb18030_mbc_enc_len in file gb18030.c, a UChar pointer is dereferenced without checking if it passed the end of the matched string. This leads to a heap-based buffer over-read.