Android Is Helping Kill Passwords on a Billion Devices (wired.com)

The FIDO Alliance -- a consortium that develops open source authentication standards -- has been pushing to expand its secure login protocols to make seamless logins a reality for several years. Today, it has hit the jackpot: Google. From a report: On Monday, Google and the FIDO Alliance announced that Android has added certified support for the FIDO2 standard, meaning that the vast majority of devices running Android 7 or later will now be able to handle password-less logins in mobile browsers like Chrome. Android already offered secure FIDO login options for mobile apps, where you authenticate using a phone's fingerprint scanner or with a hardware dongle like a YubiKey. But FIDO2 support will make it possible to use these easy authentication steps for web services in a mobile browser instead of laboriously typing in your password every time you want to log in. Web developers can now design their sites to interact with Android's FIDO2 management infrastructure.

Comments

No way to re-secure your body

[Anonymous Coward]

Biometrics can be stolen or faked. But there's no way for the legitimate owner of that body to replace them when that happens.

(posting this on the day my office is forcing a periodic password change on me)

Web developers

[DontBeAMoran]

Web developers can now design their sites to interact with Android's FIDO2 management infrastructure.

How about you design your FIDO2 thing to automatically type passwords into regular password fields instead of asking the whole web to change for your new special feature?

Re:Web developers

[The-Ixian]

Why would you not choose a new method if it is more secure and you can also have it in place at the same time as normal passwords?

Nobody is suggesting that this be a mutually exclusive choice for web developers.

By your argument, we would never be able to change anything once it was deployed...

Re:Web developers

[AmiMoJo]

That's not how FIDO works. It uses public key crypto, so you secret never leaves the phone. In contrast with a password the secret (i.e. the password) has to be both transmitted to the server and stored in some fashion (hopefully one-way hashed with salt).

Of course Chrome also supports auto-fill for passwords, which you can use if for some reason you don't understand what FIDO is.

Re:Web developers

[Zmobie]

It kind of is nothing actually. At least to the service, some of this depends on how sketchy Google or whomever implements the client side portion wants it to be I suppose. The user still only has to input their secret one time and the service and client systems handle the rest. The main difference is the user now handles their own secret information and doesn't have to trust the service with it. I read up on the standard and this is how it works:

User creates a local registration public/private key pair with whatever secret they want to use to restrict access on the client side. Then transmit ONLY the public key to the service which then associates this public key with a unique user ID on their system which is then sent to the client for storage and retrieval.

When the user wishes to login to the service they go to the publicly known location of said service which at 'login' sends their client a challenge first. The challenge consists of the user's unique ID and some type of one-time use question or internal payload that the client has to be able to read in order to answer. The challenge is encrypted by the service using the stored public key and then transmitted to the client to start the process.

Once the client receives the challenge, it uses the known service association to locate the expected key/value pair association and decrypt that information with the private key that only the local device has access to with the user's permission/interaction (scan your fingerprint, hit your smart card button, etc.). The client system can then validate the internal payload contains the expected unique ID (validating the service is who they say they are) and answer/sign the challenge since it can now be read. Using the internal ID or some other mechanism (some type of session key for a modified diffie-helman I think) the client then encrypts the challenge response and returns it to the service for verification.

At that point the service validates the payload matches what the client response to what it should be and authentication is complete.

There are two attack vectors I see and neither are easy to do at scale. One, compromise the registration such that when the service sets up the user with their Unique ID that was created on the service side the user associates it to the attacker's unique ID instead. An attacker could then impersonate the service and attempt to harvest information that way. It wouldn't enable a full MITM attack still simply because without access to the private key there is no way for the attacker to impersonate the client and authenticate properly with the service.

The second, obviously, is breaching the local device. As I have pointed out in a couple other posts though, attackers have to breach every device individually now though creating scaling issues. Not only that, if the authentication methods used are separated per service, it only gets the attacker access to the private key of that single service assuming they don't have persistent access and can wait for the user to use all secrets over time (essentially individual encryption on the keys themselves makes this even more difficult with minimal user interaction required still, but unlikely many users would do this without having very high security needs). Separating devices that store the private keys would also create at least segmented security as well such that the user would not lose everything if one device is persistently breached.

Generally I like the standard. I may not have everything correct, and I think some of my understanding may actually be assumed internals. If anyone has any corrections or sees issues, feel free to chime in. The service would still be able to uniquely fingerprint an individual for tracking purposes, but I don't see a way around that for single user authentication anyway. Kind of difficult to let a user be anonymous when they have a unique account on the service anyway...

What's wrong with keepass?

[Excelcia]

They want me to trust an Android phone to authenticate all my logins? Are they high?

Switch to KeePass and family. Create a database with a keyfile and a master password. Distribute the database using I switched to KeePass and family a couple years ago, and it was the best thing I ever did. Use a master-password plus a sneaker-net distributed keyfile to protect the database. You can share the database with something like SyncThing, that has end-to-end encryption you control just for added safety but really you could share the database publicly with complete safety at that point.

Don't get me wrong, I like Android. But Google has been in the NSA's back pocket from the beginning. Not that Assange is one of my favourite people, but he did make a compelling case for Google being essentially an arm of the US government. Which is one reason why China had it out with them (we may get on Huawei's case for back-doors, but we did it to them first with Google and Windows).

Re:What's wrong with keepass?

[b0s0z0ku]

The problem is that the US is extremely authoritarian while marketing itself as free. The watchdogs are powerless over the wails of cops and cowards that "if you have nothing to hiiiiiiiide, why do you need priiiiiiivacy?"

Android is helping to spread pervasive tracking

[sinij]

Corrected headline - Android is helping to spread pervasive tracking.

User name and password is "something you know", and as such is not something that can be used without your explicit consent. Seamless login is "something you have", and since it is part of your phone, it doesn't require your explicit consent to be checked.

Make no mistake, this is about removing what little anonymity is left from the Internet. FIDO standard is effectively a Real Name Only policy disguised as progress.

Re:Android is helping to spread pervasive tracking

[b0s0z0ku]

Yep, nailed it -- this is about techscum like Google wanting to hold the keys to the safe.

Re:Android is helping to spread pervasive tracking

[surd1618]

When I can't use an Android device without signing in to Google, I will not buy another Android device.

Re:Android is helping to spread pervasive tracking

[Oswald McWeany]

Corrected headline - Android is helping to spread pervasive tracking.

User name and password is "something you know", and as such is not something that can be used without your explicit consent. Seamless login is "something you have", and since it is part of your phone, it doesn't require your explicit consent to be checked.

Yes, and I use a dozen different e-mail accounts to make it slightly harder for different companies on the web to know that I am the same person if they try and share data. I don't want the same account ID on every site I go to.

I want Amazon and Slashdot, for example, to not know I'm the same person if they share databases. Or my bank and Google, etc. I know there are other ways of tracking and I'm probably not fooling the big guys much- but I want to log in different places as "different people".

Re:Android is helping to spread pervasive tracking

[swillden]

Corrected headline - Android is helping to spread pervasive tracking.

You don't know what you're talking about. The FIDO2 approach to online auth uses a different key to authenticate to every we site and is designed to make it impossible to connect a login to one site with a login to another site (unless user-provided data provides a connection between them).

I like my passwords...

[b0s0z0ku]

I don't want to be dependent on a given device or ecosystem for using a website or an app, and I don't necessarily want to tie it to my identity via biometrics. I can make passwords arbitrarily complex, yet easy to remember, and even write them down in a little book (kind of hard to hack remotely).

Password-less authentication isn't about security -- it's about control and LACK of security. Google wants to hold the keys to the city.

Re:I like my passwords...

[WaffleMonster]

Google does have the private key to the root CA key used to validate FIDO2 authentications, but the keys used to do the authentications are created on-device, and signed on-device by keys which are not device-unique and therefore provide no device identity linkable across web sites.

What you're saying is like claiming that Let's Encrypt has the "keys to the web" because they are the root CA for much of the web's TLS certificates.

This is a scary argument.

Let's Encrypt along with every other CA on the planet very much holds the keys to the web. They can generate keys enabling them to subvert virtually any secure site on the planet at their pleasure.

You are right in that this is not because they are the root CA "for much of the" web.

It's much more basic than that. It's simply because they are a CA and therefore inherently in a position to globally issue certs trusted unconditionally by all clients using the web regardless of how many customers an individual CA has.

If Google is able to do something similar WRT to authentication then it's to borrow a phrase from Joe Biden ... a big fucking deal. I would hope that Google DOES NOT have the ABILITY to bypass FIDO authenticated identity seen by applications relying on this system for authentication. If it is possible for Google to issue itself a key pair to impersonate one of my users then in fact the system is inherently broken, unfit for purpose and should not be used by anyone.

Re:I like my passwords...

[swillden]

Google does have the private key to the root CA key used to validate FIDO2 authentications, but the keys used to do the authentications are created on-device, and signed on-device by keys which are not device-unique and therefore provide no device identity linkable across web sites.

What you're saying is like claiming that Let's Encrypt has the "keys to the web" because they are the root CA for much of the web's TLS certificates.

This is a scary argument.

Let's Encrypt along with every other CA on the planet very much holds the keys to the web. They can generate keys enabling them to subvert virtually any secure site on the planet at their pleasure.

Actually, you make a good point. Google in this case has far less power than a traditional CA, because each time you set up a WebAuthN authentication with a web site, you generate a new, unique asymmetric key pair and the site you're authenticating to stores the public key. The Google root is used only at that time, by the web site to verify that the key you've provided is stored in some sort of secure hardware -- and only if they care to verify that (in most cases, I can't think they'll even bother.).

Once the key pair has been generated and the public key stored, Google no longer has any role at all in WebAuthN. They can't use their root key to get the web site to accept a different public key as identifying you.

BTW, to be clear, I should say "we", not "they". I'm the lead engineer for and designer of the Android Keystore attestation that is the root of trust for Android WebAuthN. If you have any questions about how keys are generated, managed, revoked, etc., just ask.

Biometrics A Slippery Slope

[BrendaEM]

First it was fingerprints, then it was the face. While the question where it will end exists, does anyone notice that they are just scanner our bodies part by part, and selling the information?

Re:Biometrics A Slippery Slope

[sinij]

Error. Post aborted. Failed to confirm user identity. Please firmly re-insert authentication device into your sphincter and try posting again.

No mention of SQRL Login

[MCRocker]

I'm a little shocked to see an article on FIDO without even a mention of Steve Gibson's competing Secure Quick Reliable Login.

Although I'm not an expert on this, most reports I've heard is that SQRL, is what FIDO was trying to be.

One key feature of SQRL is that it only does one of Authentication and Authorization, so it can be used for anonymous login, which would be better for many purposes, such as blog comments where you only need to verify that some response belonged to the same author as some other so nobody could impersonate someone else. Though it looks like FIDO may also do this.

Client certs are a UX nightmare

[tepples]

One big difference between client certificates and U2F keys like this is that compared to a web browser's client certificate store, a U2F key is somewhat more hardened against attempts to copy out the private key. This lets a U2F key pass more tests for being "something you have."

The other is that TLS client authentication have been a usability nightmare, particularly for non-technical users, in "all major browsers since the beginning of time itself."

• No obvious button to "sign out" (use no client certificate) in order to retrieve a logged-out view of a resource or to switch between certificates associated with different user accounts.
• Backing up certificates and moving them among devices isn't easy.
• Certificates aren't associated to a domain. If the user uses the same certificate on all sites, this isn't quite as bad as sharing a password, but it does have the same cross-site tracking implications as third-party cookies. If the user uses a different certificate on each site, major browsers traditionally haven't helped the user figure out which certificate goes with each site

Browser publishers haven't prioritized improving client certificate UX because of the low user base of client certificates. I've seen them on only two sites: StartCom (a defunct TLS CA) and Kount (an e-commerce fraud risk assessment platform).. But browsers could improve this UI in a few ways:

• When a TLS site requests a client certificate, show a key icon in the location bar next to the TLS lock icon. This opens the certificate chooser. The user can click it again to log out.
• Group certificates in the certificate chooser by the registrable domain* with which they were last used.
• Let the user drag certificate files in and out of the certificate chooser.
• Include client certificates in the browser's password sync feature.

But good luck getting browser publishers to devote any time==money to this.

*A "registrable domain" is a public suffix, as defined by Mozilla's Public Suffix List, plus one name part. If "co.uk" is a public suffix, for example, then "ebay.co.uk" is registrable.

Re:Client certs are a UX nightmare

[WaffleMonster]

One big difference between client certificates and U2F keys like this is that compared to a web browser's client certificate store, a U2F key is somewhat more hardened against attempts to copy out the private key.

There is no reason keys can't be stored in security modules or "smart cards" or even USB sticks for those dumb enough to require the security nightmare that is USB for user authentication.

The other is that TLS client authentication have been a usability nightmare, particularly for non-technical users, in "all major browsers since the beginning of time itself."

So instead of addressing usability problems the answer is to create an entirely new incompatible protocol? Fuck that. I use client certs every day and it's no more of a usability nightmare than HTTP authentication.

No obvious button to "sign out" (use no client certificate) in order to retrieve a logged-out view of a resource or to switch between certificates associated with different user accounts.

This is impossible to fix right? A completely new protocol is required to address this because browsers don't offer obvious sign out buttons for certificate and http auth.

Backing up certificates and moving them among devices isn't easy.

This is nonsense. All systems require a key to work. Whether on a USB stick or a smart card or embedded in a computers security module it's the same issue. Nothing prevents portability and regardless of which one you select the same keying material is being guarded.

Certificates aren't associated to a domain. If the user uses the same certificate on all sites, this isn't quite as bad as sharing a password, but it does have the same cross-site tracking implications as third-party cookies. If the user uses a different certificate on each site, major browsers traditionally haven't helped the user figure out which certificate goes with each site

They are not domain based they are signer based. The proper certificate is generally always selected automatically based on who signed it in the first place unless there is a name collision with signer in which case a list of matching client certs are displayed. In no entirely preventable event are users given an infinite list of certs to choose from only the matching list.

Users on a per domain basis existing browsers can be configured prompt whether or not to use a cert to mitigate usage as tracking mechanism.

It would also be trivial to add constraints to client certs which limit domain applicability. There is no reason to invent a new standard.

Browser publishers haven't prioritized improving client certificate UX because of the low user base of client certificates. I've seen them on only two sites: StartCom (a defunct TLS CA) and Kount (an e-commerce fraud risk assessment platform).. But browsers could improve this UI in a few ways

This is commonly used by "enterprise" systems rather than customer facing web sites.

Re:Client certs are a UX nightmare

[tepples]

There is no reason keys can't be stored in security modules or "smart cards" or even USB sticks for those dumb enough to require the security nightmare that is USB for user authentication.

If you're doing the signing on the computer, an attacker can copy the private key on its way from the module to the computer or copy it out of the browser process once it is in the computer. If you're doing the signing on the module, that is exactly what FIDO aims to do. What am I missing?

This is impossible to fix right? A completely new protocol is required to address this because browsers don't offer obvious sign out buttons for certificate and http auth.

I notice the sarcasm. It's required in a browser only because as of first quarter 2019, more customer-facing websites support FIDO than TLS client certificates.

All systems require a key to work. Whether on a USB stick or a smart card or embedded in a computers security module it's the same issue. Nothing prevents portability and regardless of which one you select the same keying material is being guarded.

The structure of FIDO ensures that the private key never leaves the device, unlike with a TLS client certificate whose key pair must be copied into the TLS stack's address space to be used. As I understand it, this safeguarding of the private key is necessary for the device to be considered a second factor, as "something you have" rather than "something you know", in case someone compromises your password manager.

They are not domain based they are signer based.

Who is the signer in common uses of TLS client certificates? In hypothetical use thereof on customer-facing websites, who would be the signer? How does the deprecation of the <keygen> element change this answer?

This is commonly used by "enterprise" systems rather than customer facing web sites.

In order to improve the usability of TLS client certificates to the point where customer-facing websites can use them, an overhaul of the user interface is needed. Feel free to contribute a pair of pull requests, one to Firefox and one to Chromium, that does this.

Device security

[ironicsky]

If only they would apply 2FA policies to device authentication. Using their BLE token , you should not be able to unlock your device without your token and a finger print or password.

As others have mentioned, finger prints can be faked, passwords can be guessed, but none of that matters when the phone is stolen if you are missing the token attached to someone's keychain.

Google accounts online can be protected by 2FA, but your Google device is the weak link, because it has access to all your photos and drive documents without authentication once your device is unlocked.