Slashdot Mirror
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.
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)
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.
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.
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."
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:
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.
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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...