Clench is inferior to TLS+SRP

~ Nate Lawson

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 thoughts on “Clench is inferior to TLS+SRP”

  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:

    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.

    1. 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”.

      1. 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.

      2. 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).

    1. 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?

      1. 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

      2. 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.

      3. 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.

  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..

    2. 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:

      Click to access s4p1.pdf

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

    1. 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.

    1. 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.

Comments are closed.