Web Authentication API
developer.mozilla.org
developer.mozilla.org
In short, this could replace passwords for web authentication entirely.
Oh, I guess client certs are owned and controlled by the server owner...
And with a better UI and flow since you don't need it to establish connection.
However the WebAuthn API also leaves options for password managers and other endpoints managing the actual secrets.
And does it allow extensions, e.g. secure login through a smartwatch + NFC, and similar ideas?
There is also pam-u2f: https://developers.yubico.com/pam-u2f/
and https://github.com/bluecmd/openssh-u2f (not in upstream)
That may sound contradictory or that it misses the point, but let me explain. The password can be used to locally decrypt a secret key that is stored on the server at registration time, and that is retrieved based on the username provided. What this achieves is a login system that covers the way social login/Facebook/OAuth is used, without giving any power to a 3rd party. The password never leaves his machine and the user is not dependent on any particular hardware or keyring.
So for all those "I can't trust this website with a secure password / I can't be bothered to signup" cases, you will have a strong authentication scheme that is as secure as your (salted and stretched) master password, and where you are guaranteed that a compromise on one of the sites does not spill over to the rest. Unless you choose to reuse a username, your identities will be independent and unlinkable, unlike any social login scheme, preserving privacy. The user complexity is similar to what regular people already know, usernames and passwords - you can even safely reuse a strong password. The essential difference is that you should trust only your device / browser with the password, not the site.
retrieve_salt(username)
retrieve_keyfile(username, encrypt(streched_password, salt, server_name))
This still has some imperfections related to replay susceptibility, but my point isn't to design a protocol, rather the principle of a thing that could make social login obsolete and stone-age.
Why not just use public key authentication, like the Web Authentication standard already does?
By comparing it to the static value stored at account setup time. The server trusts your shared secret just like it trusts your public key - establishing the identity of a public key is a different problem with various solutions, CAs, WoT, directory servers etc. The idea here is to move from plain authentication (user/password) to a public key system without carrying the key material around, but deriving it when needed from your password.
That's better, but still allows malicious sites (or anyone who compromises the database of a site you have an account on) to brute force your master password offline. Slightly better than reusing passwords since there's no danger of sites using a weak hash algorithm or storing your password in plaintext, but still not great.
IMO if you _really_ don't want to carry the key material around (which _does_ necessarily reduce security btw, as you're going from "something you have" + "something you know" to just "something you know", which is easier to steal and inherently susceptible to brute force), then it'd be much simpler to just derive a private key from `(user password, site id)` and use that with WebAuthn.
While I congratulate you for your efforts, I can't really see the point of implementing this outside of the browser as anything more than a proof of concept. The whole idea is to replace the trust in a web service with the trust into the user agent, I would approach this as specification/standardization work, not something you whip up an electron app for.
The Failsafe work is fascinating, I just discovered it thanks to your link and I'm digging in.
It's definitely would be more successful being part of the browser, but Web Auth API is too slow to move so I went out to make a PoC instead. In the end: I hate electron apps now :) Also I now know what kind of effort is needed to change the auth space... I don't believe it will happen short term :/ It's too hard and too little incentive to change things.
The only perk of being outside the browser is being able to auth regular desktop apps like Spotify or Btc wallets. But yes, 99% are web apps so seamless in-browser login would make more sense.
I'm not sure I understand the advantage here. You're still dependent on a password.
> you will have a strong authentication scheme that is as secure as your (salted and stretched) master password
So, as secure as we have now.
> where you are guaranteed that a compromise on one of the sites does not spill over to the rest
Why not? If I use the same password for all sites, the attacker can just use that password to authenticate to all other sites (by decrypting all the other secret keys with it).
> Unless you choose to reuse a username, your identities will be independent and unlinkable
They're independent and unlinkable with passwords now, too. The only improvement is that your password doesn't go over the wire, which, admittedly, is a moderate improvement.
The browser could store several data points for each field so you can choose from a dropdown OR different user profiles so you can switch from "Francisco the freelancer" to "Francisco the open source guy" in the drop of a beat. Or per window to do both at the same time if that's your thing.
But anyway, this new Web Authentication API is really, really awesome to remove passwords forever. Now we need the last one, which would be closer to my design concept to even remove the manually adding all those fields: Web Identity API.
Credential phishing, password reuse, credential stuffing, and weak passwords are all about to be a thing of the past, at least insofar as the web is concerned.
Compared to the situation today when if one your passwords is cracked they can't immeidately access your other accounts.
Most passwords are vulnerable because they are easily guessed, not because somebody breaks your encrypted password store.
I really hope my Ledger Nano S becomes WebAuthN-compatible, as it can already be used as a U2F key.
Most people will be using much cheaper, dumb authenticators which aren't going to have the capability to read and update the keys, they would be expected to replace their authenticator altogether, not try to clone it if there's a problem.
This scenario could also be a legitimate use case for blockchain technology.
If say my Gmail is configured to trust my awesome Darth Vader bobble head authenticator, the tiny one I keep on my keychain and one that's in my locked desk drawer with my cyanide pills and then I lose my keys somehow, I go home, use the Darth Vader to sign in, click for the account credentials page, pick the keychain one and pick remove. I can add another one when I buy it, using the ordinary enrollment step.
No new API needed or desired.
The trick to U2F and this whole family of technologies is that the devices are really dumb, your authenticator doesn't remember "I'm allowed to authenticate to Google, I picked this key" it just turns google.com into a number and uses that with some crypto arithmetic. If you never actually enrolled with Google, the results are worthless but it has no idea. If I try to sign into Mike's account with Sarah's authenticator, it doesn't work but there's no clue why. The authenticator doesn't even know it's Sarah's.
Air gapped authenticators are plausible, although they'd be awful from a usability perspective, if you're really that paranoid...
Whereas all your passwords are just bits, and you have to transmit those bits to a remote party every time you authenticate. You can't keep those bits safe, only trust that everybody else is looking out for you and they're all competent. Good luck with that.
During enrollment they present the server with a public key, and a magic cookie, both of which it stores. In subsequent authentication, the server sends them back the cookie, and some random data, which the token then signs to prove it still knows the private key, the server can check that because of the public key it has.
But in practice the key pair never actually lives inside the token - it makes the key pair during enrollment, and the "magic cookie" was actually its private key encrypted using a secret key only the token knows. So the token has no writeable storage, just ROM and a little bit of DRAM. Some tokens might have a tiny amount of flash to e.g. store a counter or a user chosen PIN to do PIN authentication instead of a one touch auth, but they aren't storing a bunch of keys, or domain names, or email addresses.
This feels so much like cheating that I was sure it must be flawed, but I couldn't come up with any weakness.
I conviced myself that this is possible by considering the method of using a different permutation of the same key pair on each website and storing that permutation, encrypted, in a cookie.
Cryptography is awesome.
https://www.w3.org/TR/webauthn/
?
EDIT: found this relevant comment (I think) from yesterday's discussion: https://news.ycombinator.com/item?id=17030302
> The Web Authentication API (also referred to as WebAuthn)
Sadly i've got no idea how far away we are from this actually being implemented.
Or is that TBD?
Using the same key for unrelated things can result in unpleasant surprises. So it's to be avoided.
If you have a crappy insecure email server that uses SSLv3 still, and uses the same key as your tightly locked down Web server with TLS 1.2 then this bites you really badly, I can use the email server to help me impersonate your web server.
You would normally use a scheme like this so that websites cannot connect multiple identities together, but it seems pointless here because the pubkey will be signed with the user identity and the server will have logged your real pubkey
http://blog.codesolvent.com/2015/07/why-not-signed-password-...
There are competing U2F keys, but I don't know of any competitors that support FIDO2 yet.
This is bad design philosophy, I instead encourage everybody to use the native Web Crypto API to create accounts and do P2P E2EE encryption.
Web Auth API does look a lot easier than Web Crypto API, but it pushes the wrong message. We've taken a lot of time to make an MIT/Zlib/Apache2 Open Source wrapper around Web Crypto API that allows better user security (better than Web Auth API), short tutorial here: https://hackernoon.com/so-you-want-to-build-a-p2p-twitter-wi... .
Care to elaborate on how you mean WebAuthn prescribes that? The GUN explainer videos also seem to assume there's a server involved, so I don't understand what you mean is bad about that.