Biometric and App Logins Will Soon Be Pushed Across the Web (vice.com)

Soon, it will be much easier to log into more websites using a hardware key plugged into your laptop, a dedicated app, or even the fingerprint scanner on your phone. Motherboard: On Tuesday, a spread of organizations and businesses, including top browser vendors such as Microsoft and Google, announced a new standards milestone that will streamline the process for web developers to add extra login methods to their sites, potentially keeping consumers' accounts and data more secure. "For users, this will be a natural transition. People everywhere are already using their fingers and faces to 'unlock' their mobile phones and PCs, so this will be natural to them -- and more convenient," Brett McDowell, executive director at the FIDO Alliance, one of the organizations involved in setting up the standard, told Motherboard in an email.

"What they use today to 'unlock' will soon allow them to 'login' to all their favorite websites and a growing number of native apps that already includes Bank of America, PayPal, eBay and Aetna," he added. Passwords continue to be one of the weaker points in online security. A hacker may phish a target's password and log into their account, or take passwords from one data breach and use them to break into accounts on another site. The login standard, called Web Authentication (WebAuthn), will let potentially any website or online service use apps, security keys, or biometrics as a login method instead of a password, or use those alternative approaches as a second method of verification. The key here is making it easy and open for developers to use, and for it to work across all different brands of browsers. The functionality is already available in Mozilla's Firefox, and will be rolled out to Microsoft's Edge and Google Chrome in the new few months. Opera has committed to supporting WebAuthn as well.

Comments

Re:https://xkcd.com/927/

[TheRaven64]

There are a few problems with client certs as used with HTTPS. The first is that it's difficult to integrate the selection of a client cert with the login UI. Actually, in most browsers, it's pretty hard to have multiple client certs for a single web site at all (try it some time). Second, the JavaScript APIs for generating and installing client certs are pretty horrible. It also requires that the client cert be used as part of every TLS handshake in every HTTPS connection, which adds some latency when you're doing multiple requests to the same site.

This API is designed to make it easy to generate a keypair, provide the public key to the remote site, and lock the private key somewhere. In particular, it allows the private key to be stored in a separate process (e.g. the Keychain on macOS / iOS) and never given to the web browser, or stored in an entirely separate device (e.g. a UbiKey U2F device). The browser or other user agent then exposes a unified API to allow the server to request a keypair be generated for a particular site and to request that something be signed to verify that the client has the private key that matches the public key that the server stored the first time.

As I understand the API, it is designed so that the server never stores anything that might be reused across sites, so even if you use a single password / fingerprint / face scan / blood sample to log into everything, that never leaves your local device and each site gets a key that is uniquely associated with that {authenticator, user, site} triple, where the authenticator is one of a service provided by your OS, functionality provided by your browser, a U2F device, and so on.

Re: Authentication != identification

[bws111]

Your biometric info is only used (if at all) to unlock your local keystore in order that your private key (for that site) can be used to sign a challenge. Your biometric data is not transferred to the site in any way.