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.
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...