Browser: Add option to look up by top level domain

[developer91234]

This is what all other password fillers do since sites change their login entry-points often. If I have a mail.google.com account, other fillers will fill it on all google sites. Keepass browser will only fill it on mail.google.com (which is no longer used by google or logins). I don't see the use case for looking up by complete domain name.

[varjolintu]

An example: Entry URL https://google.com will fill all subdomains under google.com. Entry URL https://mail.google.com will fill that subdomain plus all other subdomains under mail.google.com.

What are you meaning here exactly?

[developer91234]

The mail.google.com entry should fill everything under google.com

The problem is that other password managers save the subdomain (as does keepassxc by default). But many websites have different login entry points, which moreover change. To get around this issue you have to ignore subdomains in fetching entries, which is the default behavior of most fillers.

[varjolintu]

That's not how the matching works. If you wish to match everything under google.com you must use https://google.com as your entry URL. It works as a wildcard similar to https://*.google.com.

[developer91234]

That's not how it works on Keepass, but it is how it works everywhere else and for a very good reason. I have a bunch of credentials that I saved years ago, and the sites have since changed the entry points. What is the user supposed to do this in this case, write a script to strip away the subdomains?

[droidmonkey]

We are not going to change this behavior because it is in place for very good reasons.

[developer91234]

@droidmonkey Can you explain the use case? Maybe I'll use it myself if it's compelling hehe.

The only one I can think of is a website with say corporate portal and a client portal. Now, 0.1% of the site's userbase might have both 1 user and 1 corporate login. If you look up by top-level domain, you'll get two login candidates for each portal. This means that these users can no longer use autofill, but they can still find their credential. However, users of a site like google, which has ten different places to login from will not be able to use the site at all until they change their domain from some-weird-place.google.com/some-special-url-for-a-login-for-a-login-last-year. to google.com.

Security-wise, I don't see any benefit. If you trust mail.google.com you obviously have to trust google.com as well.

[droidmonkey]

We support multiple urls per entry, so if you want you can define google.com as an additional url and still have the specific site link as the main url. We aren't changing the behavior so you can modify the code yourself if you want.

[developer91234]

I was hoping to hear a plausible use-case for the current behavior, but OK I'll take no for an answer.

[droidmonkey]

The obvious use case is anyone who wants credentials defined for specific subdomains. By going to the higher level domain you nullify that option entirely. This isn't about security, but scoping.

[developer91234]

Yeah that's the use case for a person who logs into different portals on a given domain, but that use case is extremely rare (and is also still more or less satisfied by using domains, by simply using the selection dialog for that very rare occasion). On the other hand, the far more common use-case of someone with a dozens of obsolete or overly-specific urls in their database is not satisfied at all (except through scripting or manual editing).

Password-managers save the login urls only. Login urls change all the time, only the domain is stable. So pretty much every long-time user will eventually get some obsolete/unusable entries in their database and won't be able to login using the URL.

Anyway, that's was the rationale for at least creating an option to look up by domain. I think it's overwhelming. But it's your decision so I won't press the matter further.

[droidmonkey]

I am certainly one of those users that have obsolete urls, I find them all the time. I update them when I find them though. I could see an application setting that is basically the opposite of return best matching credentials.

I'll reopen this with that thought.

[varjolintu]

Yes, an opposite option for a strict matching would be ideal. The default matching should not be changed.

[WhyNotHugo]

This list is very relevant here: https://publicsuffix.org/list/

It's a list of domains where subdomains are considered separate sites (so credentials across them should not be shared).

For example, github.io is listed there, so any subdomains of it should be considered different sites, and passwords for one domain should not be suggested for another.

[dierochade]

May I ask what is the current state of this.

I would like to migrate from keepass on desktop (stay with strongbox on iOS :-) and run version 2.7.7.

When I got a ton of database entries like this: URL: https://secure.booking.com The actual login landing page is: https://account.booking.com/sign-in? →The browser extension is unable to match

I thought this was already addressed in #7988, but no matter if I choose activated or deactivated in group settings/browser integration/"omit www subdomain from matching", I get no match in the above described example. In Application Settings/Browser integration/ i have not checked "Return only best matching credentials"

Am I doing it wrong or is this still a problem when migrating with an existing database?

[droidmonkey]

Simply add https://account.booking.com as an additional url in the entry browser settings.

[dierochade]

This is not that easy cause I have several hundred entries that i would need to edit manually.

[droidmonkey]

You have several hundred entries that have differing subdomains? That seems unlikely. However, your only option is to hop to it and make the updates as of right now.

[dierochade]

I have 1200+ entries, so its just a rough guess. These entries were created with keypass or 1pass. Quite often, the register form and the login form are on different subdomains. In these programms, there was no validation/differentation for subdomains...

So it is not a bad configuration, but just not supported at the moment? Might this have a chance in the future?

I think with passkey support in keepassxc there are quite some people thinking about migration, but as it will not work (apparantly) they could refrain.

In my personal opinion it would be good if there was an option that the programm matches the whole domain at least if there is no match in the subdomain?

Thank you for the instant support btw.

[droidmonkey]

Yes, see my comment above: https://github.com/keepassxreboot/keepassxc/issues/6519#issuecomment-840216037

Passkeys require a new registration so this will not be an issue

[dierochade]

Yeah, as you wrote

"I could see an application setting that is basically the opposite of return best matching credentials. I'll reopen this with that thought.

i wonder if you still think its a possibility and maybe could implement it. There are users that would definitely appreciate this (me for instance : )

It is true that passkeys need a new registration. Thats not what I meant. I have to decide to stick with keepass for now or manually update all entries. It is not an option to do them one by one for me, cause it would be a totally annoying experience for months and moreover my partner would not like to have a new software that does not work just because it has some edge feature (very cool!) and looks nicer (it does!)- instead of the used and working way.

[droidmonkey]

I'm in a feature development mood so I'll look into how easy this would be

[varjolintu]

This option should be quite easy to make now. The latest versions already implemented a method to get the top level domain.