Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port Chromium U2F support to Electron #3226

Closed
woodrow opened this issue Oct 26, 2015 · 43 comments · Fixed by #30438
Closed

Port Chromium U2F support to Electron #3226

woodrow opened this issue Oct 26, 2015 · 43 comments · Fixed by #30438

Comments

@woodrow
Copy link

woodrow commented Oct 26, 2015

We'd love to use do 2FA authentication using U2F devices with our Electron app but it looks like the built-in plugin in Chromium needs to be ported over to Electron. We might be able to contribute to the work involved here, but I'm not really sure where to start.

Screenshot:
screen shot 2015-10-26 at 2 15 42 pm

Expected behavior: In Chrome/Chromium you're prompted to insert and touch your U2F device. No extension is required as of Chrome 41.

@anaisbetts
Copy link
Contributor

👍 if it's not Crazy Difficult

@nadimkobeissi
Copy link

+1

@anaisbetts
Copy link
Contributor

I looked into this, it is actually Crazy Difficult, their extension is like, walking the USB HID tree polling for descriptors and shit.

@nadimkobeissi
Copy link

@paulcbetts Sorry to hear. Thanks for taking a look.

@woodrow
Copy link
Author

woodrow commented May 23, 2016

@paulcbetts Thanks also for taking a look. The behavior makes sense, as crazy as that is. I take it this means it's not possible/desirable to copy the code directly from chromium?

@anaisbetts
Copy link
Contributor

@woodrow This code isn't in Chromium, it's in an Extension, we'd have to implement the APIs that back that extension. While sometimes we can make that happen, if the extension is simple, this one is not.

I'd love to be wrong and have someone do this, so if they think I'm full of it 👍 though!

@woodrow
Copy link
Author

woodrow commented May 24, 2016

Got it. I don't know enough electron/chromium to know if this is a crazy or super-crazy idea, but would it be possible to somehow expose a MessagePort that's backed by the yubico u2f client library? https://github.com/Yubico/libu2f-host

(the MessagePort is used to implement the U2F javascript API: https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html)

@molekilla
Copy link

Here is the Google u2f reference code, https://github.com/google/u2f-ref-code what do you think?

@molekilla
Copy link

Probly adding the extension and making an electron API to allow U2F, https://github.com/google/u2f-ref-code/blob/master/u2f-chrome-extension/README.md is there any guide to contribute I'm interested in this

@anaisbetts
Copy link
Contributor

Now that we're implementing a ton of Chrome extension APIs for DevTools, maybe this is more tenable

@graywolf336
Copy link

I think this would be a great addition to electron so that applications can make great usage of this, especially chat style applications like Rocket.Chat, Mattermost, Slack, etc.

@spodatelev
Copy link

Is there any update on the status/plans for this? Would very much love to have U2F in Electron.

@ItsShadowCone
Copy link

I am probably going to try to wrap the U2F host library (https://developers.yubico.com/libu2f-host/), which is written in C and allows U2F from any application that integrates it, into a native node module. Would that make your U2F implementation easier, would it even be easy to do it that way or is it just the wrong approach for this problem?

@anaisbetts
Copy link
Contributor

@Cl1608Ho This would help, the only existing node U2F library seems to be horribly bitrotted and doesn't work. This approach in general could work, though one problem is that for many U2F login sites, we'll be blocked by #2605, since they often include the U2F section in an iframe.

@ItsShadowCone
Copy link

.... What? Why do the U2F part in an Iframe? I understood it that way that U2F is just two Javascript functions that are defined in this script: https://demo.yubico.com/js/u2f-api.js.

I'm not sure how you would achieve it but when you have this nodejs module, you would just need to use the two functions that the nodejs module provides instead of the script (or, make the script call the module.... Somehow)

@anaisbetts
Copy link
Contributor

.... What? Why do the U2F part in an Iframe?

Because they're using it to integrate some other company's component - it's not an Electron thing, it's just how many U2F pages work

(or, make the script call the module.... Somehow)

Yeah, so, the thing Electron will implement is a chrome. API that will call into the module

@Georgi87
Copy link

Georgi87 commented Mar 31, 2017

Our team is looking into this issue to allow the use of hardware wallets with electron apps. Please contact me (via gitter) if you are working on this too to evaluate the current state of development.

@darkmastermindz
Copy link

darkmastermindz commented Aug 8, 2017

@georgi8 @woodrow Any progress? Also, would like to join in on this process of implementing U2F.

@ItsShadowCone
Copy link

ItsShadowCone commented Aug 8, 2017

I think there is basically two options.

  1. Implement the U2F api like all the browsers do it
  2. Write a node module which uses the u2f-host c library and exposes the two relevant functions like a polyfill

I would prefer the second as it is less work and considering electron apps often use local paths as url (origin) and U2F is only allowed for https:// origins we might actually want to not check whether the facet(s) match the web origin and either fill in the origin to be the same as the app ID in the sign request or expose it in another function parameter.

@queesamor
Copy link

Pardon my potential ignorance, but if you don't actually "check whether the facet(s) match the web origin", wouldn't you be in effect not implementing U2F? One of the foundational tenants of the U2F protocol is the extremely strong guarantees the protocol makes about the authenticity of the parties involved, and it sounds like you are suggesting a willful concealment of one party's identity.

At face value, if I correctly understand your suggestion, it would utterly defeat the purpose of implementing U2F support if you did not implement it according to the official spec developed by FIDO. As an [informed] end user, I would rather be frustrated that you don't support the internet's new easy/secure auth protocol, rather than discover that you "support" it, but in actuality your support is only partial, and my security is potentially suffering as a result.

If I've misunderstood, please please correct my error. If I have not misunderstood, please recognize my ardent objection to such a route being chosen, and the likelihood that other electron customers would also prefer less "support" over deceptively-flawed "security". :)

@ItsShadowCone
Copy link

ItsShadowCone commented Sep 11, 2017

This is a valid point.

However, I would like to cite a few things.

As long as U2F devices can be accessed directly from user space on the client OS, it is possible for malware to create a keypair using a fake origin and exercise the U2F device. The U2F device will not be able to distinguish 'good' client software from 'bad' client software. On a similar note, it is possible for malware to relay requests from Client machine #1 to a U2F device attached to client machine #2 if the malware is running on both machines. This is conceptually no different from a shared communication channel between the Client machine (in this case #1) and the U2F device (which happens to be on machine #2). It is not in scope to protect against this situation.

Taken from the lastest specification. Please correct me if I'm wrong but afaik electron apps can directly talk to hardware anyway, using node.js modules. (I mean.... Such a library would work by essentially using such a feature).

Plus, the entire document about app id's and facets. Click me

Here unfortunatly the specification is not totally clear. It specifies, that in web cases, the app id MUST be the web origin (which the browser can make sure), for Android it must be the hash of the signing key (which any authenticator app can verify) and on ios the bundle ID (same applies as for android).

A few things however should be considered when dealing with electron.

  1. The electron app has direct access to the user space. That means it can bypass all security precautions we might put in place and access the U2F device directly (unless the system prevents this, which is not supported and not even discussed by any system (afaik. Maybe except ios).
  2. There may not always be a valid web origin. Electron apps do not always have to be served over the internet (I mean, browser pages don't, too, but it doesn't make any sense in this context). Although the RFC also specifies 'file' origins, I know no implementation of the specification (if not the specification itself forbids this. Not sure on this one) that actually allows the usage of file origins. For example, Yubico's site on App Id's states "Web facets must use HTTPS". Besides, should this even be supported, it becomes extremely difficult to manage the facet id's correctly.
  3. Better officially implement it and make sure the informed user knows the implications of installing electron apps inside of their userspace than not implement it because of "only 99% security" and be shocked once the first malicious app makes use of this.

@molekilla
Copy link

I managed to use electron 1.7.6 addExtension with u2f-ref-code extension with a u2f enabled webpage inside an iframe but can't get chrome.runtime.* enabled. I guess if I moved the online to be offline from disk it would work? If that is the case then the final stumbling block will be the appid.

Also, Mozilla has this Rust API https://github.com/jcjones/u2f-hid-rs which could be useful

@ItsShadowCone
Copy link

I've been able to port libu2f-host to node for at least Linux (by statically linking precompiled dependency libs to my native node module)

Works fine but is unfortunately blocking-only and does not support an asynchronous api (yet?)

@ItsShadowCone
Copy link

I have not tried, as I am not developing on windows.
You would need to add the compiled libraries to the third party directory and maybe adapt the gyp bindings. The node dependencies should be updated, apart from that it should work.

@codebytere
Copy link
Member

This feature seems to be something that would be more appropriate for userland, and since it isn't currently on our roadmap, i'm going to go ahead and label this a wontfix. However, should someone determine a workable solution we would be very open to accepting a PR!

@queesamor
Copy link

queesamor commented Sep 23, 2018 via email

@jdgregson
Copy link

Not sure how a project as high profile as Electron can intentionally fail to implement U2F.

@codebytere
Copy link
Member

We may start to look at it, and when we do we'll re-open and label appropriately!

@nornagon
Copy link
Member

Currently this is out of scope because Chromium implements U2F as an extension, and Electron doesn't support extensions. So implementing U2F would mean completely re-implementing it, which is a massive and sensitive project, or supporting the extensions API in Electron, which I don't think makes sense. If Chromium bakes U2F support into something we can re-use, we'll reexamine this decision.

Since U2F is mostly used for signing into things, I'd recommend apps that want to support U2F use an external web browser for their sign-in flow.

@kspearrin
Copy link

kspearrin commented Sep 24, 2018

Chrome 65 has built-in support for WebAuthn (for FIDO2), which is suppose to be backwards compatible with FIDO U2F, so maybe that would work? https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API

More: https://www.yubico.com/2018/08/10-things-youve-been-wondering-about-fido2-webauthn-and-a-passwordless-world/

@dsanders11
Copy link
Member

If Chromium bakes U2F support into something we can re-use, we'll reexamine this decision.

@nornagon, I think this discussion is a bit out of date. Chromium has baked U2F support in, and has for some time. It's part of Web Authentication, which shipped in Chrome 68 (was behind a flag for a long time before that). Electron may get this for free once they upgrade Chromium to 68+.

@nornagon
Copy link
Member

@dsanders11 in #15404 says that webauthn is working in the Electron 4 beta, can anyone test if U2F is working there as part of that?

@dsanders11
Copy link
Member

@nornagon, I just tested at least the registration part of U2F and it is indeed working in the Electron 4 beta using WebAuthn. Open question as to whether it continue to work out of the box, as newer versions of Chromium (71+) are making UI improvements to ask the user permission before continuing, and I believe there's plans to support entering a PIN through Chromium. Not sure how those would fit into Electron.

@kspearrin
Copy link

@dsanders11 Could you point to any docs that show how to use webauthn with U2F? I can only find samples that show it being used for FIDO2.

@sneak
Copy link

sneak commented Oct 31, 2019

https://webauthn.io/

@irisariana
Copy link

Hello! I have the same problem mentioned here with the yubikey but I am a little confused because some comments say that the U2F is working with Electron 4 but this comment #3226 (comment) says that this is not possible right now on Electron.

I have tested with Electron 4 and Electron 7 without success. I am using the electron-oauth-helper library to authenticate my user to a salesforce community using a Gmail account but still I got the error below:

yubikey-error

Maybe I missed something. Any help will be appreciated.

Thank you!

@repentsinner
Copy link

Many thanks @MarshallOfSound! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.