FIDO2: The Dream Of Password-Free Authentication On The WWW

Of all the things which are annoying about the modern World Wide Web, the need to create and remember countless passwords is on the top of most people’s lists. From dozens of passwords for everything from social media sites to shopping, company, and productivity-related platforms like Github, a large part of our day is spent dealing with passwords.

While one can totally use a password manager to streamline the process, this does not absolve you from having to maintain this list and ensure you never lose access to it, while simultaneously making sure credentials for the password manager are never compromised. The promise of password-less methods of authentication is that of a world where one’s identity is proven without hassle, and cannot ever be stolen, because it relies on biometrics and hardware tokens instead of an easily copied password.

The FIDO2 project promises Web Authentication that means never entering a password into a website again. But like everything, it comes with some strings attached. In this article, we’ll take a look at how FIDO2 plans to work and how that contrasts with the state of security in general.

Web of Trust

The scope of online security goes far beyond the connection between a server and client. It starts with one’s own system(s), and from there spirals outward to systems and individuals who are ever less known to you and as a direct result less trustworthy. The assumption is made that one’s own systems are safe and secure, with every part of it known and audited. This implies that storing secrets on these systems is acceptable.

In the immediate circles near these systems one can find entities which are deemed relatively trustworthy, such as a major shopping site or your financial institution’s online banking features. The general assumption there is that they do their utmost to secure their systems, if only because of the (financial) repercussions when something does go wrong, so we trust that they got their servers in a state comparable to our own. That’s why you don’t mind trusting them with sensitive information, like control over your bank account, or your credit card information.

The web of trust doesn’t necessarily focus on how easy it is to establish a secure connection between you and another entity. Eminently more important are the questions of whether you can trust this entity with your information, and how secure this ‘secure’ connection actually is.

How We Determine Identity

An essential part in establishing a secure communication link is in determining the other side’s identity. This is where security certificates come into play: based on a root certificate that is provided by some trusted authority, one can determine with relative certainty that the remote side is what it says it is. Here one implicitly trusts the root authority.

In multi-factor authentication terms, the remote service’s security certificate counts as ‘something one has’, as in a secret object. What one provides with a password-based login is ‘something one knows’. Two-factor authentication schemes involving ‘something one knows’ and ‘something one has’ are usually based around a physical object (key) and an access code that allows this key to be used.

Examples of this include an ATM card and the PIN code linked to it, or a hardware device that generates a code after entering the PIN, such as commonly used with online banking. Combining a phone number (to send a text message with a code) or email address with password-based login is also very common for two-factor log-in schemes.

The Premise of FIDO2

The FIDO2 project is a joint effort between the FIDO (Fast IDentity Online) Alliance and the World Wide Web Consortium (W3C). It’s a continuation of previous projects, notably FIDO Universal 2nd Factor (U2F) protocol, which involves a USB-based hardware token (‘Something you have’) that acts as a hardware-based authenticator. FIDO2 is similar, but adds multi-factor authentication.

At the core of FIDO2 lies the WebAuthn (Web Authentication) standard, which defines a number of requirements for a conforming website, browser and compatible authenticator. In essence it’s a public key-based security scheme, whereby one has to register a device that will function as the authenticator. This can be a laptop with a fingerprint scanner, Windows Hello, Apple FaceID, or a smartphone with such biometrics options. Alternatively a PIN code can be used instead of biometrics.

In addition to this, CTAP (Client To Authenticator Protocol) allows one to link a device like a smartphone with a laptop to act as an authenticator for the browser on the laptop using NFC, USB or BLE (if supported). Regardless of the setup, there’s always the remote service with which one registers or already has registered the authenticator device. This is similar to how one would register their public SSH key at a site like Github, yet this also means that you would want to register two or more authenticators for a service, in case one is lost, stolen or otherwise becomes unavailable.

Here the device is ‘What you have’, while biometrics would be ‘What you are’, or alternatively a PIN code or similar could provide ‘What you know’.

Welcome to the 90s

The OpenSSH logo.

Outside of the world of browsers, password-free logins have been common-place for a long time courtesy of little known technologies such as SSH (Secure Shell), which since its creation in 1995 has allowed users to log into remote systems without ever entering a password. This is an essential part of crucial infrastructure, allowing automated tasks to communicate with remote systems over secure links without requiring a human being (AKA a sysadmin or intern) to enter a password every time a new connection is made.

These days this distinction is very noticeable for example on sites like GitHub, where the interaction with the Git repositories on the GitHub servers can be performed either via secure HTTP (requiring a username and password) or SSH (password unneeded after unlocking the private key). Here having a password manager that is unlocked the moment one logs into one’s PC allows for essentially password-free interaction with such secure remote services.

Biometrics: A Public Secret

One big premise behind eradicating the use of passwords is that they are supposedly insecure, with biometrics being far superior. This is why systems such as facial recognition, fingerprint recognition, as well as iris and palm vein scanning have become hugely popular, especially smartphones providing at least a fingerprint sensor (though Apple ditched it in favor of facial recognition because of aesthetics).

Graphic courtesy of the Electronic Frontier Foundation.

Unfortunately, fingerprint scanners are hopelessly inaccurate, as we have covered recently as well. The main reason behind fingerprint sensors being added to smartphones has been to make unlocking it less of a bother for phone junkies who will reach for their phone on average 52 times a day, according to a 2018 study by Deloitte. A simple thumb or finger pressed on a sensor or quick glance at the front camera to unlock the device would seem like a godsend at that point.

Facial recognition doesn’t score much better when it comes to security than fingerprints, either. Apple’s high-profile Face ID has big problems distinguishing between twins, family members and children, according to a security paper Apple released a few years ago. This paper notes that in the case of twins, siblings who look alike and children under the age of 13 one should not use Face ID for security reasons.

Another two strikes against biometrics are that they are non-revocable (you’re stuck with them for life), and that they are not a secret as such. While they are a part of you, you also carry around your face in public, leave your fingerprints on everything you touch, leave your irises wide open to scanning, not to mention the number of times you rest your palms on a surface that could contain a scanner.

By making the copying of biometrics and defeating their scanners ever more profitable, we might risk unleashing a rush to develop ever more sophisticated technology to get around biometrics, rapidly degrading it as a security option.

What You Don’t Have Any More

Clearly the security benefits of moving everyone from passwords to what will essentially be a biometrics wet dream should be questioned as being doubtful at best. At the horizon looms a future in which one’s smartphone could be stolen and unlocked using the same fingerprints which you have left all over the device, after which all of your online accounts will be open to whoever now has the device. It’s like writing your PIN code on the ATM card, just with more biological proteins and sophisticated technology involved.

Losing the authenticator device also means that you instantly lose access to every single online account that requires 2FA. It’s possible you planned for this and you also set up your laptop as an authenticator, or you have a second (smartphone) device around that you also registered. If you’re lucky enough to be in this group, you’d next be rushing around, logging into every serviced you registered with to unlink the device that was stolen.

Costs and Benefits

When it comes down to it, passwords have a number of distinct advantages:

  • They’re easy to change.
  • One can have a unique password for each service.
  • Password managers make remembering passwords unnecessary.
  • They’re unknown to everyone but you.

With a system like what FIDO2 proposes with Web Authentication, one would have the same device for all services, no ability to change this identifier (device) and a ‘secret’ to unlock it which is both not a secret and increasingly easier to copy.

Adding a password in KeePass.

Realistically speaking, what Web Authentication offers is a single sign-on service using biometrics, PIN code or some gesture-based login, with questionable benefits over practicing proper password management. Frankly, by the time one is entering a PIN code or equivalent and still considers this to be ‘password-free’, some serious questioning of one’s definitions should take place.

Personally, I have been using the fully open-source KeePass as my password manager on Windows for years now, which allows me to securely manage my passwords. The encrypted password database file is available on all of my devices and backed up in multiple locations. Any device that KeePass works on and with internet access also provides me with access to these passwords, while thieves have two strong passwords to brute-force before the device is remotely wiped. For me the benefit of Web Authentication is essentially zero, especially as I only have a single device that performs biometrics (my smartphone).

If the future of Web Authentication is anything like U2F, it will likely end up making a little bit of a splash for a number of years before being quietly retired. Yet who knows? This might become the one log-in method to rule them all. What are your thoughts on this technology? Would you retire your cool passwords for futuristic, biometrics-based access?

29 thoughts on “FIDO2: The Dream Of Password-Free Authentication On The WWW

  1. “The assumption is made that one’s own systems are safe and secure, with every part of it known and audited. This implies that storing secrets on these systems is acceptable.”

    Secure boot, and DRM.

    1. It’s well known in IT circles, but not among common users. If you want to get some blank looks, mention it to someone outside your field and family. I recently saw a friend get banned from r/AskReddit for posting an SSH address. The moderator mistook it for an email address and flagged the post. I’ve worked with DBAs who thought SSH key-based authentication was some form of black magic. Not a SQL Server shop, Oracle on linux.

  2. Security on the internet is a large can of worms that frankly is rather hard to do much about.

    A simple solution is to use a password manager, but this is generally just a bodge to be fair, since its main downside is that it could loose its database of passwords, and then one is locked out from practically everything… (one can usually recover with “I forgot my password” and have the site send a temporary one to one’s registered email. Unless you used the password manager for that too…)

    Another solution is to have a trusted third party that knows that it is you, and have them do part of the login for you. Downside here is that the trusted third party can be compromised… A quick solution is to use more then one for each site, one would also need login credentials for each of those trusted third parties, but this shouldn’t be too much of a hassle, one would only need 3-5 of them, just in case one gets compromised, then one still has two-four more, and just require that the websites one logs in on needs at least 2-4 valid confirmations from these third parties to allow one to log in. But what website will support this convoluted mess of a login system? (Even though it would likely be fairly simple to implement in practice, and likely only need a small bit of code for any website wishing to use it. Though, it will likely be one additional set of database values to keep track of…)

    Yet another solution is to write in the longest string of gibberish one can think of, then always say, “I forgot my password” each time one logs in, after all, the website should send a temporary password to one’s email. And as long as that email service provides good security, then one’s authentication is literally the fact that one has access to one’s own email account. (So here one only needs to know 1 password.) Downside, one’s email can be compromised, and then one is screwed. But one is screwed regardless since most websites will send out temporary passwords in this fashion already. (so hope your email provider has their security in check, because it is a literal single point of failure.)

    In the end, providing a secure and easy way to login to any website is a tricky problem to fix.

    Though, practically every website has their preferred method, so getting any standardization in the field is likely next to impossible.

    1. > Downside here is that the trusted third party can be compromised…
      It will be compromised.
      Here, I fixed it for you ;-). It happened before, it will happen in future. No third party is safe enough.

      1. “A quick solution is to use more then one for each site]…[one would only need 3-5 of them, just in case one gets compromised, then one still has two-four more, and just require that the websites one logs in on needs at least 2-4 valid confirmations from these third parties to allow one to log in.”

        So if one were to get compromised, at least one has some time to exchange that. Something one likely can bake into the system by having the other third parties send out an update for what one’s new trusted third part is for exchanging the compromised one.

        If one were to setup a simple to use, and safe standard for such third parties, and it gets at least some market foothold, then I personally wouldn’t be too surprised if it were to take over what passwords currently are. Downside, one then needs a third party manager app/device….

        1. Honestly, I am fed up with another “third-party app/device” we already have at least HOTP/TOTP standards to use one-time passwords. But no, most places can’t give you token, which YOU control, but send confirmation codes over SMS (like that is secure, right?).

          Add here that anything like this will also break automation (I want to, say, pull my email in peace, automatically, from headless machine, without entering anything). This use-case is largerly forgotten when something is done in recent times.

          I’d keep my passwords. They are long, they are autogenerated per site, and encrypted with gpg. Oh, and synced via private git repository :).

          PS. We couldn’t damn do normal password support, special characters or unicode symbols still break many places. And I am not speaking about certain banks, where…. drumroll…. password ends up case insensitive (HOW!??!?!)

  3. Unfortunately both my bank and my online stock trading have decided to force SMS as the *required* ”2 factor” with no other alternatives. It is stupid policy as cellphone plan here are an arm and a leg. So if I travel, I would use a local sim card as it is a lot cheaper than the roaming charges.

    Sadly google also do stupid things to block access based on IP and require phone to unlock.

    As for anything ”one Authentication”. I don’t like single point of failure and prefer to keep my multiple identities compartmentalized. They already have enough pieces of my information and I don’t want any one of them to have my full web history.

    I hate hipsters generation of ”security” people these people hire as they don’t allow for any alternatives.

    1. I hope they don’t restrict your password as well. My bank does (fixed 6 characters alpha-numerical only).

      Seriously I don’t trust my bank with electronic security, in the past they were the one also letting you reset your password (online…) with a predefined (and easy) question/answer.

  4. Anyone else heard of SQRL? Steve Gibson’s latest never finished project so we could just scan QR codes? for secure login so we wouldn’t need passwords anymore. The perfect is the enemy of the good. I don’t see it being adopted, mainly because the news cycle that caused it to be written was years ago and even a weak version (for things I don’t care as much about like blogs) would have caused enough adoption so it might have made its way to facebook, twitter, or Google.

    The problem with USB based tokens is they are difficult to use with mobile devices.

    A bluetooth (probably LE) device would be more universal. The other problem is getting browsers to adopt it and the rest of the infrastructure (didn’t Hackaday have a password hardware thingy?). Infrastructure wise, getting what credential to unlock to the device is also a pain assuming it is a password store and not just an authentication “something you have” token.

    Some kind of bluetooth LE device with simple display and pin pad (think the old ANSI DES tokens) might work.

  5. I have been using the Mooltipass Mini, a bunch of software based password managers, FIDO2 keys, Mobile Text/Authenticator, and plain old mathematical “formulas” on paper needing “something I know” to translate it into passwords.

    And I must admit that I prefer to use the FIDO2 keys, whenever possible.
    Unfortunately, it’s not fully supported in that many places.

    I’m primarily using the keys for 2FA but there’s also some non-critical sites where I use them for passwordless login, and both with and without a pin depending on how critical the site is.

  6. i don’t see what advantage hardware keys have over software keys. even the thing that makes the usb key do its thing is the firmware on the device. therefor no matter what interface you use you ultimately depend on a block of data which could be stored anywhere. it wont be long before people are virtualizing those devices for convenience (say on devices that dont have usb ports). also that creates a thing you can lose that locks you out of your account so virtualization would also be essential for backup. might as well just cut out all that hassle and make a software authenticator. same idea as a password manager, but without the user needing to know what those are.

    1. The us of hardware keys means that the keys cannot be extracted (easily). Key management is the concern upon which the security of these systems hinge — everything else is just protocol (not to trivialize the importance of correct protocol implementation). Software-based key storage works the same way cryptographically, but it is straightforward to duplicate bits stored in software systems (even if they are encrypted blobs), and then you can do all sorts of things (cloning identity, offline brute force analysis, etc) that are not practical with hardware protection.

      But FIDO does have provision for software-based authenticators, as well. (I know, I implemented the client-side FIDO spec about 2 years ago for a client). Your authenticator is meant to also have a ‘metatdata’ document that defines these and other characteristics of your technology in general. That is used when bringing up the ‘server’ side of the system (the ‘relying party’), and a policy decision can be made at that time as to whether to honor or not authentications coming from a software-only solution.

  7. Why is having this as part of a web browser a good design?
    Seems like web browsers have become incredibly complex behemouths, with
    all sorts of legacy protocols, various engines, and bits laying around.
    (Seem like fertile ground for security exploits.)

  8. The problem with all these various authenticators is that they’re only worth the time and effort to set up if almost all of one’s accounts can use them such that remembering whether a given site uses a key or a traditional password is no longer necessary. But, as the OP notes, only a relatively small number of websites have adopted such a system and even there it’s a fractured landscape of hearsay, special rules and customer service calls.

    Think of it like the classic Windows (passwords) v Linux (FIDO/U2F) debate. The former may be crufty and obtuse, and lacking the latter’s power and flexibility in the hands of a sufficiently trained power user, but the whole world has figured out how to work with it and generally standardized on common practices. And ultimately a system is only as useful as the things you can do with it.

    In related news, props to HAD for not taking Big Tech’s bait and requiring yet another password. Sites that demand account management for things like posting silly words on the Internet are part of the security problem.

  9. I don’t see why we can’t just use public/private key pairs like SSH does? Add the ability to revoke your key if need be and all should be good. Why isn’t this ever proposed as a solution? It works very well for ssh, why not websites?

  10. In my opinion the title is misleading. The combination of password free and secure does not exist. Passwords can take many forms. ssh also accepts a certificate. Well then that is your password a long binary string. Be lucky you do not have to type it every time.
    There is no security without having some form of authentication and authorization and at some point you will have to type, copy or carry something around. So fido(2) can change the hassle, but certainly won’t prevent it, that is just marketing.

  11. Just my 2 cents… fido2 is marketed as the most secure solution against ***PHISHING***…
    If you cannot stop a worm/man in the middle from reading your email/password tuple that’s game over for you.
    Also third parties are definitely not reliable
    ( facebook leaked usernames passwords of millions… anyone been pwnd yet?)

    Assuming your device is secure is dangerous. That is why you leave an specialized key for that. the surface area of atack is smaller than your laptop/cellphone.
    Fido2 protocol stablisbhes some nice feats too. For starters the server does not stores a simple password, it stores your public key. A challenge and only the private key can decrypt it.

    You can produce as many public keys as you want for different sites from a single private key. The protocol uses a combination of the site’s url and the username as part of the public key generation meaning if this public key gets leaked it cannot be used in another site’s. (And this is what keeps phishing away! A man in the middle cannot attack this with a fake url as the result will be different)

    Outside phishing there are downsides… your keys can be physically stolen and lost. That is pretty much belittled by the specification as “outside of the scope” but if the standard is to become the popular, expect some street thugs to ask for wallets AND FIDO2 keys in the future…

  12. I would really like it when we start explaining MFA as a combination of
    – something only you have
    – something only you know
    – something only you are

    For one thing, it helps explaining why security questions are a bad thing ;)

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.