root labs rdist

September 8, 2010

Clench is inferior to TLS+SRP

Filed under: Crypto,Network,Protocols,Security — Nate Lawson @ 10:38 am

There’s a new proposed client authentication method called Clench from web security super-group Goatse Security. While their deep magic may work for revealing iPad email addresses, it’s not so great when it comes to designing crypto protocols.

This protocol is intended to provide a way for clients to authenticate themselves to servers and vice versa without revealing useful information to a man-in-the-middle. While most of the rhetoric in the post is anti-PKI (and rightly so), their protocol doesn’t really replace PKI.

First, it only works for sessions where the user is logging in. There is no way to authenticate just the server (anonymous client). This means the protocol does not replace PKI since it assumes a priori that the server knows the client’s password. There has to be an existing relationship established with this particular server before Clench can be used. This is the chicken-and-egg problem that SSL+certs solves by including a root cert in the browser.

Second, the server has to store plaintext passwords. The authors attempt to explain this away by suggesting the password will be stored in some other secure device (like an HSM). But this is definitely a step down in security from appropriate password hashing methods like bcrypt.

Finally, the authors don’t emphasize that Clench will require changes to all client software (e.g., your web browser). This has been a non-starter for many protocols.

Luckily, all of this has already been solved. SRP is a family of password-based authentication schemes. SRP provides the following:

  • Provably secure against dictionary attacks
  • Provably secure against an active man-in-the-middle attacker
  • No trusted third-party required
  • Passwords stored on the server are salted and hashed

SRP has been around since about 1998. RFC 5054 added a TLS extension for SRP and was approved in 2007. OpenSSL will support it in version 1.0.1. Various patches are out for OpenSSH support.

All the discussion about Clench will hopefully raise awareness of SRP instead. It’s been around for 12 years, solves more problems, and has none of the drawbacks Clench has. It’s definitely time to adopt SRP.

21 Comments

  1. I wouldn’t care much about the cleartext passwords thing. The bad guys are already reversing salted hashes using video cards, they can go at several billion attempts per second. Example of a slowpoke machine doing this:

    http://www.jobertabma.nl/downloads/core-i7-250gts-benchmark.png

    If you assume a site is cracked with 100,000 user accounts on it, at these speeds it’d take less than a day to recover all the passwords (well, assuming the majority of passwords can be located with a few billion tries).

    The days when a salted hash was enough to make your password db secure are over for good. The huge wave of hijackings happening across the net is the result.

    Comment by Mike Hearn — September 8, 2010 @ 11:24 am

    • Please explain how simply bumping the number of iterations for bcrypt does not fix this? The defender always gets the most benefit out of increasing the computational difficulty of generating each guess.

      Salting has more to do with space than difficulty of computation. It increases the space an attacker needs to store all variant hashes for a given dictionary word. Even a small salt can make precomputing hashes unhelpful since it scales with the size of the dictionary.

      Increasing the number of iterations for bcrypt increases the computational difficulty of every time the attacker needs to calculate one of those hashes, whether generating them beforehand or during the attack.

      It’s a long way to go from “password cracking is getting faster” to “let’s go back to 1975 and store cleartext passwords”.

      Comment by Nate Lawson — September 8, 2010 @ 11:55 am

      • I think it depends on the attackers goals. If they have a password db and the password is one million iterations of bcrypt with the username as the salt, that does make it harder for an attacker to reverse all the hashes.

        If they only care about one or two of the hashes, like the admin password, doing it a million times doesn’t seem to help that much. If an attacker can try 5 billion combinations per second on a powerful GPU like one of the Teslas, and we assume the admin password falls into one of those 5 billion combinations, then using a million bcrypts takes you from 1 second of cracking time to 11 days. If the attacker has any funding at all they can just by a few more high end GPUs and bring the attack time down to a day or two instead of 11.

        Comment by Mike Hearn — September 9, 2010 @ 7:42 am

      • Have you profiled bcrypt? I highly doubt you can get 5 billion hashes/sec out of it on any GPU where it is tuned to take 0.1 seconds/hash on a modern CPU. The nice thing about Blowfish is that the key schedule takes a while to setup, and that process has to be done once per password (+ salt) guess.

        The articles you cite link to FreeBSD MD5-crypt, which is much faster than bcrypt. Even in the original 1999 paper on bcrypt, MD5-crypt was 15x faster than bcrypt(32 rounds).

        Comment by Nate Lawson — September 9, 2010 @ 10:39 am

  2. SRP requires a “strong pre-shared session key” as well as a password

    Comment by purly — September 8, 2010 @ 11:27 am

    • Wrong. The only thing SRP requires on the server is the client’s hashed+salted password (values “s” and “v” in the SRP spec).

      Comment by Nate Lawson — September 8, 2010 @ 11:43 am

  3. Nate,

    In via Google Blogsearch. Initially saw SRP via Dan Kaminsky rippin apart our shit on f-d:
    http://seclists.org/fulldisclosure/2010/Sep/127

    SRP is absolutely a better means of approaching this problem. I can’t believe I’ve never seen it implemented anywhere before.

    -Andrew

    Comment by Andrew Auernheimer — September 8, 2010 @ 12:43 pm

    • Andrew, thanks for your comment.

      SRP had a lot of resistance due to questions about its patent status. Those have been resolved but it opened the door to a competing approach, JPAKE. JPAKE has been available in OpenSSH and OpenSSL for about 2 years. It’s a little slower but a basically sound approach.

      None of this should distract from the fact that browser root certs are a mess. Browsers need to clean house, and I appreciate your goal of helping that effort. Perhaps the SSL Observatory project could benefit from some assistance?

      Comment by Nate Lawson — September 8, 2010 @ 3:03 pm

      • Hi Nate,

        I too surprised they have come up with yet another PAKE, without solving any problems of the previous ones.

        The JPAKE in OpenSSH is unfinished and I don’t recommend enabling it (we don’t provide a documented knob to do so for this reason). When writing it, I came up with a hacky solution to the cleartext password storage problem that afflicts most PAKE protocols – using the pw _hash_ as the value the client and server exchange proofs over, but this just shifts the problem by making the pw hash the thing you need to keep confidential (ok, this is slightly better in that theft of a pw hash doesn’t automatically grant access to all the sites you have reused the pw at, but it is not good enough to satisfy me).

        One of these days I’ll get some time to get back to it and come up with a better protocol. This will probably require storage of pw hashes in a different format.

        -d

        Comment by djm — September 9, 2010 @ 4:45 am

      • djm,

        These are known as “balanced” and “augmented” schemes in the literature. “Balanced” is symmetric and requires both sides to hold the same authenticator (e.g., a plaintext password). “Augmented” has the additional property that compromise of the server does not yield the key necessary to impersonate the client (e.g., to other servers where the client used the same password).

        JPAKE and SPEKE are balanced schemes and thus have the same problem as Clench. However, SRP does not.

        SRP is an augmented scheme where the server stores s and v computed by:

        x = H(s, P)
        v = g^x

        where P is the plaintext password and s is the salt. Thus, if an attacker gets s, v from the server, she can perform a dictionary attack by computing the forward function of these variables. However, this does not reveal the plaintext password directly. “H” could be bcrypt with a client/server shared number of rounds, making SRP just as secure as ordinary Unix password hashing.

        Augmented EKE protocols first appeared in:

        S. Bellovin and M. Merritt, “Augmented Encrypted Key Exchange: a password-based protocol secure against dictionary attacks and password file compromise,” 1993.

        SRP, A-EKE, and B-SPEKE are the current augmented EKE protocols. JPAKE is not. That’s one reason it was disheartening to see SRP adoption slowed by somewhat-unrealistic patent concerns.

        Since those are now out of the way, it’s high time to adopt SRP.

        Comment by Nate Lawson — September 9, 2010 @ 10:26 am

      • The killer with PSK schemes isn’t really the patent (TLS-SRP is usable on fairly liberal terms) since there’s also the totally unencumbered TLS-PSK, the real issue is the incredible resistance of browser vendors to implementing it. For NSS (Firefox, etc) the reason is:

        “There are no plans to include any PSK cipher suites in NSS. Because of the enormous potential for PSK cipher suites to be misused by application developers, there is strong resistance to incorporating them into NSS”.

        I really don’t know what more to say in response to a comment like that.

        Comment by Dave — September 17, 2010 @ 4:45 am

      • “Misused by application developers”? Is HTTP basic auth somehow safer? I can’t even imagine what they’re thinking.

        Comment by Nate Lawson — September 21, 2010 @ 2:53 pm

  4. Shameless self-plug:

    I wrote a patch for Mozilla NSS as well: https://bugzilla.mozilla.org/show_bug.cgi?id=405155

    Based on this, there is also code for the GUI/http handler parts. Might not be online anymore but I should have it. However, I never tried that part.

    TLS+SRP is probably also the best way to implement the upcoming automated credential management stuff..

    Comment by steffen — September 9, 2010 @ 3:06 am

    • Absolutely. TLS+SRP should replace HTTP basic auth.

      Comment by Nate Lawson — September 9, 2010 @ 10:17 am

    • The UI prototype is still available here:
      http://jengler.webs.com/pake.htm

      Last time I asked, the author said its free for use. GnuTLS already supports SRP and there are also (old) patches for OpenSSL and ModSSL.

      They made a fancy paper out of it with some remaining problems:
      http://w2spconf.com/2009/papers/s4p1.pdf

      Of course, they forget to mention the guy who helped them with the code and reviewed their draft..

      Comment by steffen — September 12, 2010 @ 4:29 am

      • Thanks for the links. I hope you continue to help out with SRP.

        Comment by Nate Lawson — September 13, 2010 @ 8:33 am

  5. In regards to the discussion about bcrypt: Take a peak at scrypt:
    http://www.tarsnap.com/scrypt.html

    Comment by andreas — September 13, 2010 @ 3:21 pm

    • Yes, I’m familiar with scrypt. For now, I’d rather recommend something that has been around a little longer with implementations in multiple languages than something that is newer.

      Comment by Nate Lawson — September 21, 2010 @ 3:04 pm

  6. Do you have a link to any places describing the clearing up of the patent status of SRP?

    Comment by caf — September 15, 2010 @ 6:34 pm

    • SRP has never been a problem, the problem is that both Phoenix and Lucent like to imply that their patents may cover SRP (which they probably don’t) but it’s enough to scare people off using it.

      Comment by Dave — September 17, 2010 @ 7:14 am

    • Here are the IPR disclosures for SRP:
      https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=2945

      Looks like Lucent and Phoenix were the only ones that made noise. But you’re right — I can’t find a definitive “all clear” message out there. That’s usually the case with IP rights. Companies could be penalized for saying they have no claims in a technology so they don’t say anything at all.

      Comment by Nate Lawson — September 21, 2010 @ 3:22 pm


RSS feed for comments on this post.

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 81 other followers