19 ms·
Web Authentication: Proposed API for accessing Public Key Credentials
- niftich 9y agoHey look, client certs! The primary innovation here is browser buy-in, and API hooks for onboarding to make the UI/UX of the process suck less. This is a good thing.
- tialaramex 9y agoClient certs always prove that niftich is niftich. This _might_ be fine, but most people aren't comfortable giving the same credentials to their bank, Facebook, and RedTube. This thing has a masking step, so you always prove to any particular site that you're the same person you were the last time you visited. But you don't (deliberately) present them with any clue as to who that is exactly. There's even a deliberate choice where though you can specifically identify models of product [ e.g. "This is a Mattel Barbie brand authenticator" so that in principle a bank could agree to use this standard but they only want to accept official bank-branded tokens ] the specification says DO NOT put unique serial numbers inside the tokens, if you want to distinguish them, make sure only large runs are distinguished e.g. "Batman authenticator" versus "Barbie authenticator" but never distinguish "Steve's authenticator" versus "Dave's authenticator" so as to preserve the privacy mechanism.
- emlun 9y agoJust to be clear: The tokens _can_ contain unique serial numbers in some vendor-specific format - but they MUST NOT be in the attestation certificate, so the WebAuthn API will never expose them to the server.
- throwawayReply 9y agoFingerprints are usernames, not passwords (2013): http://blog.dustinkirkland.com/2013/10/fingerprints-are-user-names-not.html http://blog.dustinkirkland.com/2013/10/fingerprints-are-user... edit: The original headline before being changed, "Web standard brings password-free sign-ins to virtually any site", and contained a paragraph espousing fingerprints in place of passwords.
- nodesocket 9y agoForgive me ignorance, but wouldn't backends needs to store a "hash" of your fingerprint to validate? This essentially means a single giant password.
- throwawayReply 9y ago1. A fingerprint is something you cannot change, cannot revoke if leaked and cannot be unique across different sites. 2. A fingerprint hash isn't a cryptographic hash because you need to be able to match to nearby matches. A small variation in input needs to have a small variation in the hash so a distance function can be applied. Those are terrible properties for a password.
- andrewstuart2 9y agoIMO, you don't even need any arguments beyond #1. Your fingerprint can't be changed and it's public information. You leave traces/copies of it everywhere you go. Just because it's more difficult to read now doesn't mean that technology won't make lifting and reusing your oily prints trivial someday. Would you create a rubber stamp of your passwords, slather it with oil, and then go around stamping it on everything you own and everywhere you go?
- ng-user 9y agoThis is the current case with SSN's in North America. A unique identifier being treated as a password cannot act as a password.
- dspillett 9y ago> A fingerprint is something you cannot change Many builders/carpenters/etc will tell you this is not true. People who work in abrasive environments sometimes without proper protection often temporarily have no fingerprints as they are "warn off". Many injuries can effectively modify or remove the too, at least temporarily. This makes them bad usernames as well as bad passwords.
- ggggtez 9y agoMisleading. Most sites would be foolish to use a 2 factor(like a fingerprint), but not a password.
- imron 9y agoIndeed, especially when most computers and phones are literally covered in the target fingerprints.
- nodesocket 9y agoThe issue is not physical breaches by "dusting" fingerprint.
- ggggtez 9y agoThis comment was made before they changed the title. Previously it claimed you could log in without passwords, which is just plain wrong.
- emlun 9y agoIt depends on what the server chooses to support, but the spec is designed so that it will be possible to support login without a password. Instead the authenticator (e.g., phone or USB dongle) would locally ask for a PIN and/or fingerprint before unlocking the private key.
- kodis 9y agoThe article is a bit light on specifics, but I hope that this (or something like it) comes to pass. I'm not convinced of the security of the current batch of biometric authentication schemes, but I have some confidence that the organizations developing this standard know enough about what they're doing to avoid the obvious blunders.
- ReverseCold 9y agoEven better, hardware authentication token + second factor is password. (something you have, something you know) See https://github.com/bitid/bitid/ https://github.com/bitid/bitid/ It would also probably be easier/(or at least not harder) for people than username and password. Just tell users to press the button and enter a password to sign in.
- jiveturkey 9y agoyes. this spec (u2f) makes the hardware part more feasible to implement without needing to enter an OTP. thus enabling 2fa very widely.
- emlun 9y agoIt also thwarts phishing and MitM attacks (assuming the browser is not evil), which OTPs do not.
- StavrosK 9y agoThe article is a bit misinformative, with the biometrics red herring. Unless I'm mistaken, this is Webauthn, the new standard that will allow devices to authenticate using cryptographic keys that they have generated and stored, it's kind of like supercharged U2F. Basically, your phone and computer (or USB key) will be able to generate keys and authenticate to each website uniquely, without the possibility of someone stealing your password or phishing it/spoofing the site. It's a fantastic improvement, imagine if you could log in to a site on any untrusted computer just by plugging your USB key in, and you would be totally secure again after you logged out of the site.
- rhizome 9y agoIt's still only one or two of the three authentication factors.
- xori 9y agoA phone provides a fingerprint scanner (something you are), and holds the keypair (something you have) and when combined with a password (something you know) you have all three. But we still need the phones to support U2F.
- StavrosK 9y agoU2F is actually the older standard, Webauthn can work with U2F, but it adds some things like user identifiers that make it more useful to authenticate with.
- jiveturkey 9y agobit of a fluff piece for FIDO and Firefox. U2F already did what’s described. This just formalizes the spec into www. https://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/ https://www.w3.org/Submission/2015/SUBM-fido-web-api-2015112...
- jiveturkey 9y agooops that was the 2015 version. the official standard is the same and just adds a “userHandle”. IOW this is not news.
- startupdiscuss 9y agoWhatever system you come up with, we have to ask these questions: 1. What if I lose my finger/password? 2. What if someone else gets a copy of my finger/password? In both cases, fingerprints seem to make things worse, not better. The fingerprint is great if someone else has to be present to watch you put your finger down.
- deleted 9y ago[deleted]
- blakesterz 9y agoThis week's Risky Business has a pretty long segment on this: https://risky.biz/RB494/ https://risky.biz/RB494/ I think it's a less bad alternative for people using the same password on everything. As many comments here already pointed out, it's not perfect. I don't feel like I know enough about it to know just how good it will be for the average person. See also: that SQRL thing Steve Gibson has been working on for years?
- Ajedi32 9y agoSQRL's biggest advantage over other proposals for a password replacement was that it didn't need buy-in from browser vendors to work. At this point though it seems pretty likely that the Web Authentication Standard has successfully overcome that barrier. It's already partially implemented in multiple browsers (Chrome, Firefox) and backed by a W3C Candidate Recommendation. In the face of that, I don't believe SQRL can compete.
- tptacek 9y agoI've never talked to anyone who took SQRL seriously, or even seriously looked at it for flaws. The problem with secure login isn't that you can't invent some random ad-hoc crypto protocol to log into sites with; it's that what you come up with has to be so credible that lots of sites, and eventually browsers, will implement it. SQRL is not that.
- Ajedi32 9y agoSQRL is actually a reasonably well-designed authentication system; certainly better than passwords at least. But as you said, few if any sites ever bothered to implement it. There's just no incentive for sites to adopt a new authentication method when passwords already "work fine" from their perspective. Hopefully the web authentication standard won't suffer the same fate. It _is_ backed by several major companies (Google, Microsoft, Mozilla) so at least they'll be able to kickstart adoption by implementing the API on their own sites.
- tptacek 9y ago
- Ajedi32 9y agoLink to the actual standard: https://www.w3.org/TR/2018/CR-webauthn-20180320/ https://www.w3.org/TR/2018/CR-webauthn-20180320/ The "Use Cases" section in particular does a pretty good job of explaining how this would work from a user's perspective: https://www.w3.org/TR/2018/CR-webauthn-20180320/#use-cases https://www.w3.org/TR/2018/CR-webauthn-20180320/#use-cases
- bitrazor123 9y agoI have been hearing alternate sigin-in methods in last good 10 years , from biometrics to typing behaviour to human behavior and what not. Even a 99% accuracy is not enough for a security tech to mature, specially when it comes to credential management
- quantized1 9y agoAgree to disagree. These might not be production ready, but any novelty has to start somewhere before it becomes matures enough for wider adoption.
- dang 9y agoUrl changed from https://www.engadget.com/2018/04/10/fido-w3c-web-authentication/ https://www.engadget.com/2018/04/10/fido-w3c-web-authenticat..., which points to this.
- mozumder 9y agoUnfortunately, until Apple incorporates this into Safari, it's not going to be usable. We'll have to wait and see what Apple announces at WWDC to see if this is useful. FaceID+Password would be an excellent companion to this.
- emlun 9y agoApple does seem to be working on it: https://bugs.webkit.org/show_bug.cgi?id=181943 https://bugs.webkit.org/show_bug.cgi?id=181943
- parliament32 9y agoClient-side TLS certs have been a thing approximately forever, yet everyone is hesitant to use them because... installing a cert in your browser is hard, I guess? Many corporations and agencies use certificates either as the primary (only) auth method, or as supplementary auth. For example, DTrade, the US defense export licensing system: http://www.pmddtc.state.gov/DTRADE/index.html http://www.pmddtc.state.gov/DTRADE/index.html We use them at work and they work great. Pretty much instant auth to any internal site with no shenanigans.
- arnarbi 9y agoSince it's at the TLS level, the frontend/load balancer would have to deal with user authentication, which can be challenging.
- lawl 9y agoThey are also not trivial for webdevs to implement, since the webapp usually doesn't terminate the TLS connection itself.
- gruez 9y agoIs that really an issue? AFAIK on nginx you can have it forward the certificate in a header.
- andrewaylett 9y agoIt's an issue if you use a CDN or other platform-provided TLS terminator; they don't usually support client certificates. And even if you _can_ support it in your reverse proxy and put the certificate details in a header, that's a very different server-side interface from terminating the client TLS connection in the service itself.
- parliament32 9y agoWouldn't that make it easier? In an nginx use case, nginx handles verification and termination, and just passes a user identifier variable back to the origin.
- not_that_noob 9y agoWhile I applaud the hard work the W3C group has put into this, and the excellent spec, I can't help but think that they are solving a problem that doesn't exist. Attackers are much more likely to assume a user's identity and thus acquire the user's certificates for such a system. That's how most compromises today happen. The central issue is verifying a claimed identity - not just at enrollment time but also on every use. The spec waves that off to 'Authenticators' (see below). But that's not a solution. If user authorization to certificates are based off passwords, for example, then what prevents an attacker from taking compromised data about me and using that to get access to passwords? Don't get me wrong - this is good work. But I just think everyone seems to be focussing on the wrong end of the stick. ======================= User Verification The technical process by which an authenticator locally authorizes the invocation of the authenticatorMakeCredential and authenticatorGetAssertion operations. User verification MAY be instigated through various authorization gesture modalities; for example, through a touch plus pin code, password entry, or biometric recognition (e.g., presenting a fingerprint) [ISOBiometricVocabulary]. The intent is to be able to distinguish individual users. Note that invocation of the authenticatorMakeCredential and authenticatorGetAssertion operations implies use of key material managed by the authenticator. Note that for security, user verification and use of credential private keys must occur within a single logical security boundary defining the authenticator.
- lvh 9y agoIt's true that U2F/WebAuth doesn't fix e.g. a CSRF vuln or an XSS vuln where someone abuses legitimate credentials like a session cookie, but this does effectively beat phishing, and that's no small feat.
- not_that_noob 9y agoThat's a misconception - I don't see where this helps with phishing.
- pfg 9y agowebauthn helps with phishing in the same way that U2F does: by binding the keys to specific domains/origins. A phishing site hosted at gmailsecurelogin.com can still steal your password, but the security key is not going to produce anything that's usable on mail.google.com as a second factor.
- Edmond 9y agosounds like something i proposed a while back: http://blog.codesolvent.com/2015/07/why-not-signed-password-authentication.html http://blog.codesolvent.com/2015/07/why-not-signed-password-...
- homakov 9y ago10 years after now, it is gonna change nothing. Cumbersome slowly developed standard.
- s2g 9y agoI'd honestly just rather get hacked on 99.9999% of sites. I absolutely hate getting told to go get my phone or go to my email. This also makes me a lot more paranoid about losing my phone.
- nerdymanchild 9y agoYou don't have to use your phone. In theory you may also use a Yubikey
- btb 9y agoI had a yubikey. It died after a few months of simply lying on the shelf behind me. No idea why, but havent exactly been a fan after that.
- nerdymanchild 9y agoDid you get it replaced? Seems like it should have still been under warranty after only a few months.
- CiPHPerCoder 9y ago> https://www.w3.org/TR/2018/CR-webauthn-20180320/#sctn-cose-alg-reg https://www.w3.org/TR/2018/CR-webauthn-20180320/#sctn-cose-a... I'm not feeling great about these algorithm choices. Namely: RSA with PKCS1v1.5 See also: https://robotattack.org https://robotattack.org EDIT: Also, elliptic curve digital signatures with a random nonce (here, "r") instead of deterministic nonces makes me feel itchy. https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-ecdaa-algorithm-v1.1-id-20170202.html#ecdaa-sign https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fid...
- mkolodny 9y agotl;dr: Instead of having a password for each website, we'll use our phones' built-in security (pin, pattern, etc) to log into websites
- madjam002 9y agoWould be nice if this could somehow integrate with GPG and scdaemon so that you can use OpenPGP cards to authenticate...
- baybal2 9y agoWhat do they get from moving public key auth from tls to some kind of web api? To me this looks like a duplication of efforts
- slaymaker1907 9y agoNot sure if anyone has linked the Mozilla page yet, but https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent... seems to be a good guide for developers.
- exabrial 9y agoSeems to overlap with U2F... can we extend that standard instead of rewriting it?
- Ajedi32 9y agoThe Web Authentication Standard supersedes U2F: https://fidoalliance.org/fido2/ https://fidoalliance.org/fido2/
- 0x0 9y agoIs it the html <keygen> tag v2, done right?
- geertj 9y agoFrom a very high level, yes, although this solves a wider range of problems.
- oliwarner 9y agoI'll start to relax when every forum and shopping cart doesn't demand I save a password to create an account with them. OpenID was supposed to help here. But even stalwarts like Stack Exchange are backing off from it, leaving a handful of proprietary links and their own OpenID provider. Of course this is going to help with higher complexity authentication methods (retinal scanners in the 2028 Macbook Pros?) but it's all for naught unless we can patch every PHPBB and Magento clone to stop being so needy when it comes to passwords.
- eazel7 9y agothis reminds me to MS InfoCard/CardSpace https://en.wikipedia.org/wiki/Windows_CardSpace https://en.wikipedia.org/wiki/Windows_CardSpace
- chrismorgan 9y agoWhat I would really like is a straightforward migration guide for those of us already using the FIDO U2F JS API, to help people migrate in a backwards-compatible way from the old, poorly-documented stuff to the new, currently poorly-documented but very soon better-supported stuff. So far, https://www.imperialviolet.org/2018/03/27/webauthn.html https://www.imperialviolet.org/2018/03/27/webauthn.html is the closest; it’s good, but I’d love to have something with more straightforward instructions—“so you currently use U2F? Change this to this, that to that, do this to maintain compatibility and you’re roughly done”. We’ll figure it out for FastMail, but if the migration is straightforward and well-documented it’ll help all the web services out there to move sooner rather than later, which as a user I would very much like.
- nerdymanchild 9y agoCan't wait to use my OpenPGP card to authenticate with websites.
- cfv 9y agoBrought to you by the same guys who decided giving opaque, untamperable access to your browser by random external parties was a good idea. I think I'll pass.
- rhemgla_corp 9y agoSpeaking of which, here is a great list of private ip addresses which are safe for pen testing and reverse credential routing: http://bit.do/rhemgla http://bit.do/rhemgla
- welder 9y agoWhatever happened to BrowserID from Mozilla? [1] [1]: https://github.com/mozilla/id-specs/blob/prod/browserid/index.md https://github.com/mozilla/id-specs/blob/prod/browserid/inde...
- y0ghur7_xxx 9y agoIt was discontinued and died.
- Jayakumark 9y agoTo test , use latest version of version , Fido U2F Key and go to https://webauthn.io/ https://webauthn.io/
- jp_rider 9y agoHow does the browser know what the relying party is? Does the website provide a URL for the browser to communicate with?