34

One of the major up-and-coming MFA methods is U2F, which relies on an initial key exchange and challenge-response mechanism.

It's a relatively new protocol, and is only starting to see more widespread adoption, notably among big web entities like Google, but it's not the first easy-to-use, key-exhchanging, challenge-responding mechanism out there; in fact, two come to mind quite easily:

  • SSH, which has been around since 1995 and is available on essentially every Linux and BSD box set up since 2000, with growing adoption on Windows via add-on software in older versions and built-in software in newer versions; and

  • PGP, which has been around since 1991, and is actually included on some of the newer Yubikeys (albeit, controversially, with a closed-source implementation in the latest generation), as well as on millions of PCs worldwide, with plenty of high-quality, actively-maintained implementations and libraries for a slew of OSes.

It seems like it would make perfect sense to use either of these widely-available protocols/standards (respectively) as an MFA mechanism for more than just SSHing into a remote machine or encrypting email; so why haven't either gained any traction where U2F is booming?

Jules
  • 1,240
  • 1
  • 10
  • 20
  • 3
    Just convenience and marketing. – Lucas Kauffman Jun 17 '16 at 05:53
  • 8
    ... so the short answer is: The open source community failed to turn their existing solutions into stuff that everybody understands and is able to use easily. – BlaM Jun 17 '16 at 15:35
  • 2
    Funfact: Even TLS-Client authentication failed and this has widespread browser, server, OS, hardware and application support. In the end it all comes down to convenience, ease of understandability and implementation effort. We also have a canonical question somewhere around here why people don't use client certificates... – SEJPM Jun 17 '16 at 20:16
  • Usability is incredibly important when it comes to security. SEJPM's comment about client certificates strikes a cord as I was involved in such an effort in my company's product. I couldn't believe it when my team mate wrote a twenty page instruction manual on how to get certificate revocation working between our product and IIS. – HTLee Jun 18 '16 at 06:10

6 Answers6

25

Let's check out what PGP and SSH actually offer for this purpose:

  • PGP:
    Client must install PGP software which is not installed by default in the majority of the systems. Client must create a PGP key pair. Then he must send the public key to the server so that the server can use it later for validation. When authenticating with 2FA the server will send a challenge which the client must sign with its private key and send the signed challenge back as response. Of course the client must protect its key against theft, maybe with a password.
  • SSH:
    Client must install the SSH software which is not installed by default in the majority of the systems. Must create key pair and send the public part to the server. When authenticating with 2FA against some web service the client must create a SSH connection to a related server and the server must merge the successful authentication using SSH and the login to the website somehow together, maybe with some additional token the client has to give after using SSH. And oops, there might be a firewall in the way blocking SSH. And of course client must protect key against theft.

Thus essentially both solutions boil down to:

  • initially install some software
  • create a static key pair and publish the public part (this might be integrated into the software for convenience but is currently not)
  • somehow get a challenge from the server and somehow send the signed challenge back. And somehow the server must integrate validation of the challenge into the authentication process. "somehow" because there is no already established process for this which integrates everything with the authentication flow used in web applications.
  • and of course the client must protect its key

The same procedure can be much easier done with a client site TLS certificate. This still leaves creation of the certificate as a major problem (but this is possible within the browser too today) but at least the validation is integrated into the HTTPS protocol already.

Additionally I cannot see how these solution provide a better user experience or integration experience than existing 2FA solutions. They are not easy to use, require additional software, require new ways to integrate with the server side etc. And they do not provide a better security either. So why care and not take the newer solutions which were designed with usability and server integration in mind?

Apart from that the current cheap 2FA solutions make use of a mobile phone. These provide usually a better security architecture than current PC's. And they are an additional hardware device the user must have access to which makes the protection offered by 2FA stronger.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 1
    Good consolidation IMO, maybe amend the last paragraph to adapt to full mobile era, i.e. in "[...] use of a mobile phone. [...] they are an additional hardware device the user must have access to which makes the protection offered by 2FA stronger." the strength is lessening as many mobile devices are used to access the "main" to be secured service also via app or browser from the mobile device itself. – Dilettant Jun 17 '16 at 08:54
  • 1
    I was an engineer at PGP from 2004-2011, and I agree with many of the points you raised. We spent a lot of time trying to make it work with existing email clients via proxies and plugins, but because we were always trying to hijack an existing transport (email, or IM) it was always very fragile. Also, most email clients don't implement the spec correctly so you had to deal with endless edge cases. Even if you are an expert, making the system work reliably is difficult. I don't think the issue will be solved until security is integrated into the protocols. – MrEvil Jun 17 '16 at 15:47
  • 1
    Also the difference between TLS and PGP is central control which allows for revenue model and backing by buisiness. If you encrypt email it makes it more difficult for people like Google to extract revenue or implement in browsers. They're is no way to make big money on it, so most big companies won't put forth the effort to establish standards and solve the problem. – MrEvil Jun 17 '16 at 15:50
  • 2FA is most popular among tech people and so are PGP and SSH. Of course most normal people do not have it, but *most people* also don't use 2FA. It's not mutually exclusive either, you can offer PGP and/or SSH (and/or something else) additionally to other methods. The main argument in this answer, "nobody has this," does not hold. – Luc Jun 17 '16 at 19:27
10

Lack of portability

SSH and PGP are widely used, but they are not web technologies. There has been an equivalent web technology for many years - SSL client certificates. However, this is not much used.

The reason is the lack of portability. If you have an SSL client certificate on your home desktop, it's difficult to move it somewhere else. So you can't login from your work laptop, your mother-in-law's desktop, etc.

There is a portable client certificate solution that has been around a long time and is very high security: smart cards. The private key is stored in the smart card and never released. However, this has mostly seen use in high security applications, such as corporate online banking.

Over the early 2000s there was limited innovation around authentication. Efforts aimed at the mass market, like Microsoft Passport and OpenID, didn't really take off. Most products were aimed at the high-end: corporate VPN access, etc. This is now changing, and we're seeing innovation in mass market authentication. For example:

  • Mozilla persona - Essentially makes a client certificate portable by storing it in the cloud. Years ago this would have been rejected as a crazy idea, but in recent times the threat model is better understood and the benefits are apparent.

  • U2F - Brings the high-security of smart cards to the mass market. The devices are more portable, and it's safe to use one device on many different web sites. So U2F is a technology that nicely fits modern usage patterns - hence it's success.

paj28
  • 32,736
  • 8
  • 92
  • 130
  • *U2F essentially makes a client certificate portable by storing it in the cloud* -- I thought that the private key was stored on the U2F device... is that incorrect? – Tim Jun 17 '16 at 16:44
  • 2
    _"U2F essentially makes a client certificate portable by storing it in the cloud"_ there's nothing wrong with presenting the public key (which U2F does when registering a device), but the part about storing the private key in the cloud is flat-out wrong. The U2F device of the users signs a challenge, the private key never leaves the device. Here's a [talk from EuroPython 2015 on how it works](https://youtu.be/YSTsgldazSU?t=25m6s). – Rafe Jun 17 '16 at 18:28
  • Smart cards are not restricted to _"high security applications, such as corporate online banking"_ either, depending on where you live. Here in The Netherlands all banks use a form of two-factor authentication, with two out of the three major banks ([ABN Amro](https://youtu.be/YzA3LGglr1k) and [Rabobank](https://youtu.be/h0DWDdPJD54)) using a reader for the smart card on the debit cards, combined with your PIN. – Rafe Jun 17 '16 at 18:41
  • @Rafe - Can I just check, the bank multi-factor you mention, is this a PKCS11 type device that interfaces with SSL in the browser? Or is it a disconnected thing where you get a code on the device's screen and type that into the online banking web site? – paj28 Jun 17 '16 at 19:00
  • @paj28 By ABN Amro you've to connect a device with USB to your computer and install a Windows driver, by Rabobank you've to scan a QR code with a device and then type the code the device returns on the website and by Regio Bank you've to type a code on a device and then type the code the device returns on the website… – wb9688 Jun 17 '16 at 20:27
  • @paj28 it is not PKCS11, both use [EMV-CAP](https://en.wikipedia.org/wiki/Chip_Authentication_Program) if I'm not mistaken. The ABN reader is manufactured by Gemalto. Its USB connection is optional, it saves you from having to type the challenge and the response on the reader but it was [successfully attacked in 2012](http://www.cs.ru.nl/~rverdult/Designed_to_Fail_A_USB-Connected_Reader_for_Online_Banking-NORDSEC_2012.pdf). The Rabobank reader is a Vasco Digipass 880. – Rafe Jun 17 '16 at 20:44
  • 1
    @Rafe - Ok, while EMV-CAP uses a smart card, it is not an SSL cert on the smart card, like PKCS11. The security features are quite different between them. Really, I have only ever seen PKCS11 devices in high security environments. Anyway, thanks for the helpful comments :) – paj28 Jun 18 '16 at 19:00
  • 1
    @paj28 that is true. For what it's worth, I know that several EU countries use PKCS for smart cards in their eID programs often embedded in passports/driver licenses. In [Belgium](http://eid.belgium.be/en) you can file your taxes, legally sign a PDF, report crime, etc with those. You're welcome :) – Rafe Jun 19 '16 at 10:12
  • 1
    @paj28 you might be interested to know that the new Yubikey 4 models [support PKCS 11](https://www.yubico.com/why-yubico/for-individuals/computer-login/yubikey-neo-and-piv/) as well as U2F. Loading your PGP key on there at least solves the portability problem. Not bad for considering it only costs $40 USD. – Rafe Jun 21 '16 at 11:31
4

Because additional auth factors should, ideally, be out of band. Like a phone, or token, or some kind of telepathic message.

U2F is good because you CAN'T extract the private key and it requires a physical touch to the device before it will sign.

Dave
  • 41
  • 1
1

For the general public, any 2-factor authentication should be understood in under 2 minutes, otherwise it will fail very quickly since few people will be able understand it. That generally requires using something people are already familiar with, or is very simple.

PGP, and SSH are complex technologies that very few people, except developers and IT operations people understand. As Stephen points out, both require not only installing the software, but understanding very complex methods of generating files, sending them to a 3rd party, and (far worse) understanding the underlying concepts involved. For the average person, this would take many hours of training, trial and error, and entirely new concepts. Even then, you'd have high failure rates.

Contrast that with the solutions that are used in 2-factor. Text messages, hard tokens that display numbers, or phone calls. Text messages and phone calls are things people are already familiar with. A hard token is slightly more complex, but a user can be trained in under 2 minutes how to use these devices because they're simple.

Steve Sether
  • 21,480
  • 8
  • 50
  • 76
0

The EnigForm FireFox plugin was a very promisong approach. And in combination with an OpenPGP SmartCard it was at least as secure as FIDO U2FA. It's a pitty it didn't gain widespread adoption.

ulrichard
  • 1
0

Two things.

1. It's the way it has always been

Biometrics or hardware tokens (such as RSA SecurID) were the standard for 2FA, and then everyone got cell phones and later smart phones. Suddenly it was easy to create a second factor by sending people an email to their smartphones, or to an app on their smartphones, or an sms to older phones.

That you could use a public key encryption instead was not considered to be a second factor, since you typically used public keys instead of a password. That was people's perception, and to be honest, I hadn't thought much of it until now either.

2. It's less secure

While a message to an app is already more easily intercepted than the RSA SecurID (or Yubikey or another hardware token) and thus less secure, using public key authentication is probably even less secure than that:

A token can be intercepted as you type it, but your private key can be stolen from your computer for once and for all. The second factor's source is not on a server (sending text messages) or hidden in some tamper-resistant module (a token), it's in the system that you use all the time for lots of things.

(It must be noted that smartcards solve this, but then, I know really few people who use that outside of work.)

Also, most other answers include "nobody has this" in one form or another, and they are right. But most people do not use 2FA either. I think the overlap between tech people who use SSH and/or PGP and 2FA is significant, invalidating the argument that nobody uses SSH, PGP or something similar. Especially places like Github could totally offer SSH as a second factor; they already support SSH keys (and people use it!), just not for 2FA.

Luc
  • 31,973
  • 8
  • 71
  • 135
  • Can't agree with you. SSH/PGP keys are not less secure, the same way a private key can be stolen it can be a smart phone or rsa secure id, by the time you notice and actually can disable it is too late. Furthermore, PGP and SSH keys can be revoked. Even more, private keys can and SHOULD be protected through passwords. And I wouldn't say that most people don't use 2FA, every mildly decent bank website nowadays has 2FA enabled, webmails have been suggesting it for a long time and it won't be long until they enforce it – Mr. E Aug 31 '18 at 00:32