Big Tech wants to kill the password and “Access Keys”is the hot new standard for block password replacement. Access keys are supported by Google, Apple, Microsoft, and the FIDO Alliance, so expect to see them everywhere soon. iOS picked up the standard in version 16, and now Google is rolling out password beta versions for Chrome and Android.
The password argument is that the passwords are old and weak. Computer passwords were originally conceived as an easy-to-remember secret that people could type into a text box. As the need for greater security arose, password managers emerged to make it easier to save and recover your passwords. Now, instead of some catchy phrase, the ideal way to use a password is to have the computer generate some wild string of characters and never use that password anywhere else. However, the password manager revolution is a hack built on top of that original text box. We don’t actually need the text box anymore, and that’s where the password standard comes in.
One odd choice Big Tech has made with passkeys is that the thing that passes your key to the website is your phone, not the password manager on whatever device you’re currently using. This communication between the phone and the client is also not done over the Internet like two-factor authentication – the device you use must have Bluetooth in order for your phone to communicate with it locally. Local communication ensures that random people on the internet cannot log into your accounts, but it will also block some desktops.
Google says password efforts have reached a “major milestone”today. If you sign up for the Play Services beta, you can now create and use passkeys on Android devices, and Chrome Canary now supports website passkeys. Google says stable implementations for Chrome and Android will arrive later this year, but wants developers to start development right now.
Google has also shared some details on how this will work. In Google’s solution, your passwords are stored in the Google password manager. A pop-up on your phone will first prompt you to select an account and then authenticate with some kind of biometric, such as fingerprint unlock. The phone will communicate with the client via Bluetooth, the browser will receive your password and send it to the website. (If the client is your phone, things get a lot easier.)
For some reason, in Google’s example, the whole process starts with a QR code. I’m guessing this is just a quick hack for the beta, but in order for the passkey popup to appear on your phone first, Google shows the computer a QR code and then the phone scans it. As is the case with Google Prompt or other forms of 2FA, we hope that in the future the initial password popup will open automatically over the web.
Apart from the stable releases for Android and Chrome, next for Google is an API for native Android apps and an Android API for third party password managers that can be plugged into this. Google is tidying up right now, but in the future this should work across different ecosystems, so an iPhone can send a passkey to Chrome and an Android phone can send a passkey to Safari.