‹ BackHN Continuity

Thread

SAML: A fractal of bad design

353 points · 190 comments · aray07

  1. bawolff · · focus · HN ↗
    My favourite SAML horror story, is that it used to be, that by default the main c implementation of xmlsig would not just check the sig with the public key specified but would also:

    - check it against an hmac using a password specified in the attacker controlled document.

    - check the signature using web pki (so the attacker could sign the saml document with their TLS key for their own personal domain and it would always be considered valid)

    I honestly dont know how sites with saml arent getting hacked all the time. The only thing worse than the absolute terrible standards are the absolute terrible implementations.

    1. stouset · · focus · HN ↗
      I saw multiple implementations that looked for a signature, verified it, then just trusted the document as a whole rather than only the part that was signed. So as long as you had any signed SAML doc, you could provide an attention of your choosing and just bundle the signed one somewhere arbitrary inside of it.
      1. tptacek · · focus · HN ↗
        It really probably is the worst security specification ever written.
        1. pseudohadamard · · focus · HN ↗
          Which, given the output of the IPsec and PKIX working groups, is saying something.
          1. tptacek · · focus · HN ↗
            I say this a lot, but: there was a conspiracy theory that NSA had infiltrated the IETF during the original IPSEC standardization effort and injected the "TLS BEAST" CBC IV chaining vulnerability, which is funny because we actually know exactly how that happened (professional academic cryptographers took out a petition to get the bug fixed and were shouted down by standards body gadflies who literally rejected the premise that there was such a thing as a professional academic cryptographer). This is really easy to see once you've done an engagement on DSIG security! Standards bodies are more than capable of fucking things up entirely on their own. If anything, NSA would risk making protocols stronger by intervening in their natural processes.
            1. pseudohadamard · · focus · HN ↗
              "Never attribute to malice what is adequately explained by stupidity". Or, in this case, design-by-committee by a bunch of people who haven't written ten lines of code in as many years. There have been several other cases where absolute no-brainer fixes, like one or two lines of code changed, to long-standing security problems, were filibustered, or blocked by WG chairs, for no explainable reason, and they can't all have been paid by the NSA to do that.
              1. bigfatkitten · · focus · HN ↗
                The people running these WGs are mostly professional committee members who get paid by their employers to fly around the world to attend meetings.

                They don’t build products, they don’t operate networks, and they don’t talk to customers.

                1. pseudohadamard · · focus · HN ↗
                  Yes, absolutely. And it's self-selection for mediocrity, people who are useless at any other task and prepared to argue endlessly over pointless technicalities that no-one apart from other professional meeting-goers care about are perfect for dumping onto standards committees.
            2. bigfatkitten · · focus · HN ↗
              NSA has their own stripped down and opinionated profiles of IPsec that they mandate for applications they really care about.

              HAIPE IS is classified, and mostly accommodates NSA’s private algorithms and key management practices.

              IPMEIR is public, but it mandated the Suite B cipher suites and so I don’t know where it stands now with the move to PQC.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.