More than that. Because it's an open standard it can be used with other types of authenticators, like password managers and platform-level security keys. There are also extensions allowing sites to prompt users for explicit authorization for a specific action. (e.g. "do you want to send $20 to xyz?")
In short, this could replace passwords for web authentication entirely.
So I like this concept based off what I can see (basically like a RSA or similar w/o the generated token, or rather having to enter said token manually). Question: Microsoft was pushing hard that they're going towards passwordless, and if memory serves, it was through the FIDO Alliance stuff. So how do we get there with this? I'm assuming this is supplemental to that (a "second factor"), but what else gets us there?
Web Authentication is part of FIDO2, which is what Microsoft is pushing. Whether you use it for passwordless login or second factor depends on what the server wants and what authenticator hardware the user has.
Lack of sleep makes it a bad time for me to read this. But if the client generates the key does it mean it's stored on the browser or something like that? It means that I will need a sync/copy procedure if I'm going to use it in another machine/browser?
I wonder if this API can be coaxed into providing a method of authentication for "the other" 99% of people and use cases, without a hardware token and in a device-independent fashion, using passwords only.
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.
> 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.
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.
Seems like in that scheme anyone can retrieve the encrypted secret without authentication (just by knowing the username), and then try to brute-force it at will.
So the offline, parallel crack turns into an online, serial and rate-limited bruteforce. The salt and password derived shared secret are established at account setup time and after any password change, which the browser must support too.
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.
So now the server needs to store a copy of your stretched master password? How is it supposed to know whether the value of `encrypt(streched_password, salt, server_name)` is correct?
Why not just use public key authentication, like the Web Authentication standard already does?
>How is it supposed to know whether the value of `encrypt(streched_password, salt, server_name)` is correct?
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.
So the server stores a copy of your encrypted keyfile, salt, and the result of `encrypt(streched_password, salt, server_name)`?
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.
It's an interesting project, although the blockchain incarnation seems to go in a different direction, more akin to social login.
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.
Thanks, the blockchain part is recent and isn't relevant. Otherwise it's super simple idea: strong derivation based on something anyone can remember (username + pw) + website origin = strong non-reusable credentials w/o hardware.
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.
Finally! I have a design concept that I wanted to propose but never got around it which would be very similar or even the complement, but without all the security details that I do not know how to do and that this API is strong on: https://jsfiddle.net/franciscop/qj4g3rz8/
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.
This is going to be _huge_ for the security of the average web user once it starts getting widespread adoption.
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.
Stealing Web Authentication keys from a hardware token is a significantly higher bar than phishing you or brute-forcing your password hash from a database leak. At the very _least_ the attacker would first have to compromise your machine with malware, at which point they could easily get access to all your password-protected accounts anyway with a simple keylogger.
Ideally (and hopefully this will be doable, as I don't see any impediments), you can have Bitcoin-wallet-style seed generation that you can back up onto a piece of paper and store it somewhere safe.
I really hope my Ledger Nano S becomes WebAuthN-compatible, as it can already be used as a U2F key.
Yes, for a device as complicated as the (~ $100) Ledger Nano S I don't see any reason they couldn't support that functionality.
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 could introduce latency and centralization to the authentication process, but perhaps there could be a public key server/service that would allow the user to issue a revocation certificate.
This scenario could also be a legitimate use case for blockchain technology.
If there isn't a solution in place for revocation, then it's not really an authentication solution, IMO. I would have thought this would be part of the proposed API. Do you think it belongs there?
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.
The authenticators are physical property of the people they authenticate. If you're especially worried you can remove it when not using it, you can lock it in a safe, you can give it to your personal bodyguard to protect with their life.
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.
In practice, no, the tokens are _way_ too dumb to remember anything like that. They're using an old cryptographic trick to appear much cleverer than they really are.
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.
It would be nice to have a JavaScript API that allows you to create a client certificate locally, generate a CSR, and install the signed certificate for automatic use when connecting back to the associated host?
Not exactly. It is an alternative to the concept of passwords in general. But it is not a complete solution to all the things covered by those services.
It works with Firefox 60, Google however sometimes relies on Chrome quirks not specified in the standard which may not make it usable in Firefox. (Last I checked)
It does not, and Google does not yet even attempt to use WebAuthn. They're still using the (now legacy) U2F authentication mechanism, which firefox does not fully support. It works in some sites if you enable it in about:config, but not all. Like google.com.
Hmm, yeah, I was more aiming at "Firefox has working WebAuthn in the newest Version, Google just doesn't use it properly or at all", I should have expressed that better.
Looks great for web content, but how does it support the workflow of signing up for a website on my browser and then downloading their mobile app, and signing in on the app without a password?
If your authenticator is suitable for your mobile device, then it works with that device. If your authenticator is, say, a USB-A dongle for plugging into a PC it probably either can't be used, or is super-clumsy because it needs a big adaptor to hang off the device. They make things that do Bluetooth and USB-C though.
Not with this API. You can purchase objects which can do this AND handle say your GPG keys for encryption, but WebAuthn is deliberately narrowly scoped.
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.
It doesn't seem like it, but it does require the content to be encrypted with TLS, which implies another pair of public-private key parts and certificates.
I'd be curious to know why it chooses to have a register step, why not just use the key of the authenticator/the relying ID as a proof of identity?
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
No, you were right at the beginning. There is no "root" or "real" pubkey. A separate keypair is generated each site, so that - like you said - identities are unlinkable. This is also a crucial part of what makes these credentials immune to phishing.
So the private key will be stored a device for signing in across a few platforms. But what if I need to sign in from another device? I can't do that until I go back home and copy the key over to my mobile?
Sigh, I got all excited, but then discovered this is to be used with a server, which means it fundamentally propagates the idea of "fake security" (where somebody else owns your identity, not you. Check out this explainer for more info: https://gun.js.org/explainers/data/security.html ).
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... .
Unfortunately average people are better off with a corporation holding onto their private keys. People already get annoyed when they forget their password. Telling them they have permanently lost access to their account/data because their hard disk broke or they lost their token is much worse.
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.
