Feature request: limit matching to subdomain [not possible]

System

This discussion was created from comments split from: 1Password AutoFill in iOS 12.

[Deleted User]

Great feature but they is room for improvement.
First, it only works with the default keyboard. I have Google Keyboard, and the plugin doesn't show up.
Second, when we have several possibles choices, it only displays the URL and username... but not the title!

See:

How can I select the right one in this configuration?

AGAlumB

@celogeek: It's my understanding that only usernames and passwords are supported by Apple's autofill APIs, but I'd love to either be wrong or see that change in the future. "Titles" and other 1Password-specific fields not being used by something meant for general use makes some sense though, even if for our particular use case it would be nice. :)

Regarding the keyboard, perhaps that's something Google could add support for in the future. But not having anything to do with 3rd party keyboards, I'm not sure that's even an option for them.

[Deleted User]

@brenty it wouldn't be a problem if 1password handle properly subdomains!

I have a.domain, b.domain, c.domain with different passwords per sub domain. But 1password show them all instead of the sub domain I'm on it.

AGAlumB

it wouldn't be a problem if 1password handle properly subdomains!

@celogeek: What do you mean? I'm not having any trouble filling logins on any matching URL.

I have a.domain, b.domain, c.domain with different passwords per sub domain. But 1password show them all instead of the sub domain I'm on it.

Yep. That's intentional. Those are all the same domain, which will only have a single owner. Should 1Password not fill your appleid.apple.com at itunes.apple.com and store.apple.com? Were that the case, a lot more people would be going to iforgot.apple.com due to the confusion.

steve28

Yep. That's intentional. Those are all the same domain, which will only have a single owner. Should 1Password not fill your appleid.apple.com at itunes.apple.com and store.apple.com? Were that the case, a lot more people would be going to iforgot.apple.com due to the confusion.

@brenty, the problem is the there are a lot of cases (me included) where someone works for an organization with many different systems. They ALL end in the same domain: company.com. However, they have to have different passwords, but same username, for these different systems. This has been discussed here several times, and the same argument for both ways is always given.

Does the iOS integration allow 1p to choose the order in which the logins are displayed? If so, perhaps a compromise is the "longest match" could always be the first option?

AGAlumB

@brenty, the problem is the there are a lot of cases (me included) where someone works for an organization with many different systems. They ALL end in the same domain: company.com. However, they have to have different passwords, but same username, for these different systems. This has been discussed here several times, and the same argument for both ways is always given.

@steve28: Oh totally. We're in that camp too. ;) But it isn't the majority use case, and I think it would be shortsighted for us to make 1Password cater only to our situation. Most people are not_IT professionals with that kind of setup, and would find it confusing, frustrating, and downright infuriating if 1Password _didn't offer them logins matching the current domain. Fortunately I think technical folks like us are more than capable of understanding this and selecting the correct login. :)

Does the iOS integration allow 1p to choose the order in which the logins are displayed? If so, perhaps a compromise is the "longest match" could always be the first option?

It may be something we can do in the future. But we haven't even in our own extension so far because on most iOS devices it isn't feasible to show the context for a choice like this. To a user, it just looks like the items are in some nonsensical order, even if they're logically organized by best match. I would like to see us try to do something like this in a future redesign, but we really don't have as much to play with when it comes to the presentation of iOS 12 autofill. But if we can do it in a way that reads well to the user in the future that would be great.

Spaldo

@brenty what about if in the login you had an option (which was off by default) that allowed the selected login to not use sub domains in matching? Or is that a crazy idea

[Deleted User]

Lots of people work in a company. Those companies has most of the time several services on different sub domains.
And those people are not for most of them IT tech.
So they just deal with the current implementation or choose another software that do the job as expected.

I mean they is a really simple way to deal with this situation.
First we try to lookup the best match. If the current sub domain has no match we try the domain above. If not we continue up to the main domain.
This way it works in every situation for anyone !

Ex: my.sub.domain.com
Check: my.sub.domain.com
Check if fail *.sub.domain.com
Check if fail *.domain.com

btaroli

I’ve seen outside examples of this too. 1&1 for example. I have logins stored for different services, such as admin, webmail, etc. but I have to select among different entries because of the domain matching. I even keep getting reminded that their webmail supports OTP, when actually it doesn’t. Their admin pages do, though.

So this sort of most-specific matching would be a nice enhancement.

AGAlumB

Thanks for the feedback, folks! I guess I don't quite understand why this would only be an issue now, since this is how 1Password has worked from the beginning. And indeed, as I mentioned above, the request being discussed here applies to our own use here at 1Password too. The trouble is that's simply not the case for most users, who do need to use their logins across a domain regardless of the subdomain (which, most people won't even know what that is). It's something we'll continue to evaluate, but it's important that we're not changing things for a small number of users at the expense of 1Password being usable by everyone else. :blush:

MrRooni

Hi folks. As Brenty mentioned, thank you for all your feedback. The issue we're running into here is that iOS is matching top-level domains. This means that it's treating a.example.com the same as b.example.com and so on. This is not something 1Password has any control over, we just give the system a collection of usernames and associated domains. From there on out it's up to iOS to display them.

Regardless of our level control, however, I believe this behavior is correct. There are certainly cases where you might have different usernames and passwords for various subdomains, but in this cases you can tap on the 1Password… button to bring up our user interface and see them disambiguated.

evanmoore

I have a password story to share:
In my company, we had situation where our users could use their own personal Active Directory credentials finally to sign into their website, but when they needed to access an external resource within their website they had to login 1 more time to get to this resource using their personal AD account. We called this double login problem. This double login was huge problem for our users, because no one wanted to log in one more time. I didn't see what the big deal was, because now everyone had their own personal credential, but to everyone else it was the end of the world and this was not the solution folks wanted ultimately. Although the solution was to fix the double login issue, which we eventually did a year later (AD claim was null), a work around for the time being was to give these users back their general login that didn't prompt them for credentials again and again. However, this work around would cause another problem, which was people entering their credentials wrong and locking the account thus locking everyone out. Oy vey!

The point of this story... You're never going to hear the end of this request, because we can easily ignore all the QuickType suggestions presented to us and instead open 1Password itself by pressing "1Password..." but folks won't understand this until they investigate. They will look at this like it's a bug, but it's not bug it's by design. The folks participating in this beta are usually technical people, which is why we are noticing this issue and we understand you clearly are aware of this API limitation. I just ask if we can have a toggle to disable QuickType suggestions since Apple does not support custom titles within QuickTime suggestion menu at this time.

Keep up the great work all!

AGAlumB

Definitely something to consider. Ultimately the only thing we have control over is 1Password. But we'll continue to improve that, and all of us beta testing Apple's stuff can offer them feedback on their stuff too. Thanks for your thoughtful comments and kind words! :)

giovannibajo

Hi @brenty, your example about apple.com / developer.apple.com / itunes.apple.com seems wrong because all apple.com properties redirect to idmsa.apple.com when logging in. I think all major ID providers (Microsoft, Yahoo, Apple, etc.) now do the same, with probably the notable exception of Amazon (where the problem is actually even worse than just subdomain matching, because many amazon.tld also accept the same password).

I'm a new 1password user, and It looks like you already have some kind of hardcoded list of special sites, as you offer completions for icloud.com for passwords saved as apple.com (I haven't checked if you also offer amazon.de passwords for amazon.com, that was a major annoyance with my previous password manager).

Since I'm badly hit by the bug reported here (wrong subdomain matching for many company websites), would you be open to evaluate the following change:

• By default, limit matching to subdomain
• Internally hardcode a list of notable exceptions that required subdomain matching like Amazon (where you might also want to hardcode many amazon.tlds as well for your non-US users that regularly switch between amazon.com and amazon.mytld)

I would be surprised if there were more than 10 exceptions (sites that require subdomain matching) in Alexa top 500.

This would solve the problems that I also have where on iOS it requires multiple clicks to find out which is the correct password in the common case where a company runs many different services on different subdomain.

Did you ever evaluate such a change?

AGAlumB

@giovannibajo: This is the sign in page for the appleid.apple.com example:

https://appleid.apple.com/#!&page=signin

You may be right about the others, but appleid.apple.com will by far get the most use among Apple users, so I do think it's relevant. Anyway, if you've got a better example, let me know. Anyway, it's just an example. Amazon is a good one, and nothing to sneeze at. I think you get my point. :) This isn't a bug. It's working as intended, for the reasons discussed above. And, ultimately, it's not something we have control over anyway, as iOS Password Autofill is an OS feature, not a 1Password feature. I'm glad it works this way though since that helps the vast majority of users, even if it means I sometimes have to take a second to select the correct *.agilebits.com or *.1password.com login credentials. :)

giovannibajo

The page you linked contains a form that is an iframe to imdsa.apple.com. To the best of my understanding, all logins to AppleIDs now go through idmsa.apple.com, and most of them through redirects. So again, limiting to idmsa.apple.com should work (though I'm not sure what is your policy wrt iframes).

But again: even if it wasn't true (like Amazon), my proposal above is to consider this an exception, and only complete subdomains for a handful of websites where the single sign-on system doesn't redirect to a central login server. Even if they are as popular as Apple and Amazon, it should be a very short list of exceptions. In fact, you already have an exception for Amazon, as you correctly suggest logins for amazon.* (I guess with a closed list of TLDs).

AGAlumB

@giovannibajo: I should have mentioned that myself, so I'm glad you brought it up. Think of it this way: if matching/filling worked the way that you're suggesting, it would silently fail when trying to fill into an iframe from idmsa.apple.com with the page being from appleid.apple.com. I think we can agree that would be an awful user experience for pretty much anyone. :)

I get your point about making exceptions for specific domains (to have subdomains treated as different sites), but not only does that not scale well, it's not a decision for us to make. That's already being done by Mozilla, and we use it in 1Password:

https://publicsuffix.org/

We already see a lot of confusion from users (and, frankly, for us, trying to understand the issue they're having) in cases where governments have explicitly requested to have domains added to the list to be treated the way you're suggesting. A recent example was someone who couldn't figure out why their something.gov.uk login wasn't offered at somethingelse.gov.uk. Another was some Australian municipality which I forget. The answer, of course, is that this is how the governments want these to be handled -- as separate websites. Companies do this too. Just look at the list. You can certainly request that your own domain(s) be added too. But I don't think it makes sense for us to start making decisions about public suffixes unilaterally, even if we could (which is not the case with iOS Password Autofill anyway), as that would cause much more trouble for users compared to just needing to select the correct login credentials when you have too many.

Also, what you're talking about with the Amazon example is completely different from matching all logins for the same domain -- e.g. *.apple.com. In our own software, we use equivalent domains for different domains which are, well...well-known to be equivalent: apple.com and icloud.com; amazon.com and amazon.uk -- they are literally the same company using the same accounts, just offering different services to the user. Treating subdomains as domains is very different, has repercussions for all users, and there's a standard process in place for cases where that needs to be done. We'd make the same call if it were up to us, but in this context it's very much outside the scope of 1Password.

steve28

I hope I can bring this up again... Lately I've stumbled upon Bitwarden, which is an open source password manager. I believe it's a one-person shop, and for that it's very impressive. However, along the lines of the topic of this thread.

Bitwarden very elegantly handles the domain matching problem, by letting you select per-entry how to match the domain. You get the choice of:

• Base Domain (1p method *.domain.com are all the same)
• Host (matches full domain - including port!)
• Starts With
• Regular Expression
• Exact
• Never

Like so:

Please, STEAL THIS IDEA and give us "edge cases" a choice! You don't have to change anything about default behavior, but let us have a choice.

StemenDrew

I've come across this thread after quite a bit of searching for a solution to this problem, and reading other discussions on this support forum. Answers from 1Password Team Members here (and in other discussions) have made me extremely frustrated with 1Password. So much so that after years of using 1Password and recommending it to others, I'm starting to regret that decision... and I don't even know if competition handles this any better. I know that your ability to change the behavior of iOS's suggestions is out of your control. And yes, I know that's the forum where this thread is taking place; nonetheless this discussion has expanded to include subdomain and multi-domain authentication generally.

I'm a fan of 1Password's functionality that lets you list multiple URLs on a single entry. That goes a long way toward mitigating the need for having different entries where the credential is the same but the domain is different.

The big problems I have with 1Password are 1) it's frustrating to have to select the correct subdomain's credential (when you have many different credentials associated with subdomains on a common root domain), and 2) Watchtower is nearly useless to me because of the quantity of entries I have that necessarily require the same password. The first problem could be solved by implementing a matching option like the above example of Bitwarden, or even something as simple as a check box for "require exact match" or "require subdomain", or something like that, on each relevant entry. The second problem would be significantly more complex to resolve, in my opinion; in order to do it properly, I'd want some way to associate multiple entries together so that 1Password is aware that they must always share the same password. Sorta like the existing "Related Items" functionality, but with an additional indication that the password [may|must] be identical without triggering Watchtower duplicate-detection rules.

Regarding we who use multiple subdomains being an edge case: I strongly disagree. I have family members who I can't get to use 1Password for this exact reason (they encounter the situation with employer websites)... and they do not work for an employer that even remotely resembles a tech company (healthcare, manufacturing, etc). While many seem to dismiss this as a "techie" problem, I've seen little evidence that it's true.

This URL matching problem is a common scenario with public libraries -- from the patron perspective, not just staff. For example:

• Overdrive uses URL formats of ((library or consortium).overdrive.com/[library or consortium-member]), which each require different credentials from [www.]overdrive.com itself
• Freegal Music does the same, with ((library or consortium).freegalmusic.com)
• Freading does the same, with ((library or consortium).freading.com)
• RBDigital uses either subdomain or URL path: (https://www.rbdigital.com/(library or consortium)/*) or (https://(library or consortium).rbdigital.com)
• CloudLibrary seems to use only URL path: (https://ebook.yourcloudlibrary.com/library/(library or consortium)/*
• Polaris (when implemented in a consortium) doesn't use subdomains, but does use exact URL parameters, i.e. (https://(catalog-fqdn)/polaris/logon.aspx?ctx=(library instance number))
• Sirsi services is similar to Overdrive: (https://(library or consortium).ent.sirsi.net/client/en_US/(library or consortium-member)/)
• Bibliocommons uses subdomains: (https://(library or consortium).bibliocommons.com)

Finally, I disagree whole-heartedly with with brenty's representation of Mozilla's public suffix project, and assertion that it isn't 1Password's place to implement something capable of distinguishing subdomains having a common parent (or equivalence across multiple domains). None of the above library examples would be suitable for inclusion in the public suffix list, because they were not ever public suffixes: they're private. Even when we change our context to the government, which comprises substantial parts of the public suffix list, it's extremely common for there to be authentication-unique subdomains at two levels below the declared public suffix. For example, "oh.us" is a public suffix, but each site at ((site).(branch).state.oh.us) may be (likely is) distinct and unrelated. "state.oh.us" would not be listed as a public suffix because there was never general registration beneath it, much less "(branch).state.oh.us".

Regarding equivalence across multiple domains: while yes, it would take work and doesn't necessarily scale very well, LastPass does this exact thing via their "Equivalent Domains" functionality: they publish a global list of domains that they've verified are authentication-equivalent (such as Amazon's various domains), and allow end-users (or enterprise admins) to add their own equivalency rules (or disable some or all of the provided list). Implementing similar functionality (even if only the ability for end users to add rules) would help some of we "edge case users" substantially.

Yannoehl

+1 on this issue. And to be clear, this isn’t specifically an iOS issue. This is a cross platform improvement addressing how 1Password chooses which password to display given the domain name.

Please pay attention to your customers, here.

ag_ana

Thank you all for taking the time to share your thoughts about this :+1: All feedback is always very welcome, and it's great that you are so passionate about 1Password to help us improve it with your suggestions. As usual, we will keep all of your feedback in mind when moving forward.

davidmirv

This is a major breaking feature of 1password. We need the ability at the entry level to set the matching on it.
use case for me is we have a company intranet with dozens of subdomains and I get ALL the suggestions based on the TLD, completely useless. I could care less if this functionality was enabled on mobile but on Browser its necessary

ag_kevin

Thanks for providing your use case davidmirv, We'll keep that in mind when planning new features.

Cheers!

WayneM

Adding my comment here to support the request. In my case, I have about a dozen subdomains for a domain I manage that all have unique usernames and passwords. Each has a separate entry in 1Password with the full subdomain. With 1Password I have to scroll through the list each time. As steve28 noted above, Bitwarden offers a solution to this that works well.

ag_ana

Thank you for sharing your use case with us @WayneM, that is useful :+1:

Unknown

This content has been removed.

ag_ana

Thank you for chiming in on this as well @JamesHenderson :+1:

tuck182

This is the biggest pain point I've seen so far in my migration from Dashlane. There's a per-password/login setting in that product "For this subdomain only" that defaults to off. It would allow per-subdomain passwords but not break the common case for those "I don't understand how subdomains work" users that brenty is concerned about.

Ben

Hey @tuck182

Thanks for sharing that with us. At the moment the best I could suggest would be to tap on the '1Password' option at the bottom of the Password AutoFill UI, where you'll be able to better identify your items. If you'd like for this to be the default action when opening Password AutoFill you can disable this option in 1Password > Settings > Password AutoFill:

Not quite the same as matching based on subdomain, but should help in identifying the desired item. I hope that helps!

Ben