-
Notifications
You must be signed in to change notification settings - Fork 15.1k
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
Comments
👍 if it's not Crazy Difficult |
+1 |
I looked into this, it is actually Crazy Difficult, their extension is like, walking the USB HID tree polling for descriptors and shit. |
@paulcbetts Sorry to hear. Thanks for taking a look. |
@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? |
@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! |
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) |
Here is the Google u2f reference code, https://github.com/google/u2f-ref-code what do you think? |
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 |
Now that we're implementing a ton of Chrome extension APIs for DevTools, maybe this is more tenable |
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. |
Is there any update on the status/plans for this? Would very much love to have U2F in Electron. |
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? |
@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. |
.... 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) |
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
Yeah, so, the thing Electron will implement is a |
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. |
I think there is basically two options.
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. |
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". :) |
This is a valid point. However, I would like to cite a few things.
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.
|
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 |
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?) |
I have not tried, as I am not developing on windows. |
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 |
:'(
On Sun, Sep 23, 2018, 9:17 PM Shelley Vohr ***@***.***> wrote:
Closed #3226 <#3226>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3226 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEZw-p1DJi7iMk4AjiRwwkU2NFp6awPfks5ud9A0gaJpZM4GWA1v>
.
--
…-Denver Root
|
Not sure how a project as high profile as Electron can intentionally fail to implement U2F. |
We may start to look at it, and when we do we'll re-open and label appropriately! |
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. |
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 |
@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+. |
@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? |
@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. |
@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. |
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: Maybe I missed something. Any help will be appreciated. Thank you! |
Many thanks @MarshallOfSound! 🎉 |
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:
Expected behavior: In Chrome/Chromium you're prompted to insert and touch your U2F device. No extension is required as of Chrome 41.
The text was updated successfully, but these errors were encountered: