Wildcard support in website field?

topherfangio

Hey there! LOVE 1Password and it saves me TONS of time every single day!

One thing that would be great that I haven't gotten working yet is the ability to use a wildcard (or maybe a Regex) inside the Website field so that 1Password knows how to match a range of sites.

I know that I can have multiple sites per login, and that works great for things like my Google account which lets me login to Mail/Calendar/Etc.

However, as a developer, we have our code automatically pushed to staging apps with a different URL for every single Pull Request that we build. So it looks like https://mywebsite-pr-3348.herokuapp.com/users/sign_in and the number (3348) is different every time and will just continue to increase/change as we release new code.

It would be awesome if I could add a Website field like https://mywebsite-pr-*.herokuapp.com/users/sign_in and have it work. I have tried this, but it doesn't seem to work.

Is there currently any way to accomplish this?

Thanks again!

---

1Password Version: 6.8.BETA-4
Extension Version: Chrome 4.6.6.90
OS Version: OS X 10.12.6 Beta
Sync Type: 1Password Teams
Referrer: forum-search:website field

jxpx777

Hey, @topherfangio. Thanks for your post. We've discussed this a bit recently. The main reason that we can't do wildcard matching right now is because of how 1Password stores and matches your Logins' URLs. Rather than storing the URLs unencrypted (like the old AgileKeychain format) or decrypting every item's overview every time you want to fill (very slow, especially on older machines) we store a hash of the full hostname and the root domain. So, when you store discussions.agilebits.com in a 1Password Login, we store a hash of discussions.agilebits.com and a hash of agilebits.com. Then, if 1Password is locked, we can quickly locate matching websites for the current page in your browser by computing the same hashes.

With regard to the herokuapp.com domain specifically, we talked about this a bit back in January There was no small amount of confusion about why this was behaving this way even within our own team. :smile: So, when I said "root domain" above, this would be mywebsite-pr-3348.herokuapp.com in your example because herokuapp.com is considered a suffix.

Specifically regarding regular expressions, this is not something we're going to do because of the security and phishing concerns associated with it. We discussed this a bit in this thread as well.

I hope this helps explain the situation. Let us know if you have any other questions.

--
Jamie Phelps
Code Wrangler @ AgileBits
Fort Worth, Texas

topherfangio

Hey Jamie,

Thanks for the in-depth post! It really helps me to understand the situation a bit better!

Curious thought: what if this was a feature of the Chrome extension (and others I guess) where you could essentially put in a mapping before it hits 1Password? For instance, if we had an area in the extension settings to say something like

https://mywebsite-pr-[0-9]+.herokuapp.com/users/sign_in
maps to
https://mywebsite-pr-*.herokuapp.com/users/sign_in

Then in 1Password we add https://mywebsite-pr-*.herokuapp.com/users/sign_in as a Website to an existing login? Then, the user would have control over this at the browser level so that 1Password doesn't have to do anything funky.

Just a thought :smile:

jxpx777

One thing is that 1Password's extension doesn't actually have any user interface and adding this kind of thing in would require adding a considerable amount of complexity to the extension. The other is that processing URLs with regular expressions is so prone to error that we simply do not want to go (back) down that route. It is an actual security risk for phishing. We used to process URLs with regular expressions, but we stopped doing this months ago because of this kind of concern.

If there were a facility for the user to provide their own mapping, the additional question is where 1Password would store this information. We wouldn't want this to be accessible to other processes such that a bad actor could edit the file to make a phishing attack more realistic. Safari has secure settings, but the rest of the extensions frameworks only have an unencrypted storage area for settings. So that would be another concern to address.

In the future, perhaps we may explore some more advanced options, but for now, this isn't something we want to take on.

topherfangio

Ok, yeah, that totally makes sense. Seems a bit odd that the extensions don't have a secure storage location.

Anyway, I appreciate the quick responses!

jxpx777

:+1:

Thom Brooks

Hear, hear. Any luck getting an answer?

AGAlumB

@Thom Brooks: Maybe. What was your question? :)

Thom Brooks

Sorry about that - something in Safari was blocking the forum responses, so I could only see the original question. (Which also explains why I posted my comment twice, since I didn't see it appear.)

While I still wish that it were possible to tell 1Password "this is the password for all sites matching this wildcard" - I saw an exchange on Twitter with a guy who had 300 printers - for now I'm just clicking on the gear in the popup that offers to save the password and saying "never save this item" once per host. I've created a generic entry that represents all of the devices with matching credentials (and IP scheme) and refer to it when I need to.

Here's a different approach: What about the ability to add multiple URLs to one item (so it would generate one hash per URL, and check against them all), and allow folks in our situation to bulk add them? (Hmm, I see that it's letting me add a ton of addresses to the entry, but I'm not able to log into a machine to test this until tomorrow. If this works to match any of these URLs and submit the same password, that is great news. The question would be, how quickly I could generate the same pattern, increment the one number in the IP address, and plug all of those into the Website 1 ... [n] fields.

Thanks! Sorry for the spammy comments above, feel free to delete those.

AGAlumB

@Thom Brooks: No worries! I just figured I was missing something. I appreciate you thoughts on this! The 1Password desktop apps do support multiple URLs — though I can't say what the upper limit is on that: I think a dozen or so is the most I have. As Jamie mentioned above wildcards are a technical challenge, but it's something we will keep in mind as we continue to develop future versions. Thanks for the feedback on this! :)

butakimchee

Hi Team,

Wanted to share my thoughts on this as well from a cross-platform perspective:

Consumer Whitelists

I saved a login for Netflix on my desktop, but when filling it via mobile app, 1Pass notices the AutoFill attempt doesn't match the URL I saved, and challenges the user about this. Fair enough. First I though we could solve by adding *.netflix.com but apparently this is a feature gap 1password has, which is insane in a cloud-app world where every server's FQDN is myapp-lj34h6lk2jh.domain.com . If we could whitelist what popular websites (youtube, netflix, apple) iOS/Android authentication urls are, we could auto-add them via App. I wouldn't relish the job of white listing and nor I suppose 1Pass team would either, but it could be community generated and an option to bulk import.

The obvious alternative to this is to store plain text URLs / or allow the user to CHOOSE SLOW Search/Fill Speed

If the URL and root domain are hashed and that is new compared to the plaintext storing of URLs in older app versions, why not bring that "feature" back as an option for users who want a bit less security (25%?) but the convenience of wild card domain mapping?

Seriously the lack of wild card domain or subnet matching is one of the most annoying things about this password manager. I have to to be asked "REMEMBER" a cred I use on hundreds of systems on my network?

AGAlumB

I saved a login for Netflix on my desktop, but when filling it via mobile app, 1Pass notices the AutoFill attempt doesn't match the URL I saved, and challenges the user about this. Fair enough. First I though we could solve by adding *.netflix.com but apparently this is a feature gap 1password has, which is insane in a cloud-app world where every server's FQDN is myapp-lj34h6lk2jh.domain.com .

@butakimchee: I'm not sure I get where you're coming from here. While the explicit * wildcard is not supported, setting the URL as https://netflix.com will allow it to work at https://www.netflix.com or https://asdf.netflix.com or whatever, the same way the thing you're asking for would. Or, using your example, a login saved for myapp-lj34h6lk2jh.domain.com would also work at domain.com or www.domain.com. I'm not sure how a "wildcard" would help with that.

If we could whitelist what popular websites (youtube, netflix, apple) iOS/Android authentication urls are, we could auto-add them via App. I wouldn't relish the job of white listing and nor I suppose 1Pass team would either, but it could be community generated and an option to bulk import.

This doesn't make any sense to me. YouTube and Netflix are, as far as I can tell, using a common login portal for all of their services. For example, YouTube, like all Google properties, uses an accounts.google.com URL for signing into a Google Account, regardless of which service of theirs you're using. Netflix appears to use only netflix.com URLs. Apple is an interesting one, as they do have icloud.com and apple.com URLs for which Apple IDs are used, but we treat those as equivalent. This isn't something we're going to allow globally, as phishing protection is an important part of 1Password. But even if we don't want amazon.com logins to automatically work at just any other URL, you're free to add whichever URLs you wish to your own login items.

The obvious alternative to this is to store plain text URLs / or allow the user to CHOOSE SLOW Search/Fill Speed

We're not going to do that. We did in the past when it was necessary for search to work at all, but it isn't any longer. I'm not sure what you mean with that last bit though. Please explain.

If the URL and root domain are hashed and that is new compared to the plaintext storing of URLs in older app versions, why not bring that "feature" back as an option for users who want a bit less security (25%?) but the convenience of wild card domain mapping? Seriously the lack of wild card domain or subnet matching is one of the most annoying things about this password manager. I have to to be asked "REMEMBER" a cred I use on hundreds of systems on my network?

This doesn't seem at all related to the rest of your post, but it sounds like this may be what you're really after. Can you elaborate? What is it you're trying to accomplish exactly?

butakimchee

Hello Brenty,

Thanks for the thorough reply. I agree there is no need for whitelisting.

Matching against the root domain (Netflix.com vs login.netflix.com ) meets the majority of the requirement, but an option to always save the root domain would make password filling work even more consistently.

That won't work in the enterprise use case, like the fellow deploying heroku apps as app-prod.mycompany.com and app-dev.mycompany.com with differing sets of credentials.

So if wild card used to work in a previous release of 1pass but was causing slow password fill speed, why not allow the end user the choice of having slow fill speed but with the benefit of regex wildcard matching?

Finally - regarding subnet and network matching for saved logins or Autosave exclusions, it's the same conversation about root domain matching except I'd like to match or exclude against large network segments. Like 10.0.0.0/8 . See attached picture as example ;)

• Buta San

littlebobbytables

Hi @butakimchee,

The website field serves two key purposes:

1. To list an allowable domain for the purposes of filling.
2. The URL to be used for open-and-fill.

1Password will always consider both the FQDN (Fully Qualified Domain Name) of the stored URL and the root domain which I tend to refer to as the registered domain. For this reason I'm not understanding exactly how you imagine this option working. Can you elaborate please.

When it comes to adding optional features we are very conservative. Anything that can be enabled or disabled, if not clear and obvious can result in being a hinderance rather than helpful. Take the option Allow filling on pages that closely match saved websites. I've never once come across somebody using it correctly or finding it useful. Indeed every time it's ever come up it's because it's causing trouble after being enabled (it's disabled by default). I'd vote to have it removed completely. We get requests for new options all the time but if we added even a fraction 1Password has the potential to become unfriendly due to the complexity and we can't just add an Advanced section somewhere and hide it behind that.

Currently the exclusion list in the Browsers tab is a simple string comparison. You can edit an entry and remove the subdomain and that would work but it would require changes to support IP subnet masks. It's possible if we saw demand for such a feature. That's one useful thing about these public support forums, it does help us gauge interest given other people can see your request.

AGAlumB

Matching against the root domain (Netflix.com vs login.netflix.com ) meets the majority of the requirement, but an option to always save the root domain would make password filling work even more consistently.

@butakimchee: How would it make filling work more consistently? The TLD has no impact on 1Password's filling logic; it just makes a best-effort attempt to put the right information into the right fields. Did you mean something different?

That won't work in the enterprise use case, like the fellow deploying heroku apps as app-prod.mycompany.com and app-dev.mycompany.com with differing sets of credentials.

Heroku is a terrible example because it's already treated differently than most others because they've asked to be added to Mozilla's domain suffix list. You could apply to have your own site added by Mozilla though. We don't plan to make 1Password treat every TLD like that because that's not how the internet works or how most people use it. Deciding which TLDs should be treated specially isn't a business we're in.

So if wild card used to work in a previous release of 1pass but was causing slow password fill speed,

It didn't. 1Password has never supported wildcards. We'd have to rewrite it to allow for that, and there are a lot of other things we should do first before we work on something like that.

why not allow the end user the choice of having slow fill speed but with the benefit of regex wildcard matching?

Because weird niche settings like that are a bad user experience for most people, even if it would help your specific use case.

Finally - regarding subnet and network matching for saved logins or Autosave exclusions, it's the same conversation about root domain matching except I'd like to match or exclude against large network segments. Like 10.0.0.0/8 . See attached picture as example ;)

It's something we can consider adding in the future, but realistically there just aren't a lot of people asking us for this feature. We're generally going to focus on the things that do the most good for the greatest number of 1Password users if we can help it. And in cases where we work on something that's a solution for 1% or less, it's usually a bad bug or something. I'm sorry I don't have better news for you right now, but we'll continue evaluating all of this, and it may be something we do in the future if it makes sense to — especially if we decide to rewrite 1Password or something. :)

lucasrolff

I have an issue, and that is with 1Password, I store passwords for about 1200 servers, all servers are under *.mydomain.com

So when I try to autofill passwords, 1Password just gives me a list of 1200 servers, and I have to find the right server by actually searching.
What I find weird is that if I am browsing server1.mydomain.com - why 1Password doesn't match this one if it's already in my password database, sure use the "mydomain.com" hash if nothing matches the more specific hash.

But it's pointless to have a browser extension if it can't make my workflow even a bit more.

littlebobbytables

Greetings @lucasrolff,

Be default 1Password does this, exact matches to the the FQDN (Fully Qualified Domain Name) appear above those that only match to the registered domain name. If you're finding this isn't happening I suspect you have a particular option enabled. It's in the Browsers tab of 1Password's preferences and the option is titled Allow filling on pages that closely match saved websites. It's effect is to ignore subdomains and treat every item based only the registered domain name. That would certainly explain the precise matches not bubbling to the top as they should. That option is Mac specific, if you're referring to a different platform please let us know and I'll supply any details I can.

lucasrolff

@littlebobbytables

Be default 1Password does this, exact matches to the the FQDN (Fully Qualified Domain Name) appear above those that only match to the registered domain name

Maybe, but not if you have a port specified, so if I have port ":2083" (cPanel port) ":2087" (WHM port) or ":8006" (Proxmox port), then they won't be listed at the matching FQDN.

It's in the Browsers tab of 1Password's preferences and the option is titled Allow filling on pages that closely match saved websites

I have this option disabled because I find it insecure.

A specific example, I have the 4 entries below added to my 1Password database:

Title: Customer Support - URL: https://support.mydomain.com/admin/
Title: Server1 - URL: https://server1.mydomain.com:2083/
Title: Server3 - URL: https://server3.mydomain.com:2087/
Title: Proxmox01 - URL: https://proxmox01.mydomain.com:8006/

If I go to https://proxmox01.mydomain.com:8006/ in my browser, click on the 1Password icon (or use the shortcut), the selected match it will show is "Customer Support" - because the entries are sorted by alphabet.

It should match Proxmox01, because that's the closest match on URL level, but it seems like if using a port in the URL, it will never be taken into account.

At least I see logins in the wrong order.

And also what I would suggest is following:

• Show the list of passwords matching root domain but only if there's not a specific one for a given URL.

So in above case if it worked as intended:

• Your current implementation should show Proxmox01 as the first hit, and will then show the remaining 3 as well as 2, 3, and 4th example.

What would be nice would be to only show Proxmox01, since you have an exact match on the URL/sub/domain

littlebobbytables

Hi @lucasrolff,

This isn't the first time I've seen the word insecure used in reference to this option so I'd like to take a moment to explain what the option does and doesn't do, just in case others reading this conversation find it useful. The reason I find that particular word odd in this context is because the option does not alter what items will match and which 1Password will allow you to fill a particular page with, all it does is alter the ordering in which they are displayed. Take your example with those four Login items. Regardless of whether Allow filling on pages that closely match saved websites is enabled or disabled, 1Password will match all four items to any page on mydomain.com or any subdomain of it. 1Password will also allow you to select and fill with any of those four items, again regardless of whether the option is enabled or disabled. All the option does is alter the ordering in which they will appear in 1Password. It is unlikely that 1Password will ever limit a user to only a precise match to the FQDN (Fully Qualified Domain Name) as we believe this will only generate more confusion.

I don't have many Login items that need to specify a port but I do have two devices on my internal network and 1Password behaves as I would expect when I visit either of them, the top entry is always the match to the Login item with the same FQDN and the other is a lesser match to the registered domain name - we don't factor in the port number during the matching process. This is the expected behaviour. What you describe is if the option I referred to is enabled, all four are matched only to the mydomain.com and sorted alphabetically with no regard to subdomain.

So the question becomes why is 1Password behaving in this manner for you if the option is disabled? In all honesty I've not seen this before and I can't think of any cases I've heard of where the displayed state of that option differs from the stored state so I'm surprised. I do have one question, you used the phrase closest match when referring to your example with proxmox01 rather than saying exact match. The two FQDNs look identical in your example, is there any difference at all other than in the path of the URL? If there is, and the host components are not an exact match then it's worth noting we don't do any sort of fuzzy matching, it's either an exact match or it isn't and if it isn't an exact match it gets grouped with everything else that only matches the registered domain name.

Let's try a couple of things.

1. Manually save two test Login items for me please. For the first title it TestA and set the website field to https://google.com. For the second title it TestB and set the website field to https://accounts.google.com. If you now visit https://accounts.google.com in what order do the two items appear?.
2. Enable the Allow filling on pages that closely match saved websites option in 1Password. If you visit https://accounts.google.com again has the ordering of those two items changed?
3. Disable the Allow filling on pages that closely match saved websites option in 1Password. If you visit https://accounts.google.com again has the ordering of those two items changed?

Along with these observations, what version of 1Password do you currently use? Hopefully something stands out that explains why you're not seeing the expected behaviour or that toggling the option maybe corrects some weird state that I haven't heard of.