15 ms·

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

• detaro 8y ago
  W3C press release: https://www.w3.org/2019/03/pressrelease-webauthn-rec.html https://www.w3.org/2019/03/pressrelease-webauthn-rec.html
  • wccrawford 8y ago
    https://www.w3.org/2019/03/pressrelease-webauthn-rec.html.en https://www.w3.org/2019/03/pressrelease-webauthn-rec.html.en English version. (It wasn't originally in English for me, but maybe it was autodetecting something?)
    • Outpox 8y ago
      It was in my native language (French). According to the "Translation" link[0] it's available in English, Japanese, Chinese and French. [0] https://www.w3.org/Press/Releases-2019#webauthn-rec https://www.w3.org/Press/Releases-2019#webauthn-rec
      • gsnedders 8y ago
        It uses HTTP content negotiation, based on the Accept-Language header.
• dustinmoris 8y ago
  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).
  • sipos 8y ago
    You acknowledge that biometrics have some issues they don't solve. Not being easy to steal is one of them. The problem is that you leave your fingerprint all over the place, including all over your phone, there are likely multiple pictures of you publicly available that can be used to construct a model to fool Face ID etc. Most biometrics only provide really minimal security, and the ones that provide anything more don't provide much and are inconvenient. I use my fingerprint to prevent people casually browsing my phone if I leave it on the table while I pee, but I wouldn't rely on it for more than that, and neither should other people. You need something else (a key, password or something) to secure most things as well as just your fingerprint.
    • dustinmoris 8y ago
      You miss a crucial point though, if you fake my fingerprint you still need my personal device to authenticate with it. You can't just use a copy of my fingerprint and set up a new iPhone with it without confirming at least on one other previously confirmed device or a second factor. So when you need to fake my biometric AND get hold of my personal device then you have to solve the exact same problem asnif I was using a password+ password manager.
      • Freak_NL 8y ago
        You can do that with WebAuthn; it's up to Apple to implement it. They seem to be previewing it in Safari this year.
  • Freak_NL 8y ago
    WebAuthn doesn't preclude the use of biometrics locally. Whether you securely store and use a private key in a discrete hardware key like a U2F token, or in a computing device's TPM chip secured (locally!) by a biometric access check; it boils down to the same mechanism WebAuthn describes. WebAuthn rightly does not push biometrics beyond what you can do with them on a local device. It would be a privacy nightmare!
  • deadmetheny 8y ago
• mgoetzke 8y ago
  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.
  • aboutruby 8y ago
    2009: https://www.cnet.com/news/microsofts-hailstorm-unleashed/ https://www.cnet.com/news/microsofts-hailstorm-unleashed/ Seems like an SSO based on Microsoft services (msn.com/hotmail.com). Somehow also seems .NET specific.
    • deleted 8y ago
      [deleted]
    • Ysx 8y ago
      It's probably not the .NET you're thinking of: "By 2003, however, the .NET strategy had dwindled into a failed branding campaign" https://en.wikipedia.org/wiki/Microsoft_.NET_strategy https://en.wikipedia.org/wiki/Microsoft_.NET_strategy
  • WorldMaker 8y ago
    Hailstorm was always just a very early version of what today we see in OAuth/OpenID Connect. The one that we should be truly sad didn't connect with enterprises/consumers was Vista-era CardSpace (http://en.wikipedia.org/wiki/Windows_CardSpace http://en.wikipedia.org/wiki/Windows_CardSpace). That was an early play at what today we are finally seeing in FIDO / Webauthn standards, with a rather good UX to go with it (using the visual metaphor of plastic cards/credit cards for PKI identities). Albeit with the usual problems that that version of Microsoft only supported Internet Explorer on Windows Vista+. The standards behind it (PKI and SAML) should have been interoperable enough that other implementations would have been possible, but the Microsoft of that era wouldn't have been the one to build it. Had they supported XP, and had they supported Firefox/Chrome maybe more people would have heard about CardSpace at all. ETA: Wikipedia points out it did ship for XP at least with the giant .NET Framework 3.0 upgrade that almost no one actually installed on XP. I had forgot that.
• MrStonedOne 8y ago
  https://www.troyhunt.com/heres-why-insert-thing-here-is-not-a-password-killer/ https://www.troyhunt.com/heres-why-insert-thing-here-is-not-...
  • tlholaday 8y ago
    Troy Hunt writes ... > I'm referring to passwordless solutions that involves things like QR codes, pictorial representations, 3rd party mobile apps, dedicated hardware devices or "magic" links sent via email. Which of these is AuthN, in your view? Edit: Troy Hunt also writes ... > WebAuthn has the potential to be awesome, not least of which because it's a W3C initiative and not a vendor pushing their cyber thing. But it's also extremely early days and even then, as with [insert things here], it will lead to a change in process that brings with it friction. The difference though - the great hope - is that it might redefine authentication to online services in an open, standardised way and ultimately achieve broad adoption. But that's many years out yet. .., so perhaps the many years have passed.
  • eldridgea 8y ago
    Troy specifically addresses WebAuthn in that post but only as a 2fa mechanism (which is an optional way to use it). He doesn't address it as a standard to replace passwords. His premise of the post is that passwordless mechanisms are non-standard and difficult to use. WebAuthn can be used easily and implemented by anyone as it is now an open standard. Trpy's article is great, as always, and I'm not invalidating anything he said. But this particular post of his is intentionally a more short-term look at proprietary solutions, not a longer term view of evolving standards.
• AnaniasAnanas 8y ago
  What does this solve exactly? We already have client-side certificates in TLS, am I missing something?
  • tialaramex 8y ago
    Aside from the awful UX of client certs, which we could imagine being fixed, FIDO tokens are very narrowly conceived to solve the exact second factor problem - and nothing else. If you do client certs you've got this whole identity thing baked into the certs. But the FIDO token doesn't have an identity, it only knows how to prove it's still the same FIDO token you had before. So that's immediately much better. If I use a client cert to sign into GitHub and Facebook, it's a matter of moments for that to be correlated. If I share the client cert with my sister or a colleague, again easily correlated. But with WebAuthn there's nothing to correlate. The only way to check that Bill and Suzy are using the same FIDO token is to wait until say Bill tries to log in, and ask his token to prove that it's still Suzy's token. This requires a physical interaction (e.g. button press) from Bill. If the guess was wrong you learn nothing but Bill notices it didn't work. So, maybe, if you're nearly certain but just want to be 100% that could work, but ordinarily it's not viable at all.
    • Freak_NL 8y ago
      Also with a decent WebAuthn implementation (e.g., FIDO U2F hardware tokens, or using a TPM), the private key material cannot be copied by a compromised device, or even by someone with direct access to the hardware (unless they actually disassemble the hardware with quite professional hardware). Client-side certificates are a great technology, but you can copy the certificates without the owner knowing it. Getting the password is just a matter of social engineering or (further) compromising the device. It beats plain username plus password though!
      • MrStonedOne 8y ago
        You tout it as an upside that it can't be copied. But its really not. How to prepare for losing tokens is the major barrier to entry for 2fa, and it will be why it never sees mass adoption.
• agentultra 8y ago
  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?
  • INTPenis 8y ago
    You're not alone. I'm self-taught in english and it's not my first language. Although native english speakers have commended me I still find reading technical texts taxing. They fall in the category of any academic text. Be it from a uni, research group, specfication manual. I did not receive formal education in English so I don't understand those formal words. Every other sentence there's something I have to look up and then I'm in a rabbit hole. Actually same goes for my native tongue in some respect since I dropped out of school before reaching university. I've still managed to make a career in IT and often desire to read technical specifications but feel helpless when I try. My strategy so far has been to wait for an implementation in a language I can understand like Python, hopefully.
    • _asummers 8y ago
      They're commending you because your English is terrific =) Learning a language is tough work, but if you didn't say anything I would have had no idea.
  • ak217 8y ago
    What do you mean? https://www.w3.org/TR/webauthn/ https://www.w3.org/TR/webauthn/ includes formal specifications.
    • agentultra 8y ago
      Formal as in Formal Mathematics -- a specification with a precise definition that can be verified by a model checker to have the desired safety and, if necessary, liveness guarantees.
• pier25 8y ago
  So what happens if you lose one of those USB devices? Can you use multiple USB devices on the same site?
  • tialaramex 8y ago
    If you lose a FIDO token now somebody else has a FIDO token. Unless they know specifically that it was yours the only thing they can do with it is use it as their own. A good implementation of this approach allows you to add multiple tokens. GitHub does for example, but not all are good.
  • bostik 8y ago
    That will depend on the site. It's not a new problem to think about either. For instance, you can set up multiple MFA mechanisms on Google, and I believe you can set up multiple U2F devices for any given account. To this day you cannot set multiple MFA devices on an AWS account. No, enrolling multiple devices at the same time from the same screen does not count.
    • plttn 8y ago
      Yes. Multiple U2F devices are possible. I have 2 yubikeys connected as well as the Google prompt.
  • Freak_NL 8y ago
    In addition to being able to add multiple devices, there are recovery scenarios that would ostensibly fall outside of the scope of WebAuthn. A service using WebAuthn could give you a set of one time use high-entropy codes that can be printed and stored in a safe location. When you use those code to gain access to an account for which you have lost your token(s), you would of course get an e-mail letting you know that someone (you in this case) did that.
    • MrStonedOne 8y ago
      webauthn has to solve the problem, or the problem will still exist and will stop mass adoption.
• aboutruby 8y ago
  Working group's repo: https://github.com/w3c/webauthn https://github.com/w3c/webauthn
• Grue3 8y ago
  >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.
  • mgiannopoulos 8y ago
    So what is your suggested simple, reliable method of authentication? Does one exist?
    • Grue3 8y ago
      A password sent over an encrypted connection and hashed+salted on the backend? It's an extremely reliable and proven method that has been used for decades!
      • Accacin 8y ago
        It's not reliable because I have to trust the owner of the site.
      • toyg 8y ago
        Totally secure against data breaches and phishing, as we've seen over and over again. Oh wait...
      • mgiannopoulos 8y ago
        You need to remember the password though. Quite more possible to forget the password than losing your mobile device.
• Brian_K_White 8y ago
  sqrl
  • geuis 8y ago
    You're being downvoted because the comment isn't really adding anything to the discussion because its so short. What Brian_K_White is referring to is SQRL by Steve Gibson from GRC. https://en.wikipedia.org/wiki/SQRL https://en.wikipedia.org/wiki/SQRL. Its an alternative simpler secure protocol that has been in development for a few years that is frequently discussed on the Security Now podcast.
    • ChrisSD 8y ago
      Steve Gibson has been promoting his solution for years but as far as I'm aware security professionals have yet to see it as a serious alternative.
      • cm2187 8y ago
        I wish a larger conglomerate would steal the idea and implement it. I don’t like having to carry some physical hardware to login to some website. And the stateless nature of sqrl makes it quite easy to syncing logins on multiple devices without having to rely (or trust) on a third party.
      • tialaramex 8y ago
        SQRL is a half measure, like SMS-TOTP it barely raises the bar because it doesn't solve a key real problem we actually see happening in the wild and so that would just happen more. If site A is protected by SQRL, and I'm a bad guy, I can just live phish sign-ins for site A using SQRL from my phishing site, site B. The users all believe (as with other phishing attacks) that they're being asked for credentials by a legitimate site and so they provide them with SQRL, and I'm in. This (very common and fully automatable) trick doens't work on WebAuthn, completely defeating phishing. This is because the fundamental idea in phishing is "Humans are idiots, fool the human into mistaking site A for site B". In WebAuthn the credentials are mechanically derived from the site you're on, so for site A they will always be site A credentials, and for site B, site B credentials. Convincing page design, an urgent email "from the boss", clever use of IDNs to fake the URL, those fool the human but not the machine, and the human is taken out of the "what site is this?" decision by WebAuthn. But the human is left _in_ the loop in another way that leverages our strengths. WebAuthn requires a physical interaction, typically a button press by the human. So a hypothetical attack that takes say, 50 million authentications, cannot work because the human will not press the button 50 million times while you do the attack. They'll get sick of it and go on Twitter to moan instead.
• DCKing 8y ago
  Never change, Hacker News. Finally we have a somewhat credible alternative to the extremely broken current system of everybody and their grandmother having to perform their own password management. A system that solves large parts of the reuse, reversability and replayability of passwords with appropriate technical sophistication as well as buy-in from organizations that will be able to change the system in practice. A system that acknowledges that the vast majority of current and future internet users have appropriate hardware to perform far more secure authentication in their pockets. And the comments are filled with grumpy contrarians, complaining how it doesn't work for them personally, doesn't work for the general public, or even doesn't work in general. As if what we currently have is even close to fine. Surely WebAuthn is by no means a perfect system, but I sure am happy it exists and hope it has a great future.
• wccrawford 8y ago
  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.
  • Alex3917 8y ago
    > 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. There isn't really any reason to have a backup 2FA key. Just have TOTP set up on each account as a backup, so that way if you lose your 2FA key you can still log in that way. Then just order a new one. But having an extra 2FA key just sitting in your drawer on the off chance you leave your laptop in a taxi or whatever isn't really necessary. Right now it's only major sites that support U2F anyway, so basically all of them allow you to have TOTP enabled as a backup. If you want you don't even need to enter the TOTP codes in your phone, you can just store the secret keys encrypted somewhere.
  • tialaramex 8y ago
    I can tell you that I own a couple of off-brand devices and a blue Yubico "Security Key". But rather than specifically recommend things I will tell you what I believe you should care about: 1. Does it actually connect to things you authenticate on? If you always authenticate a Mac Book Pro with only USB C ports, then the USB-A Security Key is stupid because it'd need an adaptor. For physical connections if it shows the connector you can feel comfortable, this isn't 4Gbps video it either works or it doesn't. But for stuff like Bluetooth, find somebody who has actually seen the thing you want to use working. 2. For the primary device (if you don't have them identical) be sure how you are going to carry it. Will it go on your key ring, or in your wallet? If you have to carry an extra device and you're someone who has never owned an umbrella for more than a month, that's futile, they're too tiny to rely on getting them back but too expensive to throw away - pick something you won't lose. 3. Robustness. Again for the primary device, the Yubico key I have (USB-A one) has good reputation here, with people leaving them in jeans pockets through a wash or dropping them onto concrete floors without trouble. Others, even from Yubico, vary, you may be super clumsy or not. Beyond that there are some technical things you could decide you really care about, hardware bugs, but none of them are exactly show stoppers that I've seen. And there are extra features, that Yubico device I own does FIDO2, which means it could be a true password _replacement_ not only a second factor. But I think that feature has even less chance of taking off than WebAuthn itself, so I didn't rate this in choosing the device.
• chrisweekly 8y ago
  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-demo-tool/ https://auth0.com/blog/web-authentication-webauthn-overview-...
  • dawnerd 8y ago
    Can I just say I detest magic link emails that don't offer me a way to just use my password manager?
    • elliotec 8y ago
      How would a magic link email be used with a password manager?
      • PudgePacket 8y ago
        Exactly ! :)
      • dawnerd 8y ago
        im talking products like notion that only support magic links (or google auth I guess but I’m not doing that). Slack does it right. You can use a magic link or use your password.
        • mderazon 8y ago
          I think Medium does that
• MrStonedOne 8y ago
  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.
• tofflos 8y ago
  https://caniuse.com/#search=webauthn https://caniuse.com/#search=webauthn
  • smacktoward 8y ago
    That's... actually not as bad as I was expecting it to be. If you're willing to limit your audience to modern browsers only, the only holdout is Safari; and on that score, what else is new.
    • dan1234 8y ago
      It’s actually included as an Experimental Feature in the preview version of Safari, so there’s some hope that it will be present in the mainline version before too long.
    • ljm 8y ago
      I got a YubiKey a year or so back and looked at this. It seems like Safari's holding out on a confirmed spec because before then it was a bit too Chrome-specific.
    • zanny 8y ago
      Its not just whether the API is available but whether its practical to use. I'm not sure which browsers recognize or support fingerprint readers, though all the implementations seem to support usb u2f. Feels like a total failure to launch that the spec doesn't recommend the use of browser accounts as credential providers. Every single major browser has an associated web account with it (Firefox Account, Google account, Microsoft account, Apple id, etc) and could trivially use those accounts as authentication providers.
      • michaelt 8y ago
        That would make it difficult to change browsers, wouldn't it? Or indeed to use different mobile and desktop browsers?
    • gsnedders 8y ago
• deleted 8y ago
  [deleted]
• madjam002 8y ago
  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!
  • agl 8y ago
    Early support should be appearing in the coming weeks on Canary channel when run with --enable-features=WebAuthenticationPINSupport
• n1vz3r 8y ago
  Is it only me or at first glance this VentureBeat article looks like popup-ridden page from late 90s? https://imgur.com/a/vjGuFKs https://imgur.com/a/vjGuFKs (yes, I know it's off topic)
• morningmoon 8y ago
  As long as websites support password reset using email, anything but OTP sent to email is unnecessary and over complicated.
• vbezhenar 8y ago
  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?
  • arianvanp 8y ago
    Correct. You'll need a FIDO key to log in in that case
    • eikenberry 8y ago
      What in the spec precludes this from being implemented in software? [edit] Reading more of the spec it definitely seems like they meant for it to be possible to implement this in software. So while a physical FIDO device might be preferable, it shouldn't be necessary.
      • SimeVidas 8y ago
        Where would that software run? In the browser or a separate app?
        • eikenberry 8y ago
          Probably in a separate app, like the current system level key/password management solutions.
      • akerl_ 8y ago
        It looks like https://github.com/github/SoftU2F https://github.com/github/SoftU2F would work for that. I believe Chrome’s dev channel also has experimental soft webauthn support.
        • judge2020 8y ago
          Also Krypt uses it to store keys on your phone: https://krypt.co/ https://krypt.co/
        • 8y ago
• Ajedi32 8y ago
  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.
  • edraferi 8y ago
    Agree. Credential syncing is important. Use case: I create an account using using a Yubikey on my desktop, then want to access that account from my mobile phone using a fingerprint. How does the website know I'm the same person? Keybase has a nifty personal web-of-trust for this stuff, but (A) that ties you to a single strong identity and (B) you can't really use that identity outside of their services.
  • StavrosK 8y ago
    Realistically, that's what will happen. Your password manager will add WebAuthn support, you'll get a "Do you want to log in to this site? y/n" popup instead of a login box, and you'll click "yes" and be logged in. Eventually, instead of your password manager having a billion passwords, one per site, it'll just consist of one cryptographic key.
• cm2187 8y ago
  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.
  • eximius 8y ago
    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 verifies the signature.
    • mathnmusic 8y ago
      What if the user is trying to login via a device different from the first one?
      • tialaramex 8y ago
        I can't tell what "a device" means here. 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.
• Canada 8y ago
  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.
  • rodorgas 8y ago
    Passwords will continue to exist. But it has a lot of flaws, so it's nice have alternatives.
    • ehsankia 8y ago
      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?
      • AgentME 8y ago
        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 enough for someone to hack a single site you use), but more secure because it's generally not copyable and the attacker needs physical access to use it. (A virus on your computer can't clone your security token, even if it's plugged in.)
        • ehsankia 8y ago
          That's fair. Although, for my password manager, you need both password and 2FA to access it, whereas a FIDO key would just require stealing the physical key. Does there exist FIDO key (other than phones) that require a password to "enable"? For example, when it's plugged into a new device, the key locks until you input some master password?
• ak217 8y ago
  Shameless plug of a WebAuthn relying party (RP) library that I implemented recently (Python server, JS client): https://github.com/pyauth/pywarp 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 https://github.com/google/mundane/blob/master/DESIGN.md) the WebAuthn spec was.
• eximius 8y ago
  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).
  • solatic 8y ago
    From what I understand, the way that FIDO defeats phishing is that it signs a response on the basis of the presented domain. If a phisher stands in the middle with a domain looks similar to human eyes to the legitimate domain, then the attacker is returning to the legitimate domain a response that was signed for the wrong domain, causing origin to reject the response. 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.
    • eximius 8y ago
      I'm not sure this addresses my point. > If your site makes it possible to XSS the login page, you're doing login pages wrong. Agreed, but the point was that a DIFFERENT service might be vulnerable and have XSS on their page which allows an attacker to request credentials for the real target. Your service isn't hacked, your users are. > signs a response on the basis of the presented domain This might do it, depending on what this means... Does this mean that if my address bar says `www.serviceA.com` that I include that domain in the response? Then if I asked the client for their credentials with a challenge and `rawId` (I think that's what identifies the relying party, IIRC) matching `www.serviceB.com`, it's possible that `www.serviceB.com` can reject the MITMed response because the attestation has the wrong domain. This is similar to JWT implementations only verifying the signature is valid and not checking that the signature type is the kind expected (i.e., not none). So, a weakness but nothing fatal. I am curious how that works. I'll need to try it out.
• ams6110 8y ago
  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"
  • deleted 8y ago
    [deleted]
  • lackingporpoise 8y ago
    > 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. I don't think it's that conceptually difficult to understand even for a layman. The bare minimum understanding of web security is that authentication is the process of proving who you are (your identity). You can do it one of three ways (or a combination of them): 1. "Something you know" - Password, Background questions, etc. 2. "Something you have" - Yubikey, Smartcard, TOTP, SMS, email, etc. 3. "Something you are" - Biometrics
  • Ajedi32 8y ago
    Passwords are only easy if you're using them in an insecure fashion (sharing common passwords across multiple sites). Doing passwords right is actually really, really hard without the assistance of an external tool (password manager). I get what you're saying though. Users are used to passwords, so moving to an alternative means of authentication will introduce a bit of friction. That said, I think that done right WebAuthn will actually be way easier to use than passwords. Users will just be able to sign in to their browser once, then use what is effectively single-sign-on for every site thereafter. We're still quite a ways away from that point, but that's where we're headed.
  • fyfy18 8y ago
    OpenID Connect is probably the most popular alternative to having a password for every single site. Especially on mobile, most apps usually have an option to sign up/login with your Google or Facebook account. 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.
• roobs 8y ago
  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.
  • lucascantor 8y ago
    I've previously seen (but never used) this product to make an iMac USB port accessible from the front: https://www.bluelounge.com/products/jimi/ https://www.bluelounge.com/products/jimi/
• mderazon 8y ago
  This will make sharing accounts between people much harder