WebAuthn does this, and chrome/FF/edge support this. They're also adding CTAP2 support allowing the use of biometric, BTLE, and NFC devices to provide authentication keys.

Soon you'll be able to use TouchID to log in to your website, provided you've associated the pubkey from your fingerprint authn with your website.

https://www.chromestatus.com/features#component%3A%20Blink%3... (TouchID on MacOS: TBD)

https://bugs.chromium.org/p/chromium/issues/detail?id=780078... (CTAP2: merged)

https://www.chromestatus.com/features/6288375388569600.

We're integrating webauthn for our medical clinics as a way to support easy, secure authentication without 2FA to reduce sharing of ipads with a session logged in.

More reading: https://duo.com/blog/developments-to-webauthn-and-the-fido2-...

So instead of password managers we'll have private key managers?

WebAuthn private keys don't exist at all outside of the physical token. So there's nothing to manage. If you rely on WebAuthn as an essential authentication step you'd have two or more tokens registered and treat those the same way you would house keys.

When you lose a house key it's pretty manageable to get a few locks changed, but it can be rather overwhelming to remember all the dozens of websites that have your auth details, and update them.

Good news. Like a house key, the FIDO keys are basically anonymous. So, as long as you didn't e.g. leave it with your wallet on a bus, or write on it with non-erasable marker "[email protected]" losing the key is not that scary.

In fact, unlike a house key, the Security Key works fine for its new owner, they can register it to sign into their Facebook, or whatever, that will work fine. Facebook will have no idea it's your key, now it's their key.

If they know you're [email protected] on Facebook then that's a problem, yes, as obviously they can sign in as you, but if it's so hard for you to remember what you signed up to, seems like it'll be pretty hard for a hypothetical finder to figure out too... "Hmm, I wonder if this random stranger was into Diaper Porn and Antique furniture?"

AKA "wallet"

Awesome!!

Client certs have existed for a long time. Most sites won't implement them without great demand from the user-base or specific security needs. This would also mean that sites would have to track all of your client certs from each device.

The upside would be that you could tie a cert to a specific hardware device and serial number, which means someone getting your certs won't be useful to them. Microsoft does something like this for xbox "machine" accounts. Each device can have it's own password that is tied to that serial number. If leaked, the password (or cert in this case) is not useful anywhere else. This is similar in concept to tieing an ssh public key to a specific network or IP address, except it is a hardware identifier in this case.

Unpopular opinion disclaimer: Anything else pretty much requires tieing into some 3rd party auth service or hardware token which have their own issues, such as vendor lock-in, managing server side libraries, leaking usage data to 3rd party providers, creating weak-chain back-doors to 3rd party vendors, privacy violations, etc.. I know those are all the rage right now among technical folk, but the general public adoption is quite low. Passwords will be around for a very long time.

This is used heavily in USG/DOD where everyone has a certificate thanks to HSPD-12

I would fully expect some government sites to require client certs. Some DNS registrars also required client certs in addition to 2FA. Some payment systems also require them in addition to IP restrictions.

HSPD-12 largely abolished passwords as authenticators throughout the executive branch.

Hopefully all of their authentication methods are hosted in-house, on-prem and not outsourced or outside of secure boundaries. Everything has a back-door these days and leaks like a waterfall. :-)

A lot of the authentication is TLS client certificate authentication, SAML hosted by internal SAML IdP systems (such as ADFS) for web stuff.

For most other things Kerberos (via PKINIT) is used.

SSH authentication X.509 using PKIXSSH is rarely used since it is not a standard part of any operating systems used. For SSH, typically either Kerberos or SSH keys based on the RSA keys used by the certificates.

You can use a yubi key, or IMO better yet, a trezor crypto wallet(as unlike yubi, you can clone and restore it more easily with your seed words). Not sure how yubi works, but trezor generates deterministic passwords based on your private keys. Plus it's open source so I guess if they go bust you should be able to retain access to your passwords and to clone/restore ability forever.

Built into browser would be more user friendly, admittedly, but in my opinion this is quite good too, and arguably more secure as your private key is not exposed to your PC.

This is what you're doing when you use U2F, right?

Also see: https://w3c-ccg.github.io/did-spec/

you mean something like this?:

https://blog.codesolvent.com/2015/07/why-not-signed-password...