Again, I find that this only reinforces the fact that SSNs are not a useful identification system because there's nothing secure about them. Can someone explain where attackers obtain SSN/DOB data with such a widespread success rate?
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.
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.
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.
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.
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".
I just described a system that is neither fully static nor fully dynamic. It has a static part (Unique ID) and a semi-dynamic part (numerical key) that can rotate as needed.
> Your system is just another static piece of data to keep secret.
Keys can be rotated as needed. For example with drivers license renews. The Unique ID is static but it isn't security sensitive.
> I also don't understand how the "unique ID" doesn't have value.
Because having it doesn't give you the ability to open a bank account, take out a loan, or receive a benefit. It is used by the financial institutions to tie actions to an identity, nothing more.
The actual validation of identity occurs with the key and API, the Unique ID is simply the result.
> 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".
The action of retrieving the Unique ID is more important for verifying identity than the actual Unique ID itself. You could steal a Unique ID but that isn't useful, and there wouldn't be another way of obtaining one.
https://news.ycombinator.com/item?id=19341688
If the secret sauce is key rotation, then the best strategy is to rotate for every use. Building that strategy into the system basically results in OpenID. Take OpenID and allow the client to generate tokens offline, and that's SecurID.
And I still see value in the unique IDs, because they serve as a type of proof that key exchange has taken place. How does the bank go to court and demonstrate the the individual has validated their identity? The best way is to retain the key. Oh, but we're supposing that's illegal. So instead they'll show the unique ID and say, well then how did I get this unique ID?
I don't think you're applying enough hacker mentality to this. If we're going to approach this problem, let's approach it will the full capabilities that modern cryptography give us. There's no reason to share a secret with the company and extend trust to them; we already know how to securely share a secret between two endpoints (client and central authority) through untrusted middle men (company).
https://news.ycombinator.com/item?id=19341434
How are you paying for giving out half a billion SecurID-like tokens?
I'm talking about a code that can be printed on your driver's license, you're talking about a piece of electronics that has to be shipped to every person in the US, the logical differences are stark.
Also, soft tokens are a thing and are basically free to generate. I've got several loaded on my phone right now, and have the code backed up in my password vault.
Also also, printing secret codes on drivers licenses seems like an amazingly bad idea... Every bar bouncer I interact with sees that thing!
Which negates the whole benefit of having short lived secrets, which was the whole crux of why you were suggesting it.
> Also, soft tokens are a thing and are basically free to generate.
So now instead of buying every citizen in the US a token we're buying every citizen a smartphone or legally requiring them to have one? Seems problematic.
> Also also, printing secret codes on drivers licenses seems like an amazingly bad idea...
Then print them on a separate sheet of cardboard. Still a massive order of magnitude cheaper than what you're suggesting which could range from $0.5-20B+ depending on implementation.
I'm suggesting a more flexible SSN that solves the major issues we already facing. You're suggesting a token based system without actual tokens, smartphone apps without actual smartphones, and printed list of codes.
There's nothing about the former system that requires the things you are stuck on. (And I honestly think you're just being stubborn for some reason, because I'm pretty sure you understand the idea I'm conveying.) You could do it over the phone using a touch-tone system. You could do it through a website. You could do it with an app. You could do it with a hard or soft token. You could do it with a smartcard. The only requirement is that you are capable of telling your secret to the central authority in exchange for a token, in a way that it is very difficult for others to observe. Or, alternatively, to have come to an agreement about how to generate such tokens offline.
But the important part is that in the system I'm talking about, you get a secret value from a central authority. And then you don't tell anyone that secret except that same central authority. Everyone else sees temporary values that are useless if saved -- no pinky promises and laws required.
Indeed I do, it is logistically absurd. I'm talking about replacing one piece of cardboard with a different, more secure, piece of cardboard that resolves actual problems we have today. You're talking about smartphones, tokens, calling in, and a million other complex workarounds all in the name of hypothetical security.
I'd love to see you try to explain your system to an elderly or disabled person. I can explain mine: "Instead of giving them your SSN card, give them this card instead." Done. One sentence. That's literally all they have to know.
Plus your scheme has a huge hole. The second you moved away from physical tokens (which you now seem to acknowledge is unaffordable) to smartphones and now regular phones, you need a way to authenticate who you are. Which means you'll be giving people credentials, which can then be lost, stolen, or requested from vendors creating exactly the same issues we started with.
In other words you've managed to create an expensive logistical nightmare that the general public will hate all in the name of hypothetical security benefits that won't even work in practice. Neat.
And you're talking about zero improvement in security stance. You could literally implement your idea by just making it illegal to store SSNs, because that's the only salient point where you've improved over current state.
> I'd love to see you try to explain your system to an elderly or disabled person. I can explain mine: "Instead of giving them your SSN card, give them this card instead." Done. One sentence. That's literally all they have to know.
Print card with secret. Give them card. Card has phone number on it. Call the number. It asks for what's on the card. You enter it. You get another number. Give that to the person asking.
Also print on the card to not give the card or the number on it to anyone.
> Plus your scheme has a huge hole. The second you moved away from physical tokens (which you now seem to acknowledge is unaffordable) to smartphones and now regular phones, you need a way to authenticate who you are. Which means you'll be giving people credentials, which can then be lost, stolen, or requested from vendors creating exactly the same issues we started with.
Physical tokens are a "something you have". So is a piece of cardboard. If there's no need to authenticate a hardware token, there's also no need to authenticate a number on a piece of cardboard. And there's no reduction in security stance by doing so.
Also, I make no acknowledgement of the in-/affordability of tokens. Rather, I assert that you can simultaneously support multi-modal methods of exchanging a secret for a token.
> In other words you've managed to create an expensive logistical nightmare that the general public will hate all in the name of hypothetical security benefits that won't even work in practice. Neat.
Really? My proposal is literally the same mechanism by which OpenID and web tokens work... And I'm done because I don't know how to work with someone who's idea of a good security posture is give away secrets to people who ask for them.
Rotatable consumer keys. Mitigating the danger of vendor hacks/leaks. Both at the main problems with SSNs today.
> You could literally implement your idea by just making it illegal to store SSNs, because that's the only salient point where you've improved over current state.
SSNs cannot be rotated. SSNs have already leaked. Stealing an SSN allows you to open accounts/credit/etc neither of which my proposal allows.
I'm wondering if you've even read my proposal. Either you haven't or you're pretending you haven't, in either case it seems bad faith.
> It asks for what's on the card. Also print on the card to not give the card or the number on it to anyone.
So this card of yours is identical to existing SSNs. SSN cards even contain that exact text. You need to go back to the drawing board (or just read my proposal and think about it a little).
> Physical tokens are a "something you have".
So now we're back to spending billions on physical tokens? How are you funding it.
> My proposal is literally the same mechanism by which OpenID and web tokens work...
OpenID won't scale to half a billion people, it isn't affordable or practical. Something you've already conceded, that's why you're talking about calling a phone number using your SSN-v2 secret.
> And I'm done because I don't know how to work with someone who's idea of a good security posture is give away secrets to people who ask for them.
We're on the tenth post and you still haven't even read my proposal, that isn't something in it, and you'd know that if you had taken the time to read it.
You really aren't discussing in good faith here.
This statement seems to be about the only thing we agree on. You keep shifting your goalposts or simply repeating "but rotation!" when I've already addressed exactly that.
1. Client holds key.
2. Client exchanges key with central agency for token. Token expires after a short time period, making long-term storage and leaks useless.
3. Client gives token to company.
4. Company validates token with central agency.
And now we've reinvented OpenID. And SecurID is nothing but a piece of hardware that can perform (2) in a decentralized manner. We could maybe modify (4) to potentially be more useful for this specific use-case:
4. Company exchanges client identity token with central agency for a validation token that can be stored long-term. Validation token signifies that an identity token was received and exchanged, for legal purposes.
What I don't know is how to protect this validation token from becoming valuable beyond the above use-case. If it's proof of something, then it becomes valuable for that proof... So it would would have to be scope-limited in ways that make it useless for proving anything other than that exact exchange. Off the top of my head, obvious scope limitations are: client, company, and timestamp.
Bonus points: have tokens issued in XXX-XX-XXXX format so that existing systems don’t have to change anything- it’s still a SSN of sorts, just one time use.
1. https://www.npr.org/sections/money/2018/03/14/593620579/epis...
[1] - https://www.pcworld.com/article/3004654/a-tale-of-two-women-...
If that was all it (SSN) was used for, a "unique-id", it would work ok for that usage.
The problem is that far too many companies also make use of SSN as a "secret only you know" to authenticate that you are in fact the individual identified by the SSN. I.e, your "login name" is identical to your "password". It is this miss-use that leads to the problems around SSNs.
No. It's sufficient for identifying someone, but not at all sufficient (not even close) for verifying someone is who they say they are.
SSN as a user identifier - to uniquely describe an entity
Actual PKI including a secure public/private key with a signature from a trusted agent (like a government ID authority), and maybe also web-of-trust signatures? THAT is what is required to securely sign things.
OK, fine, whatever, except this is the same even for controlled substances. Which is quite weird considering all the other regulations around controlled substances. One time I had to get rid of some excess oxycodone after a surgery, I ended up having to go into a little booth at the sheriff's department where they had a drop box and a sheriff's deputy sitting at a desk behind a window watching me. But all my wife needed to pick it up in the first place was my name and DOB.
I'd imagine it's trivial to pretend to be a cop and just purchase access to this stuff, not that it's going to be hard to hack most police departments either.
On the non-trivial side: I was doing a startup where we sublet from a law firm. We had an on-site audit by someone who came in and we were cautioned that we had to have an independently locking door on our office. We also had to give a reasonably thorough explanation of what we wanted to do with the data and certify, as well as convince the auditor, that we would be using it for GLBA (anti-fraud in financial transactions) purposes.
We actually failed one of the audits the first time because some paperwork wasn't in place (I think we had changed the Delaware company name and not re-filed something, like our local jurisdiction foreign corporate registration, in the new name).
On the not comforting side: the sales reps for these products have full access and will let you do lookups and surf through on whatever. 100% unmasked details on any numbers you want. DMV, aircraft, SSN, judgments, etc., all linked and at the ready.
Also, GLBA is a giant Sherman-tank sized loophole that means that essentially anybody can fully legally use these databases as long as there's some cognizable financial transaction that you're protecting from fraud (even proactively / research wise).
See https://risk.nexis.com/AMLSolutions/help/GLBA_Permissible_Us...
So no, you can't just "pretend to be a cop" but if you actually go to the trouble of being some sort of fraud-prevention business, you can just go wild.
https://krebsonsecurity.com/2013/10/experian-sold-consumer-d...
>An identity theft service that sold Social Security and drivers license numbers — as well as bank account and credit card data on millions of Americans — purchased much of its data from Experian, one of the three major credit bureaus, according to a lengthy investigation by KrebsOnSecurity.
>An individual who read a story about the operators of a similar ID theft service online having broken into the networks of LexisNexis and other major data brokers wrote to say that he’d gone back and reviewed my previous stories on this topic, and that he’d identified the source of the data being resold by Superget.info. The reader said the abbreviations matched data sets produced by Columbus, Ohio-based USInfoSearch.com.
>Contacted about the reader’s claim, U.S. Info Search CEO Marc Martin said the data sold by the ID theft service was not obtained directly through his company, but rather via Court Ventures, a third-party company with which US Info Search had previously struck an information sharing agreement. Martin said that several years ago US Info Search and CourtVentures each agreed to grant the other company complete access to its stores of information on US consumers.
>Founded in 2001, Court Ventures described itself as a firm that “aggregates, repackages and distributes public record data, obtained from over 1,400 state and county sources.” Cached, historic copies of courtventures.com are available through archive.org.
>In March 2012, Court Ventures was purchased by Costa Mesa, Calif.-based Experian, one of the three major consumer credit bureaus. According to Martin, the proprietors of Superget.info had gained access to Experian’s databases by posing as a U.S.-based private investigator. In reality, Martin said, the individuals apparently responsible for running Superget.info were based in Vietnam.
So, yeah. I bet you could obtain tons of SSNs from fucking Lenscrafters if you wanted to.