* = For now, fingerprint or lock screen authentication applies only to one Google property.

Share this story

It could soon become easier for Android users to securely log in to Web accounts. Starting today, Google is rolling out a service that lets people on version 7 and later of Google’s mobile operating system use their device’s fingerprint or screen lock instead of a password when visiting certain Google services.

For now, the service is available only for Google’s Password Manager property, and even then it's only when people are using select Android models. Over the next few days, the feature will be available to all Android 7 and above devices. Google has no timeline for when people will be able to use the feature when signing in to Gmail, other Google properties, or for non-Google sites.

The new sign-in method uses the industry-wide FIDO2, W3C WebAuthn, and FIDO CTAP standards jointly developed over the past few years by a long list of companies. The standards are designed to wean the world off its reliance on passwords by making it easier to use other authentication factors such as physical security keys, fingerprints, or other biometrics.

The new feature, which Google announced in a blog post published Monday morning, is one of the first times it has become possible to log in to a Google property using the FIDO2 framework. Google says it marks the first time an interaction on the Web, as opposed to one inside a native mobile app, has allowed the use of a biometric to authenticate an action.

“An important benefit of using FIDO2 versus interacting with the native fingerprint APIs on Android is that these biometric capabilities are now, for the first time, available on the Web, allowing the same credentials [to] be used by both native apps and web services,” Google Software Engineer Dongjing He and Google Product Manager Christiaan Brand wrote in Monday’s post. “This means that a user only has to register their fingerprint with a service once and then the fingerprint will work for both native application and the web service.”

People who have a device running Android version 7 or higher and have it configured to use a Google account and a “valid” screen lock can try out the new feature by doing this:

Convenience as the enemy of security

Monday’s post said that fingerprints are never sent to Google servers, and instead those remain “securely stored” on devices. Per a core requirement of the FIDO2 design, only a cryptographic proof that a fingerprint has correctly been scanned is sent to Google’s servers.

The convenience provided by the feature, assuming it comes to more widely used properties, is great, but users should be aware that it may come at the cost of some security. While courts aren’t unanimous, they frequently grant more latitude to defendants who refuse to divulge passwords, since doing so amounts to testifying against oneself. Biometric information, by contrast, is often regarded as evidence that investigators can confiscate.

Another potential loophole: today’s blog post says Android users can use their device fingerprint or lock screen to authenticate themselves. That means that people have the option of using the PIN, password, or pattern that unlocks their phone to authenticate themselves to their Web account. It’s hard to see how this is any more convenient than entering a password into a browser. It’s also arguable this arrangement might degrade security since many phone users are reluctant to use long, complex passphrases to unlock their devices since it’s such a hassle to enter them so often. If a phone were ever to be lost or stolen, it might lead to a Web account being compromised.

Another wrinkle: the feature Google introduced today can’t be used on the site’s password manager if users have deployed a passphrase to sync sharing among various Chrome browsers. That means that in order to use FIDO2 authentication, users will arguably be required to turn off a protection that many consider a best practice. A Google spokesman said use of a sync passphrase makes passwords invisible to Google. In that case, FIDO2 authentication works only when users have an application on the client-side to decrypt the passwords, the spokesman said, without specifying what such client-side applications are.

Monday’s rollout of the new authentication method comes after years of pronouncements that passwords are dead. The limited availability of the feature—to a single Google property and then only to people using Android—underscores just how exaggerated those reports of the password’s demise are. Still, it demonstrates limited progress, and that’s better than nothing.

For another potential loophole, today’s blog post says Android users can use their device fingerprint or lock screen to authenticate themselves. That suggests that people have the option of using the PIN, password, or pattern that unlocks their phone to authenticate themselves to their Web account. It’s hard to see how this is any more convenient than entering a password into a browser.

To me this sounds like a scenario where I unlock my phone screen and then for the rest of the session the new password mangler fills in PW forms without requiring any farther interaction.

The new sign-in method uses the industry-wide FIDO2, W3C WebAuthn, and FIDO CTAP standards [...] That suggests that people have the option of using the PIN, password, or pattern that unlocks their phone to authenticate themselves to their Web account. It’s hard to see how this is any more convenient than entering a password into a browser.

I can't tell them apart, are these the schemes that also protects against MITM phishing attacks?

That suggests that people have the option of using the PIN, password, or pattern that unlocks their phone to authenticate themselves to their Web account. It’s hard to see how this is any more convenient than entering a password into a browser. It’s also arguable this arrangement might degrade security since many phone users are reluctant to use long, complex passphrases to unlock their devices since it’s such a hassle to enter them so often. If a phone were ever to be lost or stolen, it might lead to a Web account being compromised.

There are a bunch of reasons why this is better.

First, a sufficiently complex password is almost certainly harder to type than whatever you use to unlock your phone, so you're definitely gaining convenience.

Second, a phone is much less likely to be electronically compromised than a desktop, due to the heavily sandboxed nature of the phone operating systems. So you're trading off password complexity for a reduced chance of compromise (e.g. key logging), which seems like a reasonable tradeoff to make.

Third, this reduces your attack surface to someone physically stealing your phone. Due to the authentication standard, attacks on your Google account are going to be attacks against certificates/key pairs, so brute force will not be effective. The single biggest attack surface for most users is a remote, digital attack on their account. Which this removes.

Finally, if your phone is stolen, you know it. Which means there can be no surprise account compromises, no wondering if you were hacked and don't know it. Phone theft is definitely a problem, but at least you have the opportunity to act on it immediately.

It's not that there are no downsides, but most people are making worse tradeoffs right now in the name of convenience, like password reuse, or simple passwords. At least a phone provides a hardware token that must be stolen in order to break into an account.

For another potential loophole, today’s blog post says Android users can use their device fingerprint or lock screen to authenticate themselves. That suggests that people have the option of using the PIN, password, or pattern that unlocks their phone to authenticate themselves to their Web account. It’s hard to see how this is any more convenient than entering a password into a browser.

To me this sounds like a scenario where I unlock my phone screen and then for the rest of the session the new password mangler fills in PW forms without requiring any farther interaction.

Sounds like a pain since my normal screen time session is like 5 minutes at the most.

That suggests that people have the option of using the PIN, password, or pattern that unlocks their phone to authenticate themselves to their Web account. It’s hard to see how this is any more convenient than entering a password into a browser. It’s also arguable this arrangement might degrade security since many phone users are reluctant to use long, complex passphrases to unlock their devices since it’s such a hassle to enter them so often. If a phone were ever to be lost or stolen, it might lead to a Web account being compromised.

There are a bunch of reasons why this is better.

First, a sufficiently complex password is almost certainly harder to type than whatever you use to unlock your phone, so you're definitely gaining convenience.

Second, a phone is much less likely to be electronically compromised than a desktop, due to the heavily sandboxed nature of the phone operating systems. So you're trading off password complexity for a reduced chance of compromise (e.g. key logging), which seems like a reasonable tradeoff to make.

Third, this reduces your attack surface to someone physically stealing your phone. Due to the authentication standard, attacks on your Google account are going to be attacks against certificates/key pairs, so brute force will not be effective. The single biggest attack surface for most users is a remote, digital attack on their account. Which this removes.

Finally, if your phone is stolen, you know it. Which means there can be no surprise account compromises, no wondering if you were hacked and don't know it. Phone theft is definitely a problem, but at least you have the opportunity to act on it immediately.

It's not that there are no downsides, but most people are making worse tradeoffs right now in the name of convenience, like password reuse, or simple passwords. At least a phone provides a hardware token that must be stolen in order to break into an account.

Your conclusion doesn't quite stack though. All you've really done is put forward a good, valid argument for why this would work well as a second factor.

Which, really, is what it should be.

For the user, the risk isn't just phone theft, it's dropping it down the toilet, losing or otherwise breaking it. Any one of those leads to serious inconvenience.

Having a phone capable of being a FIDO2 device is great, and avoids the hassle of a dedicated dongle, but as a second factor, you could also have an additional dongle registered and stored somewhere without having the same concerns about one going walkies without you noticing

That suggests that people have the option of using the PIN, password, or pattern that unlocks their phone to authenticate themselves to their Web account. It’s hard to see how this is any more convenient than entering a password into a browser. It’s also arguable this arrangement might degrade security since many phone users are reluctant to use long, complex passphrases to unlock their devices since it’s such a hassle to enter them so often. If a phone were ever to be lost or stolen, it might lead to a Web account being compromised.

There are a bunch of reasons why this is better.

First, a sufficiently complex password is almost certainly harder to type than whatever you use to unlock your phone, so you're definitely gaining convenience.

Second, a phone is much less likely to be electronically compromised than a desktop, due to the heavily sandboxed nature of the phone operating systems. So you're trading off password complexity for a reduced chance of compromise (e.g. key logging), which seems like a reasonable tradeoff to make.

Third, this reduces your attack surface to someone physically stealing your phone. Due to the authentication standard, attacks on your Google account are going to be attacks against certificates/key pairs, so brute force will not be effective. The single biggest attack surface for most users is a remote, digital attack on their account. Which this removes.

Finally, if your phone is stolen, you know it. Which means there can be no surprise account compromises, no wondering if you were hacked and don't know it. Phone theft is definitely a problem, but at least you have the opportunity to act on it immediately.

It's not that there are no downsides, but most people are making worse tradeoffs right now in the name of convenience, like password reuse, or simple passwords. At least a phone provides a hardware token that must be stolen in order to break into an account.

Next: how do we stop people stealing phones?

It seems to me we haven't yet fully digested this. As phones become more important as biometric identifiers, the downside of theft gets greater. I was reminded of this at the weekend because I was using my phone on TfL and read about a proposal to start using phones as identifiers on the wider rail network - but using remote readers, which means always-on phones. Even now, if someone steals your phone while in the London Underground, they can use it to exit a station and you now have a problem.

At some point the legal system is going to need to start taking the theft of phones as seriously as the theft of safe keys to a bank. But that has a second aspect to it; people will need to stop walking down the street holding phones out for any passing thief to grab. They wouldn't do that with their house keys attached to a tag with their personal details, would they?

I'm becoming less and less sure that this is the right approach, and thinking more that things like Yubikeys but with somewhat increased capability are the real answer. Ideally they should be on you but in a more secure location - and the theft of a linked phone should stop it working immediately.

This is probably better for most people assuming they use complex PIN codes (as mentioned by the article already) and strong passwords already.

Really want to emphasize that the best passwords are something you have (e.g. your phone, your face, USB FOB, etc.) and something you know (e.g. pin, password, etc.)

Ideally we'll get to a point where there will be true 'multi' factor authentication where the device would automatically check your face profile, fingerprint, voice confirmation, typing style, step cadence, bluetooth/NFC fob and password or pin response and give you different levels of access depending on how certain it is sure that you are you.

Just want to play a game or play around with some innocuous app, face recognition is fine. Social media? Supply a fingerprint or require encryption fobs to be nearby. Want to open up secure financial apps or device/account administration, then your phone would start asking you for voice prompts and pin details.

It’s hard to see how this is any more convenient than entering a password into a browser. It’s also arguable this arrangement might degrade security since many phone users are reluctant to use long, complex passphrases to unlock their devices since it’s such a hassle to enter them so often. If a phone were ever to be lost or stolen, it might lead to a Web account being compromised.

I assume this uses entire encryption key of the device, so there is no much difference between pin and fingerprint. Similar to how a 4 digit pin of a modern phone encrypts files in a safe way because that pin is not the full key. How does thief get the pin if 10 tries automatically erase the device?

The new sign-in method uses the industry-wide FIDO2, W3C WebAuthn, and FIDO CTAP standards [...] That suggests that people have the option of using the PIN, password, or pattern that unlocks their phone to authenticate themselves to their Web account. It’s hard to see how this is any more convenient than entering a password into a browser.

I can't tell them apart, are these the schemes that also protects against MITM phishing attacks?

As far as I can tell not a single web standard is concerned with mutual authentication. TLS has support for it but there are no mechanism to actually authenticate the server as well as the user which means that DNS poisoning and rest of the MitM attacks will work just fine. Of course, the entire CA based "security" is a joke so it probably doesn't make much sense to bother with it to begin with.

With the YubiKey and FIDO U2F Security Key, user login is bound to the origin, meaning that only the real site can authenticate with the key. The authentication will fail on the fake site even if the user was fooled into thinking it was real. [...]Token binding is an additional protection supported by FIDO U2F that secures the connection between the browser and the service to prevent man in the middle attacks. [...]Token binding allows servers to create cryptographically bound tokens (such as cookies, OAuth tokens) to the TLS layer, to prevent attacks where an attacker exports a bearer token from the user’s machine to present to a web service and impersonate the user.

Your conclusion doesn't quite stack though. All you've really done is put forward a good, valid argument for why this would work well as a second factor.

Which, really, is what it should be.

For the user, the risk isn't just phone theft, it's dropping it down the toilet, losing or otherwise breaking it. Any one of those leads to serious inconvenience.

Having a phone capable of being a FIDO2 device is great, and avoids the hassle of a dedicated dongle, but as a second factor, you could also have an additional dongle registered and stored somewhere without having the same concerns about one going walkies without you noticing

I disagree that this only works as a second factor. My point is that a hardware token + PIN (which is what this boils down to) is, for most practical purposes, a more secure method of authentication to a password.

I would suggest that this is not a great use case for a head of state, or other people who are dealing with targeted theft. But that's not your average person. Your average person's highest risk comes from password reuse, general email phishing, general virus infection, things like that. Non-specific threats that are designed to capture as many credentials as possible.

I think some of the concerns around practicality just boil down to a new technology that's not widely adopted. If every device in your life (e.g. tablet, cell phone, laptop) is this type of login (which is where we're headed, I think), the chance of you losing your only login device is lessened greatly. And of course, there will always be a need for some kind of account recovery process.

Anything that gets us away from passwords is fine by me. Right now if i access gmail on a foreign PC my phone basically requests a certain combination of numbers that show up in order to continue sign in on that PC.

It seems to me we haven't yet fully digested this. As phones become more important as biometric identifiers, the downside of theft gets greater.

I agree that a greater reliance on phones creates a greater importance to keep them secure. But I think a lot of this is low-hanging fruit.

For example, with (correctly designed) hardware tokens, there is no possibility of capturing the password/keys, so the only thing you need to do is keep a thief out of your phone long enough to disable it as an authentication source. Your PIN doesn't have to be perfect, you just need it to not be guessable within a few attempts, and for your phone to have a lockout method.

If there is no second factor (e.g. PIN), then I would venture to say it's just badly designed security and I probably wouldn't use it if I had a choice. But that doesn't really relate to this article, it's just people who are swinging too far on the "convenience" side of the convenience/security scale.

Frankly, I think you're right that a Yubikey or something is a more secure method. Anything general-purpose like a phone is inherently less secure. However, the bar we are setting here, and should be considering, is: "is this better than a password?"

I think the answer is an emphatic "yes" for the vast majority of the population.

That suggests that people have the option of using the PIN, password, or pattern that unlocks their phone to authenticate themselves to their Web account. It’s hard to see how this is any more convenient than entering a password into a browser. It’s also arguable this arrangement might degrade security since many phone users are reluctant to use long, complex passphrases to unlock their devices since it’s such a hassle to enter them so often. If a phone were ever to be lost or stolen, it might lead to a Web account being compromised.

There are a bunch of reasons why this is better.

First, a sufficiently complex password is almost certainly harder to type than whatever you use to unlock your phone, so you're definitely gaining convenience.

Second, a phone is much less likely to be electronically compromised than a desktop, due to the heavily sandboxed nature of the phone operating systems. So you're trading off password complexity for a reduced chance of compromise (e.g. key logging), which seems like a reasonable tradeoff to make.

Third, this reduces your attack surface to someone physically stealing your phone. Due to the authentication standard, attacks on your Google account are going to be attacks against certificates/key pairs, so brute force will not be effective. The single biggest attack surface for most users is a remote, digital attack on their account. Which this removes.

Finally, if your phone is stolen, you know it. Which means there can be no surprise account compromises, no wondering if you were hacked and don't know it. Phone theft is definitely a problem, but at least you have the opportunity to act on it immediately.

It's not that there are no downsides, but most people are making worse tradeoffs right now in the name of convenience, like password reuse, or simple passwords. At least a phone provides a hardware token that must be stolen in order to break into an account.

Your conclusion doesn't quite stack though. All you've really done is put forward a good, valid argument for why this would work well as a second factor.

Which, really, is what it should be.

For the user, the risk isn't just phone theft, it's dropping it down the toilet, losing or otherwise breaking it. Any one of those leads to serious inconvenience.

Having a phone capable of being a FIDO2 device is great, and avoids the hassle of a dedicated dongle, but as a second factor, you could also have an additional dongle registered and stored somewhere without having the same concerns about one going walkies without you noticing

That's not two factor authentication, though, that's just having two different FIDO2 devices for the same account, which I assume would work fine if it works the same as 2FA for google accounts does.

If it was two factor, you'd need both your phone and the dongle and you'd be just as locked out of your account if just your phone went missing.

Google says it marks the first time an interaction on the Web, as opposed to one inside a native mobile app, has allowed the use of a biometric to authenticate an action.

On the entire Web? I don't think so. I've been using fingerprint/lock screen to logon to Yahoo Japan websites (on Chrome on OnePlus 6t) for months now.

Spoiler: show

(Disclaimer: I used to work for Yahoo Japan until recently.)

I guess it's a bit different, but I use the Microsoft Authenticator to log into my Microsoft Azure portal (no password) and my Authenticator app is locked behind my biometrics. Now, I believe if I leave the app running on my phone, it won't pop the biometric login.

One thing I havent seen mentioned yet. By requiring possession of the device to get access, a lot of social engineering becomes a lot harder. And users cant easily lend their access to someone else which prevents a lot of other problems.

That suggests that people have the option of using the PIN, password, or pattern that unlocks their phone to authenticate themselves to their Web account. It’s hard to see how this is any more convenient than entering a password into a browser. It’s also arguable this arrangement might degrade security since many phone users are reluctant to use long, complex passphrases to unlock their devices since it’s such a hassle to enter them so often. If a phone were ever to be lost or stolen, it might lead to a Web account being compromised.

There are a bunch of reasons why this is better.

First, a sufficiently complex password is almost certainly harder to type than whatever you use to unlock your phone, so you're definitely gaining convenience.

Second, a phone is much less likely to be electronically compromised than a desktop, due to the heavily sandboxed nature of the phone operating systems. So you're trading off password complexity for a reduced chance of compromise (e.g. key logging), which seems like a reasonable tradeoff to make.

Third, this reduces your attack surface to someone physically stealing your phone. Due to the authentication standard, attacks on your Google account are going to be attacks against certificates/key pairs, so brute force will not be effective. The single biggest attack surface for most users is a remote, digital attack on their account. Which this removes.

Finally, if your phone is stolen, you know it. Which means there can be no surprise account compromises, no wondering if you were hacked and don't know it. Phone theft is definitely a problem, but at least you have the opportunity to act on it immediately.

It's not that there are no downsides, but most people are making worse tradeoffs right now in the name of convenience, like password reuse, or simple passwords. At least a phone provides a hardware token that must be stolen in order to break into an account.

Your conclusion doesn't quite stack though. All you've really done is put forward a good, valid argument for why this would work well as a second factor.

Which, really, is what it should be.

For the user, the risk isn't just phone theft, it's dropping it down the toilet, losing or otherwise breaking it. Any one of those leads to serious inconvenience.

Having a phone capable of being a FIDO2 device is great, and avoids the hassle of a dedicated dongle, but as a second factor, you could also have an additional dongle registered and stored somewhere without having the same concerns about one going walkies without you noticing

That's not two factor authentication, though, that's just having two different FIDO2 devices for the same account, which I assume would work fine if it works the same as 2FA for google accounts does.

If it was two factor, you'd need both your phone and the dongle and you'd be just as locked out of your account if just your phone went missing.

That's one factor, twice. In the same vein as "Password + mother's maiden name". Significantly different than two factor.

This sort of phone-as-authenticator falls in the same line of thinking as Windows Hello. It still qualifies as two-factor. Namely, the phone is the thing that you have. The authentication token is stored on the secure enclave of the device and can't be exported. So it's just a really expensive Yubikey/RSA Token. That phone / this app is then secured by either a PIN (something you know) or a fingerprint unlock (something you are). You're not getting authenticated without both.

Now, there are some real world targeted attacks that might be a bit easier with this paradigm than other two factor methods. Someone could obviously steal your phone while it / this app are unlocked. Someone could also just make sure they watch you PIN unlock your phone before they steal it. But at the end of the day, the vast majority of physical thefts aren't after your authentication, and the vast majority of authentication attacks don't have access to your hardware. And this gets rid of re-using the same password on multiple site, killing off credential stuffing. Oh, and because the Fido2/WebAuthN standard includes domain verification, it also stops phishing. So this will be a huge boost to security to just about everyone who doesn't already utilize FIDO2 based MFA.

. It’s also arguable this arrangement might degrade security since many phone users are reluctant to use long, complex passphrases to unlock their devices since it’s such a hassle to enter them so often. If a phone were ever to be lost or stolen, it might lead to a Web account being compromised.

Can confirm. Even I, someone who should damn well know better, use a pretty crappy password on my phone. In fact, despite my early protestations that I'd never do so, I also use the fingerprint reader (Android asks me for the password anyway in certain circumstances, such as a phone reboot). Why? Because it's a hassle otherwise.

I have no excuse. My phone even has a physical keyboard, so while a truly complex password is still hard, a longer one really isn't. But I gave in to the desire to unlock faster anyway.

There's a reason I don't do anything truly sensitive on my phone. Google Wallet/Android Pay/whatever the hell they're calling it this week? Uh uh. Photos I wouldn't want shared? Nope. Bank app? No freakin way. The most sensitive thing on there is Authy, which at least has its own separate PIN. And DUO, which I can't get around because work requires it.

Can confirm. Even I, someone who should damn well know better, use a pretty crappy password on my phone. In fact, despite my early protestations that I'd never do so, I also use the fingerprint reader (Android asks me for the password anyway in certain circumstances, such as a phone reboot). Why? Because it's a hassle otherwise.

Here's the question, though: does it really matter?

Complex passwords on web services are important. If a password database is compromised, or if account lockout policies aren't effectively enforced, you want that long password to prevent a brute force attack.

On your phone, PIN lockout will occur long before an effective number of attempts is tried, and once the lockout occurs, no further attempts will be successful (without your Google account password).

I don't think you should use a 4-digit PIN. But the security profile of your phone is different from your online accounts, and what would be wildly insecure on your online bank account (a 6-character, digits-only password) presents itself differently on your phone.

"The standards are designed to wean the world off its reliance on passwords by making it easier to use other authentication factors such as physical security keys, fingerprints, or other biometrics."

You guys correct me if I'm wrong, but it does not seem as we're weaning off our reliance on passwords - we're just adding layers of abstraction on top of it to make the login process more convenient.

I hate having to type login password boxes everywhere I go as much as the next guy, but basically, there are some characteristics of it that are pretty much unbeatable. I do use a password manager btw.

Passwords are platform and hardware agnostic. They are easy to reset, a process that is necessary in any form of authentication. They can be very secure when used correctly. And you can generate multiple backups of them with some pen and paper.

For important ones, you store them in your head. And that's it - no need for extra hardware that could get stolen or lost, extra layers of software that could have their own vulnerabilities, no reliance on body parts imprints, etc.

Now, of course, I do understand trying to change methods of authentication both for convenience, and also to force people to use strong passwords indirectly instead of reliance on them doing it by themselves. But that's what it mostly ammounts to.

Biometrics is a way to come up with a fixed strong password based on imprint characteristics. Physical security keys is the same. They are certainly more convenient for the login process, but you are always trading something there.On biometrics, since the generated key is fixed, if you get the data points the key was based off and how the system generates it for authentication, then the entire thing is compromised. Knowing enough on how readers work and having a sophisticated enough process to copy and reproduce is also a problem.Hard, but could still happen. Up to here passwords are on a similar situation.

But passwords are easy to replace, for biometrics you'd have to replace a significant part of the system - because you cannot replace your fingerprint, iris, face, vein configuration or whatever.

Physical security keys are easier to replace... easier than biometrics, harder than passwords. You could also have a backup of them in safe storage. But they can be stolen or lost. There is extra reliance on the listed methods "FIDO2, W3C WebAuthn, and FIDO CTAP standards jointly developed over the past few years by a long list of companies", which means you are still relying on companies to keep those secure.Of course, we also do rely on standards to keep passwords secure during authentication, but again, it comes down to how hard it is to replace a password in comparison to a physical security key.

In the case of Google using a similar method to turn your smartphone into a security key of sorts, pros and cons comes to mind. First of all, I don't use Google's password manager nor intend to. I'm currently using Lastpass but my ultimate goal is to use something like Keepass and store backups locally, offline. I just don't wanna rely on tech corporations like Google with stuff like that. I'm also on Firefox instead of Chrome. And at some point I'm probably also moving away from other Google based services and products.I already use DuckDuckGo more than Google Search, have some alternative e-mail accounts and managers though I still mainly use Gmail, and I probably would've tried migrating to an alternative OS other than Android or iOS if it was up to par.

Second thing that comes to mind is not having a ready to use backup method. Not sure what a reset and recovery process would look like in this case, with a smartphone getting stolen or broken. But it'd probably be kinda ugly. I do have a backup phone, but it probably wouldn't fit the standards required for this method of authentication.

You guys correct me if I'm wrong, but it does not seem as we're weaning off our reliance on passwords - we're just adding layers of abstraction on top of it to make the login process more convenient.

Not exactly. Certificate-based authentication (or any form of public/private key authentication) is fundamentally different from password authentication. There are a lot of ways the FIDO2 standard improves on traditional passwords. For one, the private key never leaves the device, so there is nothing to steal on the server side, and due to the nature of key pairs, you can actually embed the private key in devices so that it is not possible to steal it. Which is substantially better than passwords, where you actually have to present the secret itself to prove you know it.

Quote:

Passwords are platform and hardware agnostic. They are easy to reset, a process that is necessary in any form of authentication. They can be very secure when used correctly. And you can generate multiple backups of them with some pen and paper.

For important ones, you store them in your head. And that's it - no need for extra hardware that could get stolen or lost, extra layers of software that could have their own vulnerabilities, no reliance on body parts imprints, etc.

Agreed, sort-of. Passwords are definitely easier to implement, and easier to back up.

However, a fundamental transition to this new process actually removes the need for the differentiation between "important ones" and "unimportant ones" and storing them in your head. A private key gets embedded in a device and cannot be extracted. There's no difference between important or unimportant ones, and keeping it in your head is not relevant because it physically can't be read from the secure chip.

Quote:

There is extra reliance on the listed methods "FIDO2, W3C WebAuthn, and FIDO CTAP standards jointly developed over the past few years by a long list of companies", which means you are still relying on companies to keep those secure.

I'm not sure what you're asking or saying here. You are not really relying on those companies to keep your private key secure. Your private key is stored on a hardware device (you ARE trusting that particular hardware provider to keep your key secure, but you don't have vendor lock-in or anything), and doesn't leave.

In regards to the implementation here, the standard doesn't need to be tied to any particular service or vendor. Google has picked their password manager as a place to start, but these standards are just relying on standard encryption methods that could be implemented elsewhere and by other vendors.

That suggests that people have the option of using the PIN, password, or pattern that unlocks their phone to authenticate themselves to their Web account. It’s hard to see how this is any more convenient than entering a password into a browser. It’s also arguable this arrangement might degrade security since many phone users are reluctant to use long, complex passphrases to unlock their devices since it’s such a hassle to enter them so often. If a phone were ever to be lost or stolen, it might lead to a Web account being compromised.

There are a bunch of reasons why this is better.

First, a sufficiently complex password is almost certainly harder to type than whatever you use to unlock your phone, so you're definitely gaining convenience.

Second, a phone is much less likely to be electronically compromised than a desktop, due to the heavily sandboxed nature of the phone operating systems. So you're trading off password complexity for a reduced chance of compromise (e.g. key logging), which seems like a reasonable tradeoff to make.

Third, this reduces your attack surface to someone physically stealing your phone. Due to the authentication standard, attacks on your Google account are going to be attacks against certificates/key pairs, so brute force will not be effective. The single biggest attack surface for most users is a remote, digital attack on their account. Which this removes.

Finally, if your phone is stolen, you know it. Which means there can be no surprise account compromises, no wondering if you were hacked and don't know it. Phone theft is definitely a problem, but at least you have the opportunity to act on it immediately.

It's not that there are no downsides, but most people are making worse tradeoffs right now in the name of convenience, like password reuse, or simple passwords. At least a phone provides a hardware token that must be stolen in order to break into an account.

I'd argue that phones are potentially easier to compromise than normal computers, because the latter get regular updates and are often behind a router, while the former only get updates for a few years, and are regularly connected to untrusted networks.

It seems to me we haven't yet fully digested this. As phones become more important as biometric identifiers, the downside of theft gets greater. I was reminded of this at the weekend because I was using my phone on TfL and read about a proposal to start using phones as identifiers on the wider rail network - but using remote readers, which means always-on phones. Even now, if someone steals your phone while in the London Underground, they can use it to exit a station and you now have a problem.

At some point the legal system is going to need to start taking the theft of phones as seriously as the theft of safe keys to a bank. But that has a second aspect to it; people will need to stop walking down the street holding phones out for any passing thief to grab. They wouldn't do that with their house keys attached to a tag with their personal details, would they?

I'm becoming less and less sure that this is the right approach, and thinking more that things like Yubikeys but with somewhat increased capability are the real answer. Ideally they should be on you but in a more secure location - and the theft of a linked phone should stop it working immediately.

That's my concern too. Keep adding features to your phone (payment, boarding card, train ticket, remote to unlock your car/home/whatnot...) and you end up with a catastrophic failure when your phone is stolen or even just lost. I tend to print my boarding cards anyway so that I have a hard copy in case my phone is lost.

Regarding your immediate concern, there's probably no short-term solution for TfL, the only thing that comes to my mind is a phone lock tied to another device that is harder to steal, like a wristwatch or a fob etc. If they are paired and the phone cannot be unlock when you are out of your usual locations (home, office etc) and when the other device is not reachable, at least you can limit the damage a little bit. Even better if the other device could alert you when your phone is out of range. It would help to realize earlier that your phone is not with you (when the taxi or the theft already left, unfortunately.... ). You need to have geofencing properly set up however, otherwise you risk to have a lot false alarms every time you go to the loo and you leave your phone in your jacket on the coat hanger at the entrance of your office.