Issues with 1Password extension and sites using Yubikey.

jszakmeister

I took advantage of Yubico and GitHub's special offer and got a Yubikey (https://www.yubico.com/why-yubico/for-individuals/github/). So the first thing I wanted to do was test it out at their demo site (https://demo.yubico.com/u2f?tab=register). Well, it didn't go very well. After a fair amount of debugging, I ended up discovering that the 1Password Extension's dialog to save the password was interfering with site's ability to communicate to my Yubikey. In order to make it work, I had to disable the 1Password extension and complete the registration process that way. Needless to say, it wasn't a good user experience.

Is there any chance the 1Password extension can be made to not interfere with this process but still offer to save the password? In this case, I was dismissing the dialog without saving since it's a demo site. I don't know if that makes a difference.

-John

---

1Password Version: 5.3.2
Extension Version: 4.4.3.90
OS Version: OSX 10.10 and 10.11
Sync Type: Not Provided
Referrer: forum-search:yubikey

AGAlumB

After a fair amount of debugging, I ended up discovering that the 1Password Extension's dialog to save the password was interfering with site's ability to communicate to my Yubikey.

@jszakmeister: It sounds like you have a good understanding of what the problem is. Would you mind sharing the details? 1Password can't actually interfere with other processes; and of course, that's why we use extensions to integrate with the browser.

Unfortunately without some additional information it's hard to say what might be going wrong and how we might right it! Please tell me the browser version you're using, the exact steps you're taking, and what is (or is not) happening the way you expect so we can test this to see if there's something we can do to help. It may be as simple as disabling Autosubmit for the login item.

The more information you can give, the better. Thanks in advance! :)

jszakmeister

@brenty: I'm not sure that I really understand the problem--just the symptoms and what makes it go away.

If you have a U2F Yubikey, you can go to this site and register against it (to test that the key works correctly). Right now, U2F support is only available in Chrome (hopefully Firefox will get it at some point soon). The issue is that when you register, the site wants you to authenticate with your Yubikey and gives you some directions:

What I expect to happen is that the U2F key starts blinking, I touch the button, and the site sees that I've done what I'm supposed to and moves on to a successful registration screen. What actually happens is that the device never starts blinking, so I cannot continue the registration steps successfully, even if I dismiss the 1Password dialog.

However, if I disable the 1Password extension then the browser is able to talk to my U2F device, I touch the button, and the registration succeeds.

So the simple steps to reproduce, is to:

1) Grab yourself a U2F Yubikey. I'm using this one, but I believe the FIDO U2F Security Key will work the same (I think the one I have is branded with GitHub's logo).
2) Go to: https://demo.yubico.com/start/u2f/securitykey?tab=register
3) Attempt to register with 1Password enabled
4) See that the key fails to blink and accept authentication

To see it work:
1) Disable the 1Password extension.
2) Go to: https://demo.yubico.com/start/u2f/securitykey?tab=register
3) Attempt to register with 1Password disabled
4) See the success

That's really all the information I have. I hope it's enough to help track down the issue!

-John

littlebobbytables

Greetings @jszakmeister,

Could you try something for us please. Instead of having to disable the extension entirely what happens if you instead instruct 1Password to ignore this domain when it comes to asking to save new Logins. There are two ways to do this.

1. Launch 1Password and open 1Password's preferences. Switch to the Browser tab and enter the domain into the field at the bottom where it says (except on the following domains).
2. When the 1Password Save Login window pops up in your browser click on the cog in the bottom left hand corner and select the option titled Never Autosave for this site

Does that help or do you have to disable the extension entirely for it to work?

jszakmeister

If I use option 1, registration completes successfully the first time through. If I use option 2, I have to go back and try registering again, but it works the second time around. So it's not merely the presence of the extension, the extension has to interact to cause the problem.

littlebobbytables

Hi @jszakmeister,

So while it might not seem great, you will only have to populate the list once for each site. This is pretty much how the exemption list is designed to work so hopefully it seems like a reasonable approach :smile:

jszakmeister

So I refrained from commenting about it being a bad user experience because I thought we were heading down a debugging path, not a "here's what you can do for this site" solution. Yes, I can exempt the site, but I don't want to. I want 1Password to help manage my password, and making the site exempt defeats the entire purpose of using 1Password, which I don't appreciate. The idea here is it's supposed to be 2-factor authentication: the token and the password. I knew how I could workaround the problem already, but it kind of stinks for less sophisticated users.

AGAlumB

@jszakmeister: Understood. It certainly doesn't sound pleasant. But unless I am misunderstanding, the "problem" is that 1Password is doing its job and offering to save a login when encountering the U2F response. Since it's seeing a password it hasn't seen before, it's believing it to be new — and rightly so. 1Password is doing what it's designed to do, and the only difference here is that you don't want it to behave this way in this particular case; you want it to treat this login form differently.

Now, it may be that we can find some way to work around this in the future, but that seems like a rather difficult — if not impossible — problem to solve. But as it stands, 1Password has three states when it comes to a login form: it either 1 doesn't have the credentials saved and therefore offers to do so, 2 has the credentials saved already and doesn't need to save them, or 3 it doest bother to check because the site has been excluded.

I'm not sure it's reasonable to have a fourth state for this one case (and frankly I'm not even sure what that would be), but it's certainly something we can consider as we continue to develop 1Password going forward. If you have any suggestions on how we might improve this, please let us know! :)

jszakmeister

No, I want it to continue to prompt. The issue is that the prompting somehow interferes with the U2F authentication sequence to the security device. That's the bug.

AGAlumB

@jszakmeister: Unless I'm mistaken, this isn't a bug; 1Password is doing what it's designed to do and so is the YubiKey.

From what I can tell, the YubiKey U2F device is sending the code via USB using keyboard emulation when you press the button. To the computer, this is no different than you typing a text string; and therefore 1Password also sees this and offers to save it as a login for the site. I'm probably just doing a terrible job of explaining this. But ultimately there isn't a way for 1Password to differentiate between your actual keyboard and any other USB keyboard device. After all, that's the whole point — and the genius — of the YubiKey design: it will work anywhere you can plug in a keyboard. ;)

jszakmeister

I'm not sure it's entirely true that the U2F key is acting as keyboard--I know it's true of the other keys, but it appears to be more blurred with the U2F key. From a USB-perspective, it certainly doesn't describe itself as a keyboard, but it is a human-interface device, and the report descriptor seems to allow for a full range of input, so it is possible.

I still think there is some confusion. I don't get the opportunity to press the button. Here's the registration flow:

1) Enter name and proposed password and submit
2) Press the blinking light on the U2F device. It does not light up until the correct sequence has happened browser-side.
3) Once you've pressed the button while it's blinking, you move to the registration success screen.

The process fails for me between steps 1 and 2. I never see the device blink, so I never press the button, and I presume it's got something to do with 1Password bringing up the dialog. I've tried going through the motions, but it seems like the initial transaction the browser was trying to do with the U2F device is simply lost when the 1Password dialog comes up.

I hope that clears up where things are failing, and why I think 1Password may play a role. It's not simply that I don't understand. :-)

Now, there are a few arguments that could be made here:

1) 1Password is interfering with the U2F interaction somehow.
2) It's the browser's fault. It implements support for U2F devices and it's not letting plugins work correctly in the presence of said device.
3) Yubicom took the wrong approach, and having the key interact this way is a poor design.

I'm starting with 1), but it you could view as any of them. I love 1Password and I'd like to take advantage of U2F without working around issues--that doesn't make for good stories to tell friends that I try to convince to use 1Password... something I do quite frequently. So it seemed like the place to start, especially since that's where things start to fail.

I hope that makes sense, and I hope I'm not coming across as a crazed user. :-) I just want to see things work together, because I want my password managed by 1Password, and it'd be nice to use the U2F in conjunction with 1Password on sites that allow it.

Thanks for your patience!

-John

AGAlumB

I'm not sure it's entirely true that the U2F key is acting as keyboard--I know it's true of the other keys, but it appears to be more blurred with the U2F key. From a USB-perspective, it certainly doesn't describe itself as a keyboard, but it is a human-interface device, and the report descriptor seems to allow for a full range of input, so it is possible.

@jszakmeister: It is definitely a bit confusing, but the HID (Human Interface Device) specification covers pretty much any kind of input — mouse, keyboard, accessibility devices. The U2F is, in relation to the USB connection to the computer, no different than earlier devices. However, where it does differ is in its ability to accept input as well, and the built-in logic to support the challenge/response. Earlier Yubikeys simply spit out a code when you pressed the button.

I still think there is some confusion. I don't get the opportunity to press the button. [...] 2) Press the blinking light on the U2F device. It does not light up until the correct sequence has happened browser-side.

While not a mechanical button, you're still activating it when you touch it (capacitive?)

I hope that makes sense, and I hope I'm not coming across as a crazed user. :-) I just want to see things work together, because I want my password managed by 1Password, and it'd be nice to use the U2F in conjunction with 1Password on sites that allow it.

Hey, no problem. You're my kind of crazed! We always appreciate feedback from passionate users. I only wish I had a better answer for you. But right now the best thing to do would be disable autosave for sites where you're encountering this issue, after you've first saved the login.

Ultimately something like this which requires special handling for a limited case like this is not going to be a high priority when we need to be improving 1Password overall for everyone's benefit. But we'll certainly see if there's something we can do to help with this in the future. :)

jszakmeister

@jszakmeister: It is definitely a bit confusing, but the HID (Human Interface Device) specification covers pretty much any kind of input — mouse, keyboard, accessibility devices. The U2F is, in relation to the USB connection to the computer, no different than earlier devices. However, where it does differ is in its ability to accept input as well, and the built-in logic to support the challenge/response. Earlier Yubikeys simply spit out a code when you pressed the button.

I'm extremely familiar with USB--I've implemented several USB related products and devices. :-) It does cover any kind of input, but my point was that it's not being flagged as a keyboard--the keyboard protocol is not implemented on this device. Either way, it's beside the point because...

While not a mechanical button, you're still activating it when you touch it (capacitive?)

Correct, but I'm never getting to the step where I get to touch the button! :-) I don't know how to explain this any better. The browser is supposed to talk to the key, the key is supposed to blink, then I touch the button. I never get to do that because the key never blinks. It appears to never blink because the 1Password extension is interfering somehow with that initial communication to the key. How does being a keyboard affect that? I can understand the dialog accepting input from a "keyboard," but it's interfering with communications to the "keyboard."

I can understand if I was pushing the button and it emitted something, but that's not the case. The path being interfered here is from the browser to the key--not the key to the browser.

Ultimately something like this which requires special handling for a limited case like this is not going to be a high priority when we need to be improving 1Password overall for everyone's benefit. But we'll certainly see if there's something we can do to help with this in the future. :)

Thank you, but it's not all that comforting. That's pretty much the response I get from every software developer I purchase software from. I'm a power user and no one uses the software the way I do. So I'm permanently stuck in a state of work-arounds. :-/

I'm gonna let this die because I just don't have the energy to keep at it, and we're going in circles. I do appreciate AgileBits quick responses and thoughtful replies.

jxpx777

I don't have a YubiKey, so I can't test this fully just now. But, I can describe the autosave flow for you to see if it helps point things in the right direction. In order to detect autosave, 1Password attaches some Javascript event listeners to the page and checks things out when they fire to determine if a form was submitted and some basic logic about whether we should try to save it. These checks are pretty quick (checking things like what kind of element triggered the event, what kind of event it was, how many password fields are on the page… that kind of thing), and most importantly, in its current state, 1Password doesn't do anything except monitor events; we don't preventDefault() or anything like that to alter the function of the page.

Once it determines that it should proceed with saving, it sends the autosave message over to the 1Password mini (Mac) or helper (Windows) process for further processing. At this point, the browser extension is out of the mix and the UI you see is native UI from the 1Password app itself. It does take focus from the browser, though, so perhaps this is the issue? I'm not sure what kind of signaling the browser needs to do to trigger the YubiKey, but it could be checking that it is still the active app or any number of other things that might be thwarted if it isn't the active app.

Edit: (11:01 AM) I just noticed that 1Password is locked in the screenshot you provided initially. If 1Password is unlocked at this time is the behavior any different? It could be that the system's secure input is blocking the YubiKey's functionality at that point.

I hope this information is helpful for tracking down the problem you're seeing. If there's something 1Password can do to make this better, we'll certainly try to do that but at this point I can't see any obvious action we can take.

jszakmeister

[snip the great details... thank you]

Edit: (11:01 AM) I just noticed that 1Password is locked in the screenshot you provided initially. If 1Password is unlocked at this time is the behavior any different? It could be that the system's secure input is blocking the YubiKey's functionality at that point.

I tried with it unlocked as well (and just tried again to be sure I was remembering correctly), and it still has the same problem.

FWIW, I did contact Yubico's tech support and they said:

Hello John -

Thank you for contacting Yubico Support. It's certainly worth reporting a bug to 1Password. I just set up a free trial and confirmed the behavior you're seeing (if you select never remember for this site, abort the U2F operation, and then try again, the U2F registration process works). Pop-ups that require feedback can interfere with the U2F process, although most of us use LastPass, and it doesn't interrupt the process.

Best Regards,
Chris
Yubico Support

So it seems like it's possible to achieve.

-John

AGAlumB

@jxpx777: Nice hat! :pirate:

@jszakmeister: We'll look into this further, but the primary concern is that this doesn't seem to be an issue anywhere else. 1Password is just doing what it's paid to do (offer to save a login when certain criteria are met).

Look at it this way, the other 99.99∞% of the time, this is exactly what we all want it to do. In fact, in cases where 1Password isn't able to detect the login form to offer to save the login, it's a pain (and kind of a big deal). So we go to a lot of trouble to make sure that autosave works in the first place. I guess that's why it seems reasonable to simply disable it in the instance(s) where you don't want autosave.

It may be that there's a way to work around this, to effectively have 1Password auto-disable autosave under certain circumstances, but we have to be careful about this to ensure it doesn't affect other cases where we absolutely want autosave to work. Thanks again for bringing this up. It may help us improve 1Password in the future! :chuffed:

jszakmeister

Look at it this way, the other 99.99∞% of the time, this is exactly what we all want it to do. In fact, in cases where 1Password isn't able to detect the login form to offer to save the login, it's a pain (and kind of a big deal). So we go to a lot of trouble to make sure that autosave works in the first place.

@brenty: Exactly: I don't want to disable/auto-disable anything. My hope is that the save dialog and the interaction with the key can be preserved somehow.

I guess that's why it seems reasonable to simply disable it in the instance(s) where you don't want autosave.

I think things got off on the wrong foot: I was never looking for a way to take 1Password out of the loop. I merely tracked down the issue to 1Password's interaction, and disabling the extension was my way of showing that I debugged it to that level. My hope from the beginning was that there would be some way of making the two play nicely together so that 1Password's autosave would still work for the site, and that the extra U2F authentication could work successfully as well.

littlebobbytables

Greetings @jszakmeister,

I want to apologise for my part in the confusion. I was erroneously working on the assumption that the 1Password Save Login was popping up where it wasn't needed which also resulted in this blocking behaviour that you're witnessing. This is why I thought excluding the individual sites would be desirable. It's why I exclude my bank, their approach cannot be handled by 1Password so I tell 1Password not to bother me about the site.

We'll have to wait and see what jxpx777 manages to discern.

jszakmeister

@littlebobbytables Thank you! I hope there's a good fix that can be made!

AGAlumB

Likewise! Thanks again for your patience, and persistence in helping us better understand the issue. :blush: