Report websites where Browserpass doesn't work

[max-baz]

Please use this thread to report websites where Browserpass doesn't fully work, e.g. Browserpass is unable to fill username or password, or fills wrong form, or autosubmit doesn't work.

I'm not promising to support every single website, but I will investigate every example and if possible improve the detection logic.

I will not however add special cases for certain websites, I don't want Browserpass become a collection of broken websites on the Internet 🙂

[532910]

Autosubmit doesn't work for: https://esia.gosuslugi.ru/ Discourse sites: https://community.opencellid.org https://community.letsencrypt.org https://forum.f-droid.org

[max-baz]

Discourse sites will unfortunately not work until they improve their markup, sadly they are not very interested in doing so: https://github.com/discourse/discourse/pull/7056

[532910]

https://ticket.coreboot.org/login Filed wrong: login goes into openid url, login field leaved unchanged

[max-baz]

esia.gosuslugi.ru works for me, make sure to test in the latest version 😉

[532910]

I use СНИЛС login

[532910]

version 3.0.3

[max-baz]

I don't have the right credentials so I can't really test a successful login, but I click on СНИЛС, fill it with random credentials and I see the "Войти" button becoming grey, something is refreshing, and then I get "wrong username or password" red error, so as far as I can tell auto-submit actually works? 😕 What do you see exactly? And what browser do you use?

[532910]

firefox 66.0.1-1, debian sid it work for test record with random СНИЛС and password (I see "Введено неверное имя пользователя или пароль") but for my credentials it just doesn't press "Войти" button

[max-baz]

I have the same behavior for random СНИЛС and password, seems like I won't be able to reproduce because I don't have the correct credentials 😞 Injection is a bit annoying to debug, but I'll give it another try a bit later.

By the way, sadly there will be cases when autosubmit only works in Chromium but not in Firefox, because we have now an additional way of submitting forms, but Firefox doesn't support this (yet?): https://github.com/browserpass/browserpass-extension/pull/55

It's still an improvement, because in v2 such forms didn't work in both Firefox and Chromium 🙂

[532910]

can reproduce for random credentials:

% pass gosuslugi.ru    
hftEv*Iv\DrNMiB+&uf<!$sd}NWRlp
user: 123-123-512 35

for is not submitted, no red alert "Введено неверное имя пользователя или пароль"

[max-baz]

ticket.coreboot.org/login Filed wrong: login goes into openid url, login field leaved unchanged

Fixed by #70

[max-baz]

I tried esia.gosuslugi.ru and I can't reproduce the issue, neither in Chromium, nor in Firefox.

My exact steps:

1. Create the following password entry (includes autoSubmit for simpler repro steps):

hftEv*Iv\DrNMiB+&uf<!$sd}NWRlp
user: 123-123-512 35
autoSubmit: yes

2. Load latest Browserpass
3. Open incognito window, navigate to esia.gosuslugi.ru
4. Click СНИЛС
5. Use Browserpass

I do get a red alert about incorrect password.

[532910]

both firefox 66.0.1-1 and chromium 73.0.3683.75-1 with clean profiles are able to submit (get incorrect password error) with fake credentials that I specified, sorry.

but both do not submit my real credentials

[532910]

Looks like I've found it, try this one:

% pass gosuslugi.ru
oe`7\5IIxJ<_Rj2eYmiRs?U_"(+@Z.
user: 134–345–234 65
q: fBp8lbkYP9B82WivrxWM
a: H7wKupXuiwx0MPmhyF2M

[max-baz]

This turned out to be a BEAUTIFUL discovery, a bug in a most unexpected location. Very happy that you gave me precise repro steps! Solved in #87 🙂

[OkanEsen]

pi.hole doesn't seem to work and doesn't return any password. If I remove the prefilled domain and type it manually into the search bar, the extension does seem to find the password.

Screenshots

[max-baz]

This is an interesting case @OkanEsen. The reason for this behavior is because Browserpass is trying to determine where a domain name is in the string Privat/Logins/pi.hole, and it does so by using Tldjs, which knows how to search for a valid real well-known domain. In this case, .hole is not a real TLD, therefore Browserpass fails to detect this particular password entry.

@OkanEsen were the screenshots made on https://pi.hole domain, or on some other domain?

@erayd what do you think about teaching pathToDomain to also take into consideration the current domain from address bar? In other words, if you locally server a website on https://login.pi.hole and you have entries like pi.hole.gpg or login.pi.hole.gpg, they should appear in popup even though .hole is not a known TLD?

The severity is low as there is a simple workaround (hit Backspace, find pi.hole entry manually and use it to login - second time pi.hole password entry will be present in the popup), I'm curious more on your opinion if we should support this scenario or not over-engineer for this edge case.

[OkanEsen]

@OkanEsen were the screenshots made on https://pi.hole domain, or on some other domain?

Yes, that's correct and the default domain for a PiHole installation afaik.

It's not a huge deal breaker for me, though I should mention, that there are other devices in my network, which are using non-standard domains too, such as https://fritz.box etc.

Maybe it does make sense to extend the domain suggestion to non TLDs too, at least for the ones, which are specified inside a password file, such as pi.hole.gpg.

[max-baz]

I think it's also fairly common to host local servers on non-existent domains for local development, so I also tend to vote for doing this, unless anyone can think of any security issues with doing that.

[erayd]

...to also take into consideration the current domain from address bar?

I think this is a good idea. It'll remember after the first use anyway, so it's not a big deal, but I think this will be a useful improvement to the first-use UX.

[lewisdiamond]

newegg.ca doesn't work: Error: TypeError: Cannot read property 'filledFields' of null

[max-baz]

Nice one, will be fixed by https://github.com/browserpass/browserpass-extension/pull/110, thanks for reporting!

[Tycho-S]

Autosubmit doesn't work on my work's Identity Provider (PingID) with the new version. With the old (2.x) it did work. Tested both on Chrome and Firefox, on Mac. Autosubmit is switched on and works on other sites.

It's hard to give a direct link as it's only meant to be called from another site. But if you go to https://spiceportal.se.com you should be redirected to it. You won't be able to get in, but you should be able to see the form.

[mithodin]

https://ebay-kleinanzeigen.de also has Error: TypeError: Cannot read property 'filledFields' of null

[max-baz]

OK I'll prioritize releasing a bugfix release 👍

[max-baz]

3.0.11 is out with the fix for the TypeError above.

[max-baz]

@TychoSchenkeveld I checked the website you posted above, sadly that website is no longer supported unless you can get ahold of its developers and convince them to improve HTML markup.

Currently the "Sign on" button is not even a <button> (let alone [type=submit] as it should be), but is also not identifiable as a login button, it has no ID or class or name that would say something like "login" (title is usually localized, thus we don't take it into account).

The reason it worked in v2 is because back then we also attempted to submit the form itself, however unfortunately this action broke many popular websites like AWS (see https://github.com/browserpass/browserpass-legacy/issues/217#issuecomment-429671923).

I am surprised that auto-submit doesn't work in Chromium though, because v3 is also attempting to trigger and Enter keypress, which does submit the form on AWS for example, but for some reason has no effect on this page. Not sure yet if this is something we can improve, or the website is trying to detect and ignore fake Enter keypresses...

[Tycho-S]

@TychoSchenkeveld I checked the website you posted above, sadly that website is no longer supported unless you can get ahold of its developers and convince them to improve HTML markup.

Thanks, I was afraid of that... I know this site isn't the best. I don't think I can convince them to change it. It's a big identity service, we're not the only ones using it.

The reason it worked in v2 is because back then we also attempted to submit the form itself, however unfortunately this action broke many popular websites like AWS (see browserpass/browserpass-legacy#217 (comment)).

Ah I see, I think this was also why it didn't work with Steam, it would submit there but not actually login. Also with Arstechnica. Didn't test those with v3 yet actually. Thanks for looking into that!

I am surprised that auto-submit doesn't work in Chromium though, because v3 is also attempting to trigger and Enter keypress, which does submit the form on AWS for example, but for some reason has no effect on this page. Not sure yet if this is something we can improve, or the website is trying to detect and ignore fake Enter keypresses...

Ah too bad, I was going to suggest that. I didn't realise you were already trying that. Yes indeed, it's very strange, I already noticed that when I press enter myself it works. It could very well be doing this. Too bad, I use this site a lot. It's supposed to use SSO (Kerberos) tickets but on Mac this doesn't work so it challenges me with logins every time. But you're right, their form leaves a lot to be desired.

[meskes]

ox.credativ.com works nicely on firefox but with chromium it hangs on "Filling login details..."

[max-baz]

This is an interesting example, it is caused by a bug in Chromium, others have stumbled upon it too.

I have found a workaround to circumvent such websites. You might notice that the filling will be a bit slow on this website, it is because the workaround is simply an "abort" call if "Filling login details" hangs for too long, but it's better than nothing.

Will be part of the next release.