4 ms·

The focus of a lot of the coverage of this recent string of high-profile ID thefts has been the security of the companies in question, but I think the real fund

The focus of a lot of the coverage of this recent string of high-profile ID thefts has been the security of the companies in question, but I think the real fundamental problem of our system is that in order to prove your identity to someone you have to give them enough information that they can impersonate you to a third party. Information like SSN, address, mother's maiden name, driver's license number, etc. is simultaneously proof of identity and "private". Credit card numbers and checking accounts have basically the same flaw. All a merchant needs to pull money out of your account is the account number and some pretty basic additional information. If you write someone a check for a penny, you've given them enough info to drain the account. What we really need is a complete overhaul of how we prove identity. Identities should be linked to public-key/private-key pairs so you can prove you are who you say you are by signing a nonce, and thus others won't be able to impersonate you just by hacking a third party. Similarly, monetary transactions should be signed by both the sender and the recipient and include amount, date, memo, etc.. (Seriously, who initially thought that recipient-initiated transactions with no sender involvement wasn't going to be abused?)

icebraining 13y ago
Well, here in Portugal - and I know there are other European countries doing the same - our national ID cards already include a public/private key pair and can encode and sign stuff using standard APIs. You can already login on some governmental websites (e.g. IRS) using it. That said, I worry about having a single, State-granted identity; there's a reason why assigning a single number to each citizen that links all their records (health, criminal, etc) is unconstitutional here. I wish we could have a vouching system instead, where people and organizations could certify they do business with identity X. Something like Convergence[1] but for people instead of websites. [1] http://en.wikipedia.org/wiki/Convergence_(SSL) http://en.wikipedia.org/wiki/Convergence_(SSL)
- Spearchucker 13y ago
  This problem has been solved. The idea is to use identity federation, claims-based authorisation, and a privacy-enhancing technology that lets the subject determine which claims to share with a resource provider. Such a system can verify identity without divulging that identity. For instance, when you buy beer you need to prove you're over 18. The barman doesn't need to know your name, address, what vehicle classes you're licensed to drive, or age. All the barman needs is to know that you're over 18. The reason nobody uses it is that it's unpalatable to identity and resource providers alike. Imagine a world where you could buy anything without the seller ever knowing who you are. Or your bank not knowing what you bought. Or your identity provider (government) not knowing where you're using your authN credential. The tech community doesn't like it because even though it's open source, it's from Microsoft. And that it uses XML. So we keep on using broken identity systems like Persona and OAUTH. http://research.microsoft.com/en-us/projects/u-prove/ http://research.microsoft.com/en-us/projects/u-prove/
  - icebraining 13y ago
    U-Prove is interesting, but it doesn't solve the problem I posed. With our current ID cards, the identity provider is already ignorant where I use it. All they did was sign the certificate in my card, and now third-parties can check the chain without informing the IdP about me. The problem with U-Prove is that it still relies on a single identity provider. What happens when, by incompetence or malice, the State revokes your identity? And assuming that you can voluntarily revoke identities (e.g. if they're stolen) and not lose you bank accounts and so, there must be some way of proving that your new identity is just a new version of the old one. So, what prevents the IdP from creating fake identities that allow them to pass as you? The idea of applying Convergence would be to decouple the identity from that single provider, and I don't see how U-Prove helps with that.
    - Spearchucker 13y ago
      U-Prove can use any number of identity providers. It can even create a single new token assembled from pieces (claims, or inferred claims like age) of multiple identity providers. Decoupling an identity from a provider invalidates the identity. Identities have value because of the providers' relationships with subjects. It's up to the resource provider to establish trust relationships with other identity providers.
      - icebraining 13y ago
        Fair enough, it seems I have to do some reading on that proposal. Still, what happens when a single IdP invalidates their claims? Is the whole token invalidated?
        Spearchucker 13y ago
        The token is invalidated, as with any identity system. That's how it should work. Think certificate revocation lists, for example. The identity provider has to be able to revoke certs, or the entire trust model would fall apart.
- PeterisP 13y ago
  For many practical purposes, single identity is exactly what you need - i.e., as soon as you extend trust or credit to someone, you'd like it to be impossible for that person to ever be able to get another 'fresh' identity that's not clearly (and publicly) linked to the previous one; otherwise it would be trivial to violate that trust without the intended consequences.
PeterisP 13y ago
I would say otherwise - the key in protecting identities doesn't lie with information, but on requring not-information. As per classic security principles, for any risky endeavor "something you know" shouldn't be enough, but it should be combined with "something you have" and/or "something you are". It doesn't need to be frequent - you can require proof of identity only when [re]issuing proper, private security credentials (no matter if they're passwords, keys or hardware authentification tokens), but it means that the merchant/bank clerk/whoever can't impersonate you afterwards.

icebraining 13y ago

Well, here in Portugal - and I know there are other European countries doing the same - our national ID cards already include a public/private key pair and can encode and sign stuff using standard APIs. You can already login on some governmental websites (e.g. IRS) using it. That said, I worry about having a single, State-granted identity; there's a reason why assigning a single number to each citizen that links all their records (health, criminal, etc) is unconstitutional here. I wish we could have a vouching system instead, where people and organizations could certify they do business with identity X. Something like Convergence[1] but for people instead of websites. [1] http://en.wikipedia.org/wiki/Convergence_(SSL) http://en.wikipedia.org/wiki/Convergence_(SSL)

Spearchucker 13y ago
This problem has been solved. The idea is to use identity federation, claims-based authorisation, and a privacy-enhancing technology that lets the subject determine which claims to share with a resource provider. Such a system can verify identity without divulging that identity. For instance, when you buy beer you need to prove you're over 18. The barman doesn't need to know your name, address, what vehicle classes you're licensed to drive, or age. All the barman needs is to know that you're over 18. The reason nobody uses it is that it's unpalatable to identity and resource providers alike. Imagine a world where you could buy anything without the seller ever knowing who you are. Or your bank not knowing what you bought. Or your identity provider (government) not knowing where you're using your authN credential. The tech community doesn't like it because even though it's open source, it's from Microsoft. And that it uses XML. So we keep on using broken identity systems like Persona and OAUTH. http://research.microsoft.com/en-us/projects/u-prove/ http://research.microsoft.com/en-us/projects/u-prove/
- icebraining 13y ago
  U-Prove is interesting, but it doesn't solve the problem I posed. With our current ID cards, the identity provider is already ignorant where I use it. All they did was sign the certificate in my card, and now third-parties can check the chain without informing the IdP about me. The problem with U-Prove is that it still relies on a single identity provider. What happens when, by incompetence or malice, the State revokes your identity? And assuming that you can voluntarily revoke identities (e.g. if they're stolen) and not lose you bank accounts and so, there must be some way of proving that your new identity is just a new version of the old one. So, what prevents the IdP from creating fake identities that allow them to pass as you? The idea of applying Convergence would be to decouple the identity from that single provider, and I don't see how U-Prove helps with that.
  - Spearchucker 13y ago
    U-Prove can use any number of identity providers. It can even create a single new token assembled from pieces (claims, or inferred claims like age) of multiple identity providers. Decoupling an identity from a provider invalidates the identity. Identities have value because of the providers' relationships with subjects. It's up to the resource provider to establish trust relationships with other identity providers.
    - icebraining 13y ago
      Fair enough, it seems I have to do some reading on that proposal. Still, what happens when a single IdP invalidates their claims? Is the whole token invalidated?
      - Spearchucker 13y ago
        The token is invalidated, as with any identity system. That's how it should work. Think certificate revocation lists, for example. The identity provider has to be able to revoke certs, or the entire trust model would fall apart.
PeterisP 13y ago
For many practical purposes, single identity is exactly what you need - i.e., as soon as you extend trust or credit to someone, you'd like it to be impossible for that person to ever be able to get another 'fresh' identity that's not clearly (and publicly) linked to the previous one; otherwise it would be trivial to violate that trust without the intended consequences.

PeterisP 13y ago

I would say otherwise - the key in protecting identities doesn't lie with information, but on requring not-information. As per classic security principles, for any risky endeavor "something you know" shouldn't be enough, but it should be combined with "something you have" and/or "something you are". It doesn't need to be frequent - you can require proof of identity only when [re]issuing proper, private security credentials (no matter if they're passwords, keys or hardware authentification tokens), but it means that the merchant/bank clerk/whoever can't impersonate you afterwards.