Multiple logins for same site (but different port)

@eddydc: Sorry for the confusion! I can definitely appreciate that in some cases you'll want 1Password to discriminate based on port number...but this isn't something 1Password supports, since in the vast majority of cases you won't want this.

Before you think I'm crazy, let me give an example: HTTPS. 1Password works based on the URL, otherwise the http://gmail.com login you saved years ago would be completely ignored now that Google redirects everything to https://. At a glance, it's something even you and I may overlook, but most people will absolutely not see this difference and will believe they're login(s) lost forever. Ouch.

For that reason, 1Password works based on domain/subdomain — both port and directory/document are ignored for purposes of matching. You'll still be offered these logins for the domain, so perhaps naming them distinctly would help identify their use. And of course the other side effect of that is that if 1Password sees you already have those login credentials for that domain, it won't offer to save them again. However, if there's a particular URL where you aren't being prompted to save new login credential for the domain, be sure to let us know so we can investigate.

We'll definitely consider making it more discriminating in the future, but we don't want to do so at the cost of usability. It's an interesting topic for discussion. Thanks for bringing this up! :)

ref: OPX-881

I certainly understand your perspective, @eddydc. One of the things that impacts this is that in our newer data formats (starting with OPVault in 1Password 4) do not store the URLs for your items unencrypted. In the previous AgileKeychain data format, the URL was considered metadata that was left unencrypted for performance reasons. Now, though, we still have performance needs to be able to look up your Logins for filling even when 1Password is locked. So, we store a hash of the URLs' full hostname (www.example.com) and the root domain name (example.com).

When you're visiting a web page, 1Password computes the same hashes from the URL it gets from the extension and then uses the computed hashes to look up the Logins that match the page you're on. With these hashes, there's not a way to determine what the port number is for a given stored hash.

We do have some ideas for how we can better handle this, but it will require moving around some things in 1Password to allow this kind of looking up in a way that will not hamper things like the immediacy of Command-\. Moreover, we have to decide if this is what users will expect. The current behavior of matching and preferring Logins at the subdomain level is already confusing to some people, and expanding this to more criteria will make it potentially more confusing, so that's another angle we have to consider.

I hope that makes sense.

--
Jamie Phelps
Code Wrangler @ AgileBits

@eddydc: I understand completely. I have a handful of Basic Auth logins myself, and it isn't nearly as nice as what we're used to with websites that support current standards. Both that and the port matching are on our list of things we'd like to but don't have the bandwidth to do currently I'm afraid.

Now, that's not the news you want to hear when you run into one of these limitations, but in both cases they're not something that most people care about (you and I notwithstanding) and given that we're a small team we really need to focus our efforts on doing the most good for the most people.

In the case of ports, I realize there are some people out there who would kill for that feature, but it isn't something we can do without significant effort, disproportional to those it will benefit, so it's more likely to be something we do as part of larger changes to the way 1Password works — so we're probably not talking short term.

And in the case of Basic Auth, not all browsers even allow extensions to access this through their API, and there are significant differences between the implementations of those that do, so it's really something we'd need to tackle on a per-browser basis...and of course that multiplies the development and testing significantly — again, for something that most folks won't ever touch.

But I hear you: copy/paste is a drag when we're used to 1Password making our browsing experience smoother and more secure the other 90+% of the time, and frankly I'd like us to support both on principle, since it would make some people incredibly happy and then we could be proud to have those off our plate so we can all move on to the next extension milestone — and there's always a "next". But until then, I really appreciate you bringing this up. It makes a huge difference to us when we hear from folks about the features they're looking for. Thanks for your patience and understanding, and I truly hope we'll be able to grant your requests someday! :)

@eddydc While autosave will not prompt you to save if it finds an extant Login for that site with the same password, you can always save manually. I definitely think we could improve in some of these areas, particularly with the Login matching, but like I said before, those changes don't fit particularly well with the current flow and would require some substantial changes. I'm not saying it can't or won't be done, but we do have other things we need to focus on right now.

Haha indeed! Thanks for the feedback! Just make sure you're not reusing passwords, and let us know if there are particular sites you're having autosave issues with. As Jamie mentioned, 1Password should be offering to save a new login if the password doesn't match those already saved. Cheers! :)

I'm sorry, @mylittlebeaker, but this isn't possible and I don't think it's something we would want to add to 1Password. 1Password's ability to match your Logins' URLs to the page you're currently viewing is part of phishing protection in 1Password. One of our favorite sayings here is "No decision is permanent" so I can't say we'll never do this, but I can say it won't be coming any time in the near future.

If it's at all possible to automate knowing the IP address that comes out after the deployment, I would write a script to edit a hosts file to point some constant test domain name like myvirtualmachine.test to the new IP and then have that be the URL in your 1Password item. That's about the best option I can think of for something as particular as this use case.

--
Jamie Phelps
Code Wrangler @ AgileBits

Hey @HappyUser,

Thanks for taking the time to write into us. Unfortunately this still isn't possible with the current way that 1Password works and we don't have plans at the moment to implement this. Our view on this particular request is articulated very well by Brenty in his post earlier in this thread. I hope you can take a moment to have a read through it to see our point of view on this particular request.

Thank you very much for writing in and we would love to hear other suggestions or feature requests you may have.

Best regards,
Matthew

While it's clear Agilebits aren't very keen on the idea, I just want to add another voice requesting this feature be considered.

@frog: Thank you! It isn't the case at all that we wouldn't like to have this feature ourselves, but put in the context of our other responsibilities it is something we have to say no to for now.

First, while I don't think Brenty is "crazy", I do disagree with his assessment that in the vast majority of cases you want to use the same login credentials for all ports on a particular domain/subdomain.

Thank you. :lol:

To be fair, even if I'm not crazy, re-reading my post I do see that I misspoke. What I said was:

I can definitely appreciate that in some cases you'll want 1Password to discriminate based on port number...but this isn't something 1Password supports, since in the vast majority of cases you won't want this.

But what I should have said was:

I can definitely appreciate that in some cases you'll want 1Password to discriminate based on port number...but this isn't something 1Password supports, since the vast majority of users won't want this.

That's really the chief concern, and I'm sorry if I misrepresented that. Obviously this would be very useful to some people, including folks here at AgileBits, but given that we still have plenty of work to do to improve login filling for everyone and support significant browser changes, we kind of have to be picky about where we focus our efforts.

You've offered some great suggestions as far as implementation, and these are things we can take into account if and when we go this route. But none of those options are possible now because 1Password simply isn't programmed to handle any of that, and it isn't something we're working on currently. I agree that it would be nice to have this capability, and I doubt that anyone here at AgileBits feels differently. But someone has to do the work, and currently we have our hands full supporting our existing browser integration capabilities.

Hey @mthome,

Adding configuration changes like this one would require work initially and testing to ensure it works correctly. Once it is released we would then need to make sure that it continues to work which is a maintenance cost that never ends until the configuration option is removed.

We really need to ask the question is the effort to build, add the feature, support it and continually test it is worth it in the long run? As Brenty mentioned we also have a other issues that are affecting a lot of more customers than this one and have the same cost I described. As developers we only have so much time and need to make a call. We really want to make 1Password the best that it can be for the most people. I'm afraid to do this we need to say no to some requests to allow ourselves to focus on what is most important.

Best regards,
Matthew

Hi @danielcompton,

It's an interesting point. I will be curious to see certain people's responses here at AgileBits when I reference this internally. My initial thought of course is that if an attacker has already managed to reach the point where they're running a process on a supposed privileged webserver that it's really game over already. It seems unlikely that if somebody can get that far that compromising the machine entirely isn't going to happen and would be the more effective route. That's just my initial take on it.