keepassxreboot / keepassxc-browser

KeePassXC Browser Extension
GNU General Public License v3.0
1.76k stars 187 forks source link

TOTP icon missing, and TOTP filling not working with Okta #1378

Closed carestad closed 2 years ago

carestad commented 3 years ago

Username and password filling works fine for Okta logins, but not when using TOTP (their Google Authenticator setup, not Okta Verify).

Expected Behavior

  1. Fill username and password
  2. Get TOTP login, with either TOTP icon showing in the input, or by right-clicking and selecting KeepassXC-Browser > Fill TOTP and TOTP is inserted into input
  3. Login successfully

Current Behavior

  1. Fill username and password
  2. TOTP does not fill, neither by right-clicking input and selecting Fill TOTP, keyboard shortcut, and no icon appears either. Have to open KeePassXC, lookup the entry and copying TOTP manually.

Possible Solution

Fix detection of TOTP input for Okta. The markup for the input is usually

<input type="tel" placeholder="" name="answer" id="input4" value="" aria-label="" autocomplete="off">

Maybe answer could be added to the TOTP icon list? Could it be the autocomplete="off" causing this?

Steps to Reproduce (for bugs)

  1. Set up two Google Authenticator two factor login in Okta and get the TOTP secret from the QR code to use in the KeePassXC entry
  2. Log in to a service via Okta (this might be a company solution so not sure if it can be tested very easily) that requires two factor login
  3. Try and auto-fill the TOTP code in the browser

Debug info

KeePassXC - 2.6.6 KeePassXC-Browser - 1.7.8.1 Operating system: Linux x86_64 Browser: Mozilla Firefox 90.0

varjolintu commented 3 years ago

That's kind of generic input field, so the best we can do is to add a site-specific configuration for Okta.

carestad commented 3 years ago

@varjolintu well that would also work. Any workarounds I could do myself locally though? Setting custom login fields does not work either

varjolintu commented 3 years ago

I'll see if I can find a workaround. If not, I'll make an exception to the next release.

varjolintu commented 3 years ago

Uh oh. Any idea where I can test the Okta login free? If all TOTP's use that same input field but the URL is always different, things are going to get difficult.

carestad commented 3 years ago

@varjolintu There is a free trial signup here, but I think all companies get their own subdomain. :grimacing:

The URL I had when debugging this was https://<my-company>.okta.com/signin/verify/google/token%3Asoftware%3Atotp

varjolintu commented 3 years ago

Well that URL info is already helpful :) Still, coding it blindly without testing is not gonna work. I can do a test fix if it's possible for you to test it?

carestad commented 3 years ago

@varjolintu sure!

mpas97 commented 3 years ago

@varjolintu Why does right-clicking and selecting KeepassXC-Browser > Fill TOTP not just always work? I have a lot of sites where I need to copy paste things manually although I could select the fill option from the input fields context menu.

You should surely be able to detect the calling DOM element of such a click event, so why is there some kind of filter behind? As the user already provides the input field by clicking in it, we should just use it. That's why I think that a more general approach/fix like this could also solve that issue.

varjolintu commented 3 years ago

@varjolintu Why does right-clicking and selecting KeepassXC-Browser > Fill TOTP not just always work? I have a lot of sites where I need to copy paste things manually although I could select the fill option from the input fields context menu.

You should surely be able to detect the calling DOM element of such a click event, so why is there some kind of filter behind? As the user already provides the input field by clicking in it, we should just use it. That's why I think that a more general approach/fix like this could also solve that issue.

This is probably because no input fields were identified earlier -> no credentials are requested from KeePassXC. True, filling TOTP that way should trigger the credential request if those haven't been received yet. Let see if that can be improved.

mpas97 commented 3 years ago

Thanks for having a look. If I remember correctly, after doing these right clicks "fill TOTP" I get asked if I want to forward the credentials. But nevertheless, the field remains empty. So credentials should be known, but the field is still not recognised/filled although the click originates from there.

varjolintu commented 3 years ago

@mpas97 Does this happen with the Okta login or do you have specific site where this can be reproduced every time?

mpas97 commented 3 years ago

@varjolintu I have different sites where this happens every time. But you always have to be a "customer" to get an account there, so they are not really open to the public. An other site where nothing works at all would be https://accounts.firefox.com/. I can not even define custom fields, nor does right click "insert email/password/totp" do something.

Probably not the best example for TOTP (as it uses multiple input fields) but https://app.hackthebox.eu/login also doesn't fill even after manual context menu action. But at least this site is open to the public. To test, I also clicked in the backup code field just below and did the right click fill TOTP. But again although I'm asked for forwarding my credentials, the field is also not filled with my desired content.

As described in my last comments, I just think that the actions from context menu are not bound to the caller element yet as the plugin rather tries to find the correct field on its own (but as the field is not found on page load, it's therefore not found on manual action).

varjolintu commented 3 years ago

@mpas97 Thanks for the info. Firefox login page is an exception, because if you are using Firefox, all content scripts are denied for those pages. Everything works fine if you are using some other browser. No idea why they chose to do such restriction. I'll check the other site.

mpas97 commented 3 years ago

@varjolintu Here some of the sites in action:

https://user-images.githubusercontent.com/9994218/130273557-36cf6b5e-3329-46a9-aa0c-04aaa435fc4a.mov

https://user-images.githubusercontent.com/9994218/130273561-3c073ca3-0057-4a36-9b04-4027b617ebe6.mov

mpas97 commented 3 years ago

Now I did some more tests: Site1 throws these errors:

grafik

And Site2 has apperently a backup code field. Which is hidden but getting filled instead....

https://user-images.githubusercontent.com/9994218/130318338-56233b78-a106-4127-b7fa-3a781d139acc.mov

varjolintu commented 3 years ago

@mpas97 What is that site on the videos?

Fixed the segmented TOTP here: https://github.com/keepassxreboot/keepassxc-browser/pull/1396

mpas97 commented 3 years ago

Thanks for the fix 💪 Again, the sites mentioned are some sort of private, but here I exported the sites as html if you want to test with: sites.zip

You are probably going to add those 2fa fields to an exception list, but again, a more general approach would be to make the context menu fill ANY field we called from with ANY content we want. As keepassxc can always recognize a field as wrong type or not at all, I want to be able to fill username/password/totp into any focused input field. If that would work, we could handle any site (like Okta too) without having to fix / handle all sites manually in the code. I can't understand why keepassxc tells me "no (password) field found" or how it can just fill an other (hidden) field when the action is being called through a specific input field.

varjolintu commented 3 years ago

@mpas97 I agree, and I'm about to improve things a little bit. And a generic solution is of course always the first priority. Exceptions are only for those sites which cannot be fixed like that.

varjolintu commented 2 years ago

@mpas97 For the sites in that zip file. First site has absolutely no indication in the input field that it's a 2FA related. Event the ´maxLength´ is 255 which doesn't make sense. The second site has maxLength set to 6, but there's no other way to see if this is 2FA related or not. Using Custom Login Fields is preferred here.

varjolintu commented 2 years ago

Using Custom Login Fields in the future will probably solve this one, if there's any problems left.