11 ms·

Thanks for correcting my abuse of language. I should have reviewed my post in detail. I did fix that now. That said, while I appreciate your perspective, I'm q

Thanks for correcting my abuse of language. I should have reviewed my post in detail. I did fix that now. That said, while I appreciate your perspective, I'm quite disappointed that you aren't offering any solutions besides asking people to contact you.

tptacek 15y ago
"Abuse of language"? You suggested that HMAC was an alternative to DSA. That's not a semantic nit. Signatures, by the way, are not the same thing as message authentication codes. And like I said: nobody should be using RSA or DSA for SSO tokens. Offering solutions on how to implement a secure single signon scheme with RSA or DSA on Hacker News is like explaining how to perform an appendectomy in Youtube comments. Sorry, not interested in hurting people. I know I sound super snippy here, and I'm sorry about that, but this problem comes up a lot. We keep finding applications that get almost everything right; locked down database layer, bulletproof authorization, reliable output filtering to stop Javascript injection... and then they go build single signon, and 3 days after we see that we can turn a guest account into the sitewide admin. People would be a lot better off if they did not try to build this particular feature themselves. (We don't build SSO systems for people, in case you think this is a sales pitch.)
- bascule 15y ago
  Can you please explain why using DSA to sign SSO tokens is a bad idea?
  - tptacek 15y ago
    Bignum cryptography is more dangerous than block cipher cryptography and (in secure systems) invariably depends on hash functions anyways (they're the worst of both worlds). The idea that public key algorithms are "more secure" than "shared-key" (symmetric, block cipher core) cryptography is exactly the opposite of true. Meanwhile, the utility of public-key cryptography in SSO systems is minimal. Public key is useful, and sometimes the only viable solution, when you have a potentially unbounded population of verifiers or signers. But that's never the case in SSO schemes, which have a bounded number of cryptographic participants (or, if they don't, are badly broken). Long story short: public key crypto is a last resort for systems that can't be deployed in any other way.
    - psadauskas 15y ago
      The idea that public key algorithms are "more secure" than "shared-key" (symmetric, block cipher core) cryptography is exactly the opposite of true. That seems backwards to me. How is having one key that can sign things be less secure than having multiple? If someone pwns a box with the shared key, they can forge credentials. If someone pwns a box with the public key, they can't. I would make sense to me that you'd want the important key that can be used to sign credentials in as few places as possible.
      - tptacek 15y ago
        After fielding a custom-cryptography single signon system for your Ruby applications, you think your biggest concern is "how well will the system survive the loss of one of my app servers to an attacker"? Let me help you out with that: you won't survive the loss of one of your app servers. You're going to have to rebuild and rekey everything. No, the biggest concern you have doing custom-cryptography for your Ruby apps is that the cryptography itself is going to hand attackers control of your app servers. Which, from experience, is somewhat likely. More likely if you haplessly use RSA or DSA.
        bascule 15y ago
        Obviously you're going to rebuild compromised servers and change all the keys... as soon as you find out you've been hacked. What about before then? You're advocating a scheme whereby if any verifier is compromised, the attacker can forge tokens. This isn't the case with a system that uses asymmetric crypto.
        tptacek 15y ago
        You're going to have to re-key because as soon as you got hacked the security of your SSO scheme is likely nil. When you find out about has nothing to do with anything. In any case, no part of block cipher crypto requires every pair of participants to share the same key --- even in the unlikely even that you needed all-pairs keys (virtually all SSO systems have a star topology). The idea that a system is going to resist forgery because it uses public key cryptography would be amusing if it wasn't so common. In reality, cryptography does not work the way _Applied Cryptography_ says it does; it works more like the way _Cryptography Engineering_ says it does. In other words: it conspires at all points and at all times to fuck you.

tptacek 15y ago

"Abuse of language"? You suggested that HMAC was an alternative to DSA. That's not a semantic nit. Signatures, by the way, are not the same thing as message authentication codes. And like I said: nobody should be using RSA or DSA for SSO tokens. Offering solutions on how to implement a secure single signon scheme with RSA or DSA on Hacker News is like explaining how to perform an appendectomy in Youtube comments. Sorry, not interested in hurting people. I know I sound super snippy here, and I'm sorry about that, but this problem comes up a lot. We keep finding applications that get almost everything right; locked down database layer, bulletproof authorization, reliable output filtering to stop Javascript injection... and then they go build single signon, and 3 days after we see that we can turn a guest account into the sitewide admin. People would be a lot better off if they did not try to build this particular feature themselves. (We don't build SSO systems for people, in case you think this is a sales pitch.)

bascule 15y ago
Can you please explain why using DSA to sign SSO tokens is a bad idea?
- tptacek 15y ago
  Bignum cryptography is more dangerous than block cipher cryptography and (in secure systems) invariably depends on hash functions anyways (they're the worst of both worlds). The idea that public key algorithms are "more secure" than "shared-key" (symmetric, block cipher core) cryptography is exactly the opposite of true. Meanwhile, the utility of public-key cryptography in SSO systems is minimal. Public key is useful, and sometimes the only viable solution, when you have a potentially unbounded population of verifiers or signers. But that's never the case in SSO schemes, which have a bounded number of cryptographic participants (or, if they don't, are badly broken). Long story short: public key crypto is a last resort for systems that can't be deployed in any other way.
  - psadauskas 15y ago
    The idea that public key algorithms are "more secure" than "shared-key" (symmetric, block cipher core) cryptography is exactly the opposite of true. That seems backwards to me. How is having one key that can sign things be less secure than having multiple? If someone pwns a box with the shared key, they can forge credentials. If someone pwns a box with the public key, they can't. I would make sense to me that you'd want the important key that can be used to sign credentials in as few places as possible.
    - tptacek 15y ago
      After fielding a custom-cryptography single signon system for your Ruby applications, you think your biggest concern is "how well will the system survive the loss of one of my app servers to an attacker"? Let me help you out with that: you won't survive the loss of one of your app servers. You're going to have to rebuild and rekey everything. No, the biggest concern you have doing custom-cryptography for your Ruby apps is that the cryptography itself is going to hand attackers control of your app servers. Which, from experience, is somewhat likely. More likely if you haplessly use RSA or DSA.
      - bascule 15y ago
        Obviously you're going to rebuild compromised servers and change all the keys... as soon as you find out you've been hacked. What about before then? You're advocating a scheme whereby if any verifier is compromised, the attacker can forge tokens. This isn't the case with a system that uses asymmetric crypto.
        tptacek 15y ago
        You're going to have to re-key because as soon as you got hacked the security of your SSO scheme is likely nil. When you find out about has nothing to do with anything. In any case, no part of block cipher crypto requires every pair of participants to share the same key --- even in the unlikely even that you needed all-pairs keys (virtually all SSO systems have a star topology). The idea that a system is going to resist forgery because it uses public key cryptography would be amusing if it wasn't so common. In reality, cryptography does not work the way _Applied Cryptography_ says it does; it works more like the way _Cryptography Engineering_ says it does. In other words: it conspires at all points and at all times to fuck you.