5 ms·

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 ap

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".
  - Someone1234 8y ago
    > 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. 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.
    - jdmichal 8y ago
      Please see my response here: https://news.ycombinator.com/item?id=19341688 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).
patch_cable 8y ago
I think that is mitigated by allowing the key to be rotated freely. The shortcomings over the token based approach are outweighed by being more practical to implement. If the issuing of a new key was an annual process, or even tied to something like drivers license/state id renewal, it would still be worlds better than what we have today.
- jdmichal 8y ago
  If rotation is the secret sauce, then the best strategy is to rotate after every use. In which case, why not just build that into the system: 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.
  - leesalminen 8y ago
    I agree that the client should generate a token and provide that to the company. 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.

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".
- Someone1234 8y ago
  > 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. 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.
  - jdmichal 8y ago
    Please see my response here: https://news.ycombinator.com/item?id=19341688 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).

patch_cable 8y ago

I think that is mitigated by allowing the key to be rotated freely. The shortcomings over the token based approach are outweighed by being more practical to implement. If the issuing of a new key was an annual process, or even tied to something like drivers license/state id renewal, it would still be worlds better than what we have today.

jdmichal 8y ago
If rotation is the secret sauce, then the best strategy is to rotate after every use. In which case, why not just build that into the system: 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.
- leesalminen 8y ago
  I agree that the client should generate a token and provide that to the company. 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.