Improving Authentication On The Internet

On the 17th of this month, at the invitation of Comodo, the major CAs and browser vendors (including mozilla.org) are having a meeting in New York to discuss some of the issues surrounding the future of SSL and trust on the Internet.

As a way of working out my thinking on this, I’ve written a paper called “Improving Authentication On The Internet“.

It starts with the basics, mostly as a way to confirm that my understanding of the current situation is correct. All comments, both correcting my facts and giving alternative views, are very welcome.

7 thoughts on “Improving Authentication On The Internet

  1. Hm, you’re SSH-example probably mirrors how SSH is used by many people. But SSH often comes with preinstalled root certificates/keys (nomenclature differs quite a bit between SSH, GPG and X.502/SSL communities, sorry if I mess things up). SUSE for example signs its RPMs with their certificate. So I don’t think you should use SSH as a known authenticating mechanism.

    Instead of locks and dollar signs I’d propose something else: Even though a lock for privacy seems reasonable it’s already been used for meaning everything from encryption to authentication and overall “security”. Probably leave the lock a bit like now but make it a three state icon (open, non-highlighted for unencrypted and non-authenticated channels, closed, non- or semihighlighted for encrypted channels and fully highlighted if authenticated and encrypted). Make an icon specifically showing encryption (closed envelope, a chain?) and one for authentication (a official looking stamp? A seal (could also mean privacy for some people)). Or somehow put it all into one thing showing all states. But I wouldn’t use just the lock for encrypted, non-authenticated channels. People will just think that a lock means secure, I don’t think people will associate just the lock and the lack of anything else with “missing” authenticity.

    There are interesting discussions going on about the (im-)possibility of revocation. I think “IEEE”, “PKI” and “revocation” should turn up some interesting reads.

  2. Uhm, I should use that “Preview” button. SUSE naturally signs its RPMs with its GPG key and I don’t think that they deliver some SSH key with their distro. What was I thinking? Nonetheless it’s perfectly possible to use SSH with preinstalled certificates.

    Sorry for confusing myself and probably others.

  3. You might want to add to your threat model “I’m talking to who I think I’m talking to, but someone is modifying the messages en route”: for example, consider bit-flipping attacks, where flipping one bit can make a payment go to the bad guy’s account instead of the intended one, or make a payment twice the size. This comes under the heading of maintaining message integrity.

  4. Disclosure: for my daytime job in a very large telecommunications vendor, I work on authentication systems for VOIP SoftSwitches.

    I think that the use of Digest-Authenication should be encouraged. Firefox already implements most of it, but bug 270447 still has to be fixed (incorrect Http-Digest with MD5-sess).

    Many webservers have started to use login-screens over TLS, thinking that they’re save. Maybe save against eaves-dropping, but that doesn’t help if the login-page was faked anyway. The presence of the lock-icon isn’t a guarantee anymore.

    Http-Digest can help you check a password with a server (over TLS or over a normal connection), without actually exchanging the password itself (only the real server will know it). And the client can also verify the server itself, although that only happens in the answer (Authentication-Info). The problem is that the server isn’t required to send Authentication-Info back. Can’t we enforce it ? If a server is not sending it back, or incorrect, we should warn the user that it might be a fake server, who might *not* be in possession of the password. The fact that it’s using TLS, or is using the correct DNS-name is no guarantee that it’s correct. The server might be compromised or spoofed, or there might be a man-in-the-middle server that is secretly listening in on the conversation.

    Digest-Authentication is used in a lot of VOIP systems, which often don’t use TLS at all. And they don’t need to. But they’re still secure.

  5. Probably leave the lock a bit like now but make it a three state icon

    I think that it’s important to have clear distinctions – adding and removing icons is a much more visible change than tweaks to the look of a single icon.

    Neil said: You might want to add to your threat model “I’m talking to who I think I’m talking to, but someone is modifying the messages en route”

    Are there attacks where this is possible but a full MITM is not? I’d say this falls under the “privacy” section.

    jhermans said: The presence of the lock-icon isn’t a guarantee anymore.

    That’s what we are trying to fix! :-) Thanks for your interesting comments about Digest-Auth.

  6. Another good read, Gerv, thanks!

    Did you consider using stars instead of dollar signs in the authentication UI? These would be more culturally neutral and already have traction from other areas such as hotels and restaurants: “This is a three-star restaurant” likens to “This is a two-star web-site”.

    Do you think it’s feasable to get all the browser vendors to update at once? Would it be possible for a sub-set to move forward on their own? This would effectively force the other vendors into action in the medium-term, as banks would be likely to start recommending (or even mandating) browsers that support the authentication UI.

    Taking the above two points in conjunction, perhaps it would be better to show between one and three stars for the levels. This would make it evident which browsers supported the UI and which not, at the cost of some more status-bar clutter. This might also improve user perception, as having two stars as the top rating is a little miserly.

  7. Unfortunately, the biggest threat on the Internet is not phishing, but a problem ruled out of scope in your paper — trojaned clients. There are millions and millions of infected PCs (the zombie army) out there. Today, we *think* that their primary purpose is to do something in the email spam world — send out billions of emails or host the advertised website. But, they could easily be keyloggers either in addition to the spam or instead ofthem. An infected machine would almost be a guarenteed phish. The zombie controllers still want to increase the total number of zombies, so continuing to spam to increase the zombies won’t stop. This is certainly a *very* difficult problem, and one that a browser is not likely to be able to solve alone. (Btw, this is the best link to attack — problems that require many actions by many constituents to solve will ensure the problem lasts for a long time).