But identity fraud is not just about money. The pervasive use of Social Security numbers (SSNs) as an identification mechanism gives an attacker many options. California, for instance, requires a birth certificate (or many other types of documents) and a valid SSN to get driver's license or identification card. With a little effort, one can acquire a state issued identification that can be used for unrestricted travel throughout the country, including air travel. A criminal, terrorist, or general bad guy can leverage stolen credentials in this manner for extended periods of time without the original owner ever knowing about it.

The problem is the permanent nature of an SSN: It can’t easily change without special assistance or circumstances and are good forever, even after you die. It is this trait of permanence that has dictated its use as a unique identifier in so many systems. As a result, we have provided attackers with an ever growing source of vectors where the stolen ID data can be leveraged, as well as an ever growing number of potential targets from which to steal the data. It is this permanence that gives the SSN its core value.

Our current system perpetuates fraud and, by its very design, affords criminals whatever time they need to exploit it. It is a system that exposes us to a number of threats without giving us any power or capacity to manage the associated risks.

So, what’s the solution?

Currently, there are many proposed solutions to the problem of identity theft—all of them dealing with things like punishing those who steal data, punishing those who let the data be stolen, enforcing strict protection mechanisms for systems housing the data, and even the limitation of who can collect what data, and for what purpose. All of these mechanisms will ultimately be ineffective because they do not address the core issue of ID theft: They do nothing to impact the value of the SSN.

Laws that provide for harsher punishment will not stop criminal organizations. And laws that punish those with lax security will not stop the data from being stolen. Those measures only come into play when the criminal gets caught or when the data is already gone. They may provide after-the-fact retribution, but they don’t protect the data.

Forcing companies to have minimum standards of security will help, but it will not stop the data from being stolen. It will make the data harder to get, which will actually increase its value, making the data a more attractive target for criminals who will most certainly find ways of getting it. If something has value, and can be stolen and sold for a profit, then criminals will get to it somehow.

To impact identity theft, the U.S. must implement measures that directly affect the inherent value of the SSN itself. A system that allows a victim of identity theft to change -- or have changed -- their SSN and voiding the "old" number should work. This would allow for SSNs to be verified before a transaction is executed much like a credit card number is validated for purchases. Such a system would have rules to enforce the voiding and expiration of compromised numbers, while maintaining a change log that prevents abuse of the system from a credit history standpoint.

To be successful:

• The process must pay for itself.
• Changes in the Social Security Administration process do not necessarily require commercial applications that use the SSN as a unique identifier to change. Legacy support for business applications must be maintained without change if they so choose.
• Credit history and auditing must be maintained.
• The system must be developed in a way that will guarantee voluntary adoption by the credit agencies.
• The validation process must be paid for by business entities, however, government agencies (like the DMV) must be able to utilize the service for free. In this way, pass-through fees can go to the Social Security Administration for commercial use while authentication bodies can validate data without cost.

Currently, if a breach exposes individuals' data, the company responsible is usually fined. But where do these fines go? What are the funds used for? We may never know. I propose that when a breach occurs (and is verified, of course) that rather than being fined, the responsible company or entity would pay for the process required to void and change the SSNs of the victims.

The voids and reissued SSNs would then be propagated into the credit tracking processes. The current "Big Three" credit bureaus are already in the business of tracking your personal financial activities. And, because it is their source of income, they do it well. Since they maintain your history and give it to others for a fee, they should be the ones responsible for ensuring that their internal change logs are maintained -- after all, it is in their best interest to do so. If their procedures allow for one to delete past credit history by acquiring a new SSN, the value of their services to their customers would be greatly diminished.

The Social Security Administration (SSA) would still be responsible for the overall process of distributing SSNs, and would still be the authority in that regard. However, they would have to maintain their own change log should someone require that their SSN be changed -- but they would only maintain a change history -- it would be up to the credit reporting companies to maintain the data integrity and key references needed to maintain consistent reporting of credit history through SSN changes. They would be responsible for the costs associated with updating their systems and software to accommodate the process.

Consider the following: TransUnion, who holds information on over 500,000,000 people worldwide and who sells that information, is an independent privately-held company. Experion bills out $3.1 billion a year, and has almost $8,000,000 in assets on the books. Equifax, publicly traded on the NYSE, had $1.3 billion in revenue in 2005, yet subcontracts all their customer service to a company in Canada. These companies need to share some of the burden of the solution since they help perpetuate the problem.

Though the SSA would "hold the keys" to the SSNs, the actual SSN change logs could be maintained by two independent entities. The two sets of logs could be checked against each other for data integrity and auditing purposes. The main function of these third-party entities would be to provide authentication and validation of any given SSN and to maintain, administer, and support the “voiding” of an SSN. Though the actual processing would be done by these third-party companies, they would work under the guidance and direct control of the SSA.

Trust, but validate

Once this framework is in place, different bodies could use it to verify the validity of a SSN when required -- this could a history check to obtain some form of credit, a claim of authenticity (as in a requirement to obtain a state ID), or when needed to provide a unique identifier (as in the case of filing income tax forms).

If a non-government entity requires the use of one’s SSN to be used or validated as part of its process model, the first step is for the validation bodies (both of them) to authenticate the status of the supplied SSN. This would be done for a small fee- this is the current model exercised by companies who use the validation and qualification services offered by companies like Equifax. The main process would not change: A customer fills out an application for credit, which is sent to one of the "Big three" (or any other qualifying entity) for reporting. The only difference is that the qualifying entity, Equifax for example, must validate the SSN with both validation authorities before beginning their review process.

In exchange for validating the SSN, the qualifying entity pays each validating body a small transaction fee to cover the added cost of having a separate body validate the data. If both authorities validate the SSN, then it’s business as usual for the qualifying agent. If not, an exception is flagged, stopping the process and terminating the initial transaction pending further investigation. Government agencies could use the system for free.

If someone’s information is compromised in a qualified, validated breach, or if the possibility exists that one’s personal information was accessed without authorization, then the process of changing the person’s SSN is initiated. The SSA issues a void order to the two validation bodies to invalidate the old SSN, and issues a new SSN on behalf of the victim, followed by an "update" order sent both entities. When both validation bodies provide confirmation of the new number’s entry into their respective systems, the victim receives their new social security number, and the original SSN is immediately invalidated.

Since all requests for validating a SSN go through the authentication bodies, any attempted use of a compromised SSN will be "denied."

Business competition will ensure that the new process of "verifying" the SSN is adopted, providing such a service would be invaluable to customers and would be a huge competitive advantage. As such, any agency that did not adopt the process would lose business -- this would ensure that the process would be widely adopted commercially.

In the presence of a system that can immediately revoke an SSN (thus stripping it of its value to criminals), the "worthless" remediation measures I questioned earlier can now serve a valuable purpose by providing legal measures that would hold companies accountable for having their data compromised by making them directly cover the cost of reissuing SSNs to the victims. The funds would go directly to the SSA, as opposed having ubiquitous fines collected by the Federal Trade Commission. A legislative body could dictate the criteria by which a company would be required to report security breaches, as well as constituting appropriate reparation based on a given scenario.

A great benefit of such a system is its natural support for legacy systems that may depend upon a SSN to track records -- it would be up to individual companies to make the decision to develop systems that would support a history of SSNs. For instance, the company that provides my health insurance coverage requires my SSN to track transactions against my account. They do so because they access other systems that also use my SSN -- as my physician or any given hospital or emergency facility does. The reason they require my SSN has less to do with my credit record than it has to do with accessing data using a consistent method.

If I were a victim of identity theft and changed my SSN, my insurance company would not necessarily have to change their systems to accommodate the change. Since they use the SSN simply as a unique number to access my records, they could go on using the old number. In fact, I would prefer that be the case as any breach of their systems would result in an attacker getting a voided SSN, not the current, valid one.

This would obviously be huge undertaking and would require incredible amounts of work and planning at the national level. It would be a long, hard road.

Yet, the problem of identity fraud is already out of control, and our current efforts are not doing anything to solve it. But if we can come up with a way of seeing a framework like this implemented that could actually end identity theft as we know it while also securing Social Security benefits for the future, I think it's something we should consider.