from Hacker News

W3C approves WebAuthn as the web standard for password-free logins

by markoa on 3/4/19, 1:47 PM with 147 comments

  • by chrisweekly on 3/4/19, 5:26 PM

    I 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-...

  • by Canada on 3/4/19, 10:37 PM

    I 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.

  • by ams6110 on 3/5/19, 3:00 AM

    I 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. People understand "enter this number that I just texted to you"

  • by vbezhenar on 3/4/19, 10:00 PM

    I don't understand how does it work. If I'm using just desktop and don't have mobile phone or any specialized hardware, I can't login?

  • by agentultra on 3/4/19, 4:06 PM

    Does anyone else find these informal specifications difficult to digest?

    The informative appendices link to papers on TPM and the like but it's hard to find a formal description of the protocol, or at least the sensitive parts, that could be independently validated or verified.

    Has there been any work to formally verify/validate the design of this protocol that I'm not seeing?

  • by ak217 on 3/4/19, 11:17 PM

    Shameless plug of a WebAuthn relying party (RP) library that I implemented recently (Python server, JS client): https://github.com/pyauth/pywarp

    Having worked with a few different standards before, I was pleasantly surprised by how easy to understand and ergonomic (https://github.com/google/mundane/blob/master/DESIGN.md) the WebAuthn spec was.

  • by detaro on 3/4/19, 1:59 PM

  • by tofflos on 3/4/19, 6:34 PM

  • by Ajedi32 on 3/4/19, 10:12 PM

    Almost there; now we just need some cross-platform implementations with synced credentials, and support from a couple major sites. Ideally some password managers will step in and implement support, and Google will add support to their own login flow as a primary authentication factor.

  • by madjam002 on 3/4/19, 8:29 PM

    Still waiting for Google Chrome and Firefox to support User Verification in the form of PIN prompts and Resident Keys for true passwordless login (at the moment WebAuthN in Chrome is basically just 2FA, no option for Passwordless).

    Hopefully soon!

  • by eximius on 3/5/19, 12:32 AM

    Somewhat 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 information, but it doesn't say WHICH profile on the domain and people could certainly not pay attention to the domain in that prompt (I had to check if it existed because I hadn't noticed).

  • by mgoetzke on 3/4/19, 3:04 PM

    If only Microsoft hadn't chosen to use the code-name Hailstorm for its authentication proposal back in the days (and generally had a better image and a more open approach etc). Would have alleviated a lot of the pain earlier.

  • by pier25 on 3/4/19, 4:08 PM

    So what happens if you lose one of those USB devices?

    Can you use multiple USB devices on the same site?

  • by wccrawford on 3/4/19, 5:24 PM

    The last time I saw 2fa and fido talked about on here, someone recommended a set of 2 keys, but they ones they recommended are now out of stock.

    Does anyone have a recommendation with the reason?

    Thanks.

    Edit: With the reason. Jeez, what a typo.

  • by Grue3 on 3/4/19, 4:24 PM

    >Users log in with simple methods such as fingerprint readers, cameras, FIDO security keys, or their personal mobile device.

    Neither of these methods are simple. I don't have a camera or fingerprint reader, idk what is FIDO security key or how to get one, and mobile phone can be lost or cease working at any moment so it's not a reliable method of authentication.

  • by cm2187 on 3/4/19, 10:18 PM

    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.

  • by aboutruby on 3/4/19, 4:22 PM

    Working group's repo: https://github.com/w3c/webauthn

  • by dustinmoris on 3/4/19, 2:42 PM

    I was saying for a long time that a new protocol for a biometric driven login scheme should become the new default. We use biometrics to log into our phone, then a password manager uses the same biometric to authenticate on the same device to log me into a website by auto populating the username + password for me. Afterwards I'll get a 2FA confirmation on the same device which again I'll have to confirm via the same biometric. Instead of having so many moving parts which all boil down to authenticate via a single vector (my fingerprint or eye) on a single device we might as well have a new auth scheme and get away with insecure passwords and expensive password managers and replace them all with a new biometric driven login scheme.

    Yes, there are still some issues that biometrics don't solve, but they should not be a concern to most websites. If everything authenticates me via my AppleID (which uses FaceID or Fingerprint) then I only need to remember one password for Apple - which is just the same as remembering one password for a third party password manager - except it's overall much safer and better for me as a user as I don't have to upload all my online identities to yet another third party that I don't know anything about (= password managers).

  • by roobs on 3/5/19, 3:06 AM

    I moved from primarily using a MacBook Pro to an iMac Pro a few months ago, and have struggled to find a non-awkward FIDO U2F key due to the ports being on the back. I'm really looking forward to a decent range of BLE U2F keys that are supported on Desktop and Mobile.

  • by MrStonedOne on 3/4/19, 5:26 PM

    tl;dr: Every downside to 2fa is out of scope, so this doesn't solve them, and doesn't require sites solve them.

    It then suggests using this as both factors.

    Most of all is reliability.

    all "Something you have" based factors have one key issue, reliability.

    Backup codes are not a solution, I'm not going to have those when i'm at a friends house and get an alert the server is dead but i left my token at home.

    Customer service is not a solution, its hard getting me to change my address in the millions of places that have it, now I have to call up, to change my token, because I lost it and have no idea where the fuck i put the backup codes? Across the millions of websites I have an account on? Where each provides their own backup codes?

    Backup tokens are barely a solution. In that they only work once, lose your backup token and you are back to the above. At the least you now have to buy another one to become the new backup and go and load it on to all of your sites.

    I can't lose, break, forget at home, or otherwise invalidate a password. I can forget it outright, something we know a lot of about, and something we have workflows setup to deal with, some better than others, but I can't just one day lose it and get locked out of everything, I would have to forget all of my passwords simultaneously to do that.

    2fa for people who care about it seeing adoption: cloneable tokens. I shouldn't need to re-setup my token across every site when it lose it. Habadab about security all you want, as long as this is a barrier to entry it will stay a barrier.

    Also, with fancy crypo, it would be piss easy to make a token key base where each token had its own key and that key can be revoked, but in a way where all tokens work out of the box once you add 1 to a site.

  • by n1vz3r on 3/4/19, 8:59 PM

    Is it only me or at first glance this VentureBeat article looks like popup-ridden page from late 90s?

    https://imgur.com/a/vjGuFKs

    (yes, I know it's off topic)

  • by mderazon on 3/8/19, 12:50 PM

    This will make sharing accounts between people much harder

  • by morningmoon on 3/4/19, 9:08 PM

    As long as websites support password reset using email, anything but OTP sent to email is unnecessary and over complicated.

  • by Brian_K_White on 3/4/19, 4:50 PM

    sqrl

  • by MrStonedOne on 3/4/19, 3:55 PM

  • by AnaniasAnanas on 3/4/19, 3:55 PM

    What does this solve exactly? We already have client-side certificates in TLS, am I missing something?