How easy will it be to implement? We should keep in mind the most dangerous guys out there store passwords in clear text in databases and other amateurish rookie mistakes. Having easy to use / impossible to f__k up libraries for every major platform is going to be critical.
There are two methods, IIRC. `get` and `create`. Everything is done with Challenge/Response with the browser handling the Private Stuff. It's hard to mess up, at a glance. You ask the browser to create an asymetric key pair. It returns the public key, which the server saves. On login, you provide a challenge to the browser to sign using the private key from earlier. It returns the signed message and the server verifi…
W3C approves WebAuthn as the web standard for password-free logins
121–130 of 154 posts
Re: W3C approves WebAuthn as the web standard for password-free logins
#122I recently used auth0 to implement passwordless login (via "magic link" emails) for a client project. Auth0's documentation is not great, but some of their blog posts are pretty good. In any case, if you're interested in WebAuthN, you could do worse than reading what Auth0 has to say about it: https://auth0.com/blog/web-authentication-webauthn-overview-...
Can I just say I detest magic link emails that don't offer me a way to just use my password manager?
Re: W3C approves WebAuthn as the web standard for password-free logins
#123Earlier quoted context omitted.
Is there a solution for the fact that all of your accounts will be secured by the same "source"? Isn't this almost close to using the same password on every site? I realize a physical secret is better than a password, but if someone gets their hand on your little FIDO device, do they instantly get access to all your accounts?
The big problem with using the same password on multiple sites is that if any of the sites record your password (because of maliciousness or incompetence), they can re-use your password to log in as you on any other site. Using a security token is more like a password manager with random passwords everywhere than that (the attacker needs to get access to your password manager to get access to your accounts; it's not…
Re: W3C approves WebAuthn as the web standard for password-free logins
#124Re: W3C approves WebAuthn as the web standard for password-free logins
#125Earlier quoted context omitted.
The big problem with using the same password on multiple sites is that if any of the sites record your password (because of maliciousness or incompetence), they can re-use your password to log in as you on any other site. Using a security token is more like a password manager with random passwords everywhere than that (the attacker needs to get access to your password manager to get access to your accounts; it's not…
Who said anything about using the same password on different sites?
Re: W3C approves WebAuthn as the web standard for password-free logins
#126Earlier quoted context omitted.
Passwords will continue to exist. But it has a lot of flaws, so it's nice have alternatives.
Is there a solution for the fact that all of your accounts will be secured by the same "source"? Isn't this almost close to using the same password on every site? I realize a physical secret is better than a password, but if someone gets their hand on your little FIDO device, do they instantly get access to all your accounts?
2FA is still an option (e.g. 1 thing that you have + 1 thing that you know), with the hardware token representing a more secure alternative to phone SMS messages.
> Isn't this almost close to using the same password on every site?
To get the a shared password, you have to hack one of hundreds of different services that password is used on, or phish the user, and penetration often goes undetected for years.
To get the physical secret, you have to rob the user, who will notice they've been robbed the next time they attempt to login. Additionally, trying to login to a phishing website won't automatically auth them with the real website - I can't do secure key exchange algorithms in my head, but a hardware device can.
Re: W3C approves WebAuthn as the web standard for password-free logins
#127Somewhat random thought: is Challenge-Response sufficient or should it be 'Challenge-Challenge-Response' so that the client only answers a challenge it requested? Otherwise, what's to stop an XSS attack on page A from effectively MITM page B by overriding the event listener for the login on page A, asking to sign for page B, then exfiltrating the response? EDIT: looks like the dialog attempts to give you some informa…
If your site makes it even remotely possible to have an XSS attack on the login page (by not being a separate page with no user-provided input apart from the login credentials) then you're doing login pages wrong to begin with.
Re: W3C approves WebAuthn as the web standard for password-free logins
#128I don't want to let the password go. It gives me the freedom to rightfully access my service if I just know the secret, without any entanglent to some app, device, or other account.
Re: W3C approves WebAuthn as the web standard for password-free logins
#129I think fundamentally most users don't understand anything more complicated than passwords. Passwords are easy. They make sense. A kindergartener understands the idea of a secret word that only they know. Tokens, certificates, FIDO -- it's black magic. Therefore people don't trust it. It has to be as easy and intuitive as passwords or it's a non-starter. That's why the SMS codes (though insecure) are so popular. Peop…
I'm still a bit bummed that OpenID (the original version) got lost to history. It's not really 'open' if you are handing over the keys to Facebook or Google.
Re: W3C approves WebAuthn as the web standard for password-free logins
#130Earlier quoted context omitted.
There are two methods, IIRC. `get` and `create`. Everything is done with Challenge/Response with the browser handling the Private Stuff. It's hard to mess up, at a glance. You ask the browser to create an asymetric key pair. It returns the public key, which the server saves. On login, you provide a challenge to the browser to sign using the private key from earlier. It returns the signed message and the server verifi…
What if the user is trying to login via a device different from the first one?
If you mean "what it I only used Security Key A to register, but now I want to sign in with Security Key B?" the answer is that you can't, that's the wrong key. Register all the keys you want to use.
If you meant what if I registered with my Pixel phone and now want to sign in on my Windows PC, that just works fine. The client "state" lives in the Security Key (actually there is no state whatsoever in affordable designs), it's very clever cryptography.