4 ms·

The US government should replace SSNs. SSNs were never meant to be used this way. Any good replacement should start with a set of APIs specifically targeting f

The US government should replace SSNs. SSNs were never meant to be used this way. Any good replacement should start with a set of APIs specifically targeting financial institutions/credit. Give the consumer a random, easily rotatable, numeric key (e.g. "14830-29928-8921-29"). The key + API can return a unique ID, but a unique ID cannot return its corresponding key (i.e. single directional flow). The unique ID never changes for a given individual. If the consumer's key is lost, stolen, or breached the key can be re-issued and old one expired. Make it illegal to store the numeric key itself in a database for long periods. Only the resultant Unique ID can be held. You'd never request from the consumer the Unique ID itself (otherwise it itself would become the new SSN); only their key for API verification. Why is this a secure system? The information companies would store (Unique ID) is not the same information they need to process a new credit requests (Key). Meaning the piece of information that identity thieves need to steel is short lived, and the long lived info cannot convert back to the short lived.

jdmichal 8y ago
Aren't you basically just describing a more complex, weaker form of RSA SecurID hard tokens or Authenticator-app soft tokens? With a centralized API for validating a generated key vs identification details? EDIT: Thinking about this more, it seems like a much harder problem than this quipped solution gives credit for. The agency wishing to validate a generated key would need to have enough identifying information to isolate a single row in the centralized database to validate the token. Because we don't want every token assigned to John Smith to validate every John Smith. So now this centralized database needs to have something that's unique to every single row... Or, in other words, the same problem as SSNs have to start with.
- Someone1234 8y ago
  No, and the fact you think it is anything like SecureID means I did a poor job explaining it. It replaces cardboard cards with a SSN on them, with a cardboard card with a longer randomly generated key on it. There's no electronics involved from the consumer's perspective at all. The key is provided on your e.g. loan application. The financial institution sends that key to the government via API, and receives back a Unique ID assigned to you as an individual that never changes. The financial institution should then dispose of the key you provided them. The Unique ID is essentially used like an SSN; but the major differences are: - The consumer never provides it directly - The consumer's version of it (key) can be rotated freely - If the Unique ID itself leaks it has no value, since the API Cycle (i.e. Key -> Unique ID) is part of the system that financial institutions would use, supplying the Unique ID would just throw an error (since it isn't a valid key). So it completely different from SecurID, and is more akin to SSNs with most of the core issues resolved. Issuing cardboard cards with numbers on them isn't inherently complex, and is what we're already doing. The most challenging part is getting financial institutions to implement the API calls and update application forms. You'd also have to remain vigilant that they aren't storing the Keys themselves longer than absolutely necessary.
  - jdmichal 8y ago
    I'm with you, except for the part where we trust the middle man to please-pretty-please-pinky-swear delete the key. That, to me, makes it weaker than a token approach. With the token approach, the intermediate value has such a short useful lifetime that it's practically not a secret. The real secret -- the value required to duplicate the token -- remains with only the client and the centralized store.
    - Someone1234 8y ago
      > please-pretty-please-pinky-swear delete the key. In the first post I said quite the opposite: > Make it illegal to store the numeric key itself in a database for long periods. Using actual electronic tokens is impractical due to the costs. Even assuming just $1/each we're talking conservatively almost half a billion dollars (inc. shipping), and the upkeep would be similarly high. The proposal above 1:1 replaces the system we have and are already paying for while solving most of the major weaknesses. Multiple smartcard-like systems have failed spectacularly in other countries, a SecurID-like token would suffer from many of the same issues.
      - jdmichal 8y ago
        In the end, you're really stuck between two places. Either you have something static, in which case it's got all the negatives of a static secret. Or, you have something dynamic, in which case you have to manage the infrastructure. The only thing that makes SSNs bad static secrets is that you should basically assume yours has been leaked at this point. Like others have said in this thread, they're not bad identifiers, but they're a terrible choice for confirming identity. Your system is just another static piece of data to keep secret. Which is where SSNs started when this crazy train kicked off. And no, "rotation" is not the secret sauce, because SSNs can already be rotated under certain circumstances. I also don't understand how the "unique ID" doesn't have value. OK, you can't confirm an identity with it on the centralized system. But as far as I can tell, it basically serves as proof that you did confirm the identity. There's no way to distinguish between "obtained unique ID via the key and thereby proved identity" and "obtained unique ID via any other method and thereby did not prove identity".
exegete 8y ago
There was a good Planet Money episode on how it got to be this way. [1] The SSN maybe originally was not meant to be used this way, but starting around 1943, government agencies were required to use it when possible. [2] That's less than a decade after the first SSN's were issued. 1. https://www.npr.org/sections/money/2018/03/14/593620579/episode-830-xxx-xx-xxxx https://www.npr.org/sections/money/2018/03/14/593620579/epis... 2. https://www.ssa.gov/foia/html/EO9397.htm https://www.ssa.gov/foia/html/EO9397.htm

jdmichal 8y ago

Aren't you basically just describing a more complex, weaker form of RSA SecurID hard tokens or Authenticator-app soft tokens? With a centralized API for validating a generated key vs identification details? EDIT: Thinking about this more, it seems like a much harder problem than this quipped solution gives credit for. The agency wishing to validate a generated key would need to have enough identifying information to isolate a single row in the centralized database to validate the token. Because we don't want every token assigned to John Smith to validate every John Smith. So now this centralized database needs to have something that's unique to every single row... Or, in other words, the same problem as SSNs have to start with.

Someone1234 8y ago
No, and the fact you think it is anything like SecureID means I did a poor job explaining it. It replaces cardboard cards with a SSN on them, with a cardboard card with a longer randomly generated key on it. There's no electronics involved from the consumer's perspective at all. The key is provided on your e.g. loan application. The financial institution sends that key to the government via API, and receives back a Unique ID assigned to you as an individual that never changes. The financial institution should then dispose of the key you provided them. The Unique ID is essentially used like an SSN; but the major differences are: - The consumer never provides it directly - The consumer's version of it (key) can be rotated freely - If the Unique ID itself leaks it has no value, since the API Cycle (i.e. Key -> Unique ID) is part of the system that financial institutions would use, supplying the Unique ID would just throw an error (since it isn't a valid key). So it completely different from SecurID, and is more akin to SSNs with most of the core issues resolved. Issuing cardboard cards with numbers on them isn't inherently complex, and is what we're already doing. The most challenging part is getting financial institutions to implement the API calls and update application forms. You'd also have to remain vigilant that they aren't storing the Keys themselves longer than absolutely necessary.
- jdmichal 8y ago
  I'm with you, except for the part where we trust the middle man to please-pretty-please-pinky-swear delete the key. That, to me, makes it weaker than a token approach. With the token approach, the intermediate value has such a short useful lifetime that it's practically not a secret. The real secret -- the value required to duplicate the token -- remains with only the client and the centralized store.
  - Someone1234 8y ago
    > please-pretty-please-pinky-swear delete the key. In the first post I said quite the opposite: > Make it illegal to store the numeric key itself in a database for long periods. Using actual electronic tokens is impractical due to the costs. Even assuming just $1/each we're talking conservatively almost half a billion dollars (inc. shipping), and the upkeep would be similarly high. The proposal above 1:1 replaces the system we have and are already paying for while solving most of the major weaknesses. Multiple smartcard-like systems have failed spectacularly in other countries, a SecurID-like token would suffer from many of the same issues.
    - jdmichal 8y ago
      In the end, you're really stuck between two places. Either you have something static, in which case it's got all the negatives of a static secret. Or, you have something dynamic, in which case you have to manage the infrastructure. The only thing that makes SSNs bad static secrets is that you should basically assume yours has been leaked at this point. Like others have said in this thread, they're not bad identifiers, but they're a terrible choice for confirming identity. Your system is just another static piece of data to keep secret. Which is where SSNs started when this crazy train kicked off. And no, "rotation" is not the secret sauce, because SSNs can already be rotated under certain circumstances. I also don't understand how the "unique ID" doesn't have value. OK, you can't confirm an identity with it on the centralized system. But as far as I can tell, it basically serves as proof that you did confirm the identity. There's no way to distinguish between "obtained unique ID via the key and thereby proved identity" and "obtained unique ID via any other method and thereby did not prove identity".

exegete 8y ago

There was a good Planet Money episode on how it got to be this way. [1] The SSN maybe originally was not meant to be used this way, but starting around 1943, government agencies were required to use it when possible. [2] That's less than a decade after the first SSN's were issued. 1. https://www.npr.org/sections/money/2018/03/14/593620579/episode-830-xxx-xx-xxxx https://www.npr.org/sections/money/2018/03/14/593620579/epis... 2. https://www.ssa.gov/foia/html/EO9397.htm https://www.ssa.gov/foia/html/EO9397.htm