An Alternative to the Social Security Number

With the Equifax hack just last week, I got to thinking about a better alternative to Social Security Numbers (SSN) that all Americans are assigned at birth and must carry throughout their lifetimes. And right there, in the first sentence, we have the core problem: your SSN doesn’t change. There are a few limited cases in which you can apply for a new SSN, but they are limited. The humble number was never intended for all of its current uses.

Despite this, the SSN remains critical to all sorts of mundane interactions: applying for a passport, registering for the selective service (the draft), getting a new job, applying to college, and any type of financial transaction (credit cards, taxes, bank accounts, cars, benefits, etc). The number of entities through which your SSN has passed is outrageously high for a “secret” number.

To add to the trouble, until 2011, SSN’s were issued with state prefixes. Because I’m from Colorado and clearly older than six, my SSN must have a prefix between 521 and 524. If the last 4 of my SSN are exposed (the last 4 digits are often times displayed in a variety of places), my SSN is suddenly one of 400 possibilities.

Towards National ID Numbers

In reality, our SSN’s are already being used as national identification numbers in most interactions with government agencies and financial interactions with other organizations. I propose that the SSN is re-designated as a National ID number to be used when interacting with a wide variety of government and private organizations. This ID number would be paired with a 6-digit Financial PIN. For non-financial purposes, a National ID number could replace (newly created) Medicare Numbers, a Permanent Resident’s A-Number, non-resident USCIS Numbers, and other separate government ID Numbers.

An ID-PIN pair would be more secure than what we have today because the PIN can be rapidly changed (or locked) when needed or desired. It presents a second barrier to crooks trying to impersonate a target. There are also plenty of legitimate daily uses of our SSN’s to report earned income, capital gains, loan information, credit ratings, and a host of other financial data between government and private organizations. These interactions should proceed without PIN verification because they are in the normal course of business where a relationship already exists.

A PIN would only be needed for certain transactions, which I’ll call “Initiation Transactions”—those that initiate a new relationship between the holder and some financial institution. When applying for a new credit card, opening a financial account, or extending credit in other ways, PIN entry would be required. During a background credit check or the opening of an account, the ID-PIN pair would be checked against external databases. This still presents the opportunity that the PIN could be stored and leaked, so I propose going one step further to limit the risk of revealing both pieces of the pair.

Cryptography

With enough money and time and computing resources, any cryptography can be broken. But, there are ways to make it virtually impossible to do this easily, quickly, or cheaply. In particular, for large sets of leaked data (such as the Equifax leak). I propose that each initiation transaction would result in a hashed key rather than in the raw ID-PIN pair. To further enhance security, each financial institution would have a “shared secret” with the government database, so that a request from one financial institution could not be substituted for another.

To demonstrate how I envision this working:

User Input:

Bank Details:

Output:

Then, like most uses of hashes, the local hash is checked against the remote hash—which can be generated remotely using the request time and known information. In my example, the requesting institution would use the birthdate to create the hash, but would not send it as part of the verification request. The government database—already having a record of the true birthdate—also uses the known, stored birthdate to produce a hash, giving an added layer of verification. I include the current time so that the hash isn’t static, it changes once per second.

So, assuming the user entered their personal information correctly and the bank’s shared secret was valid, the response would be:

Now, let’s assume hackers steal:

1. The PIN: Put an immediate lock on the pin (either through request or automated detection. One might imagine that people could choose to lock their pins in general unless they were applying for something.
2. The bank’s shared secret: The financial institution would generate a new shared secret and update their local database and the government database.
3. The hash and request variables: Not much useful here, the PIN isn’t visible, the shared secret isn’t visible, the birth date isn’t visible. By the time other information is decrypted, institutions could have already changed the PIN and shared secret.
4. The master database: Lock, reset, and change all of the PIN’s and roll all of the shared secrets. It would take some time and expense, but far less than the potential impact of the leaks we currently have.

Let’s see how the hash changes (with the other variables remaining consistent) in each of these scenarios

The PIN changes (they try 123456, you’ve changed it to 098765):

The shared secret changes (they try 9ca6d642d5a5b02c, the bank updated it to 265293bd41317e78):

They get the whole database and everything

Another key in this design is the ability to permanently and temporarily lock activity (again, only “Initiating Transactions):

• Death: Lock the ID immediately upon notification
• Children / Infirm / Extremely Disabled: Lock PIN in general with ability to unlock if needed
• General public: Lock PIN online whenever desired

My solution certainly has technical shortcomings and I’m sure true computer security experts can poke holes in it. Awesome, poke holes, make it better, let’s find a way to do something like this, scale it, and end at least the most simple version of financial fraud.