Steven M. Bellovin is a professor of computer science at Columbia University. He focuses on security, privacy, and related legal and policy questions.
In the wake of the massive Equifax system compromise, in which the personal information of at least 145 million people may have been stolen, many people have questioned the ubiquitous use of social security numbers (SSNs) for authentication. This is only the latest of many data breaches; why have we not learned better? Using SSNs like this seems like an obviously bad idea—even the White House is considering a proposal to replace them—but solving the problem is a lot harder than it seems. Furthermore, alternatives are often worse in other respects.
SSNs are, and have been for a long time, a low-grade secret. However, they're not something immediately obvious to those who know you, and while they're pretty easily learnable—yes, even before the Equifax breach—it does take some effort. This latest incident isn't going to change that much—look at all of the other breaches, and all of the ways that people have had their social security numbers "doxxed". A casual attacker may have your social security number, but probably won't. Sophisticated companies, including most of those that use the SSN as an authenticator, have known this for years.
In reality, though, social security numbers are used less as a password than as a unique database key. That is, they're used to look up your database records and to link records in different databases. That's why you give your SSN when, say, you apply for a loan or start cell service or open a bank account—your social security number is used to match your credit record, rather than, say, someone else of the same name.
Should we replace the social security number for that purpose? Probably, but that's not easy, either. There are a couple of relevant National Academies reports (I was on the committee that produced both of them): IDs Not Easy: Questions About Nationwide Identity Systems, on questions that need to be answered before any national ID system could be deployed, and Who Goes There? Authentication Through the Lens of Privacy, on the privacy properties of various authentication systems. Basically, running any sort of national identity scheme is hard, and it's not clear that the replacement would have fewer problems than what we have now. Even well-engineered systems, such as the Estonian national ID card, have been reported vulnerable. Remember that security, including security of a national identifier, is a systems property; focusing on one aspect is unlikely to produce a secure system, since the attackers can always look at other aspects. To give just one problem identified in those reports, American birth records are not that good; births are recorded at the state or county level, and the quality levels vary widely.
To be sure, social security numbers are sometimes used as authenticators, but they're often to bootstrap into something more secure, again by using the SSN as an index into a database. True story: a dozen years ago, while we were in Paris, my wife's purse was stolen. While we spent many quality hours in the ever-lovely 17th Arrondissement police station, we called a few banks to report her credit cards as stolen. How could we authenticate? By definition, all of her cards had just been stolen. Her social security number, birthdate, and a few other biographical data items sufficed in this case. That's the more general problem: how do you bootstrap up to a secure identification when you're starting with no prior association? The most common scheme uses the social security number as an index to the vast trove of information that commercial data brokers have on people, and asking you odd questions based on that—but again, it starts with the most important database key, the human-memorable social security number. This is known as "knowledge-based authentication", and while it's far from perfect it's far better than just social security number and birthdate.
These are very hard problems. Social security numbers are bad, but it's really hard to do better if you want to do things like match records for credit reports, accommodate failure recovery, and permit blind account setup. There are certainly cryptographic schemes that can handle some of these tasks—but if you need linkage and you need memorability to recover from lost credentials, any replacement for the social security number is going to have most or all of the same problems. (The massive personal databases used by credit reporting agencies are rightly controversial, but it's hard to see how a modern economy can function without something like them. Credit bureaus are much older than computers; the correct answer is stricter controls on what information can be kept and on how it can be used.) A replacement scheme has to have good error recovery properties or it simply will not work. Recovery can be harder than it is today, but if so its other properties have to be enough better to make the switch worthwhile.
What, then, can we do? The problem underlying identity theft is not the existence of social security numbers, but rather, how little authentication is done for a person requesting credit. A digital national ID card could perhaps solve that, but as I noted, deploying such a system is very hard even apart from the privacy concerns attendant on such schemes. But as I also noted, the financial industry knows how to do better authentication when they want to. They could also do things like send paper mail to the last long-term address, to confirm it. Why don't they do that for credit card requests? At a guess, it's because these stronger schemes are too inconvenient, and will drive away consumers who are trying to apply for credit. If that guess is correct, it suggests that the real solution is regulatory: make credit providers liable for the full damages, including ongoing inconvenience, suffered by victims of identity theft. SSNs are not the problem; authentication commensurate with the risk to all parties, including especially individuals, is.