Safely wielding a +10 SSN.
Everyone agrees that SSNs are overused and overexposed today, both as unique identifiers and as authenticators, but nobody is able to step up and tell J. Random Corporation how to stop using them. You can’t—not when there is no other immutable, unique identifier for an individual in these here United Snakes. There’s nothing that follows you from state to state, from birth to death, through marriage and divorce ... except taxes. (Yep, and taxes follow you even after death.) This is why the IRS is the best tracker on the planet. There’s nothing like a government’s incentive to make sure it is getting its hands on as much money as legally permitted ... but I digress.
Please don’t bleat “federated identity management” at me. There’s no economic incentive to make that work (except of course for the vendors selling it). People won’t buy it and use it until it becomes a political necessity (read: economic, imposed by politicians). And that won’t happen until enough people are outraged by identity theft to pressure legislators into doing something about it. Just telling organizations to “protect personal data” won’t work when they don’t know how to stop using it like monograms on towels.
But there are a few guidelines you can offer your particular organization.
First, teach them the difference between identification (telling two individuals apart) and authentication (verifying that they are who they claim to be for the purpose of granting them access to something).
Next, teach them the difference between registering an individual (that is, authenticating them once and then assigning them a unique identifier in your systems) and tracking them thereafter. You might need an SSN for the first part—that is, assuming you even bother to validate that SSN, which most organizations don’t, even if they’re reporting payments to the IRS—but you don’t need it every time you reference that individual later on.
Tell them that if they’re only using an SSN as a unique identifier, and it’s only for the purposes within your organization, they should generate and assign a new ID to that user instead of being lazy and indexing on the SSN in the database and everywhere else. There’s no reason why you can’t tell a customer to reference a customer ID in correspondence with you rather than making him provide his SSN every time. You’re doing a lookup either way, and the strings don’t matter as long as they match.
Unfortunately, if you have to track individuals between organizations that don’t share any common IDs, you’re stuck with the SSN, especially if you’re crossing state lines. I just don’t see any way around that today, and if you can think of one, please speak up.
Either way, for Bog’s sake, tell them NOT to use the SSN or any other personal data just to create a unique login name for a user. And they don’t need to display the SSN for that user every time he logs in. There are SOME braindead practices we can start eradicating right here, right now.
(This post is dedicated to LonerVamp, who poked me at just the right time while I was feeling ornery about this very issue.)
Posted by shrdlu on Friday, September 08, 2006(4) Comments • Permalink •
