Multiple logins for same site (but different port)

eddydc

Hi,
I seem not to able to save multiple userids for the same site and need to add the manually.
On top 1password doesn't seem to make any difference port wise. I have this website that returns different functionally (plain web, web mail, etc) and thus userids/passwords depending on the port. 1password seems to consider as the same, which is rather annoying.
How can I save the credentials without making them manually and 1passwords makes distinction based on port number and shows only the relevant logins?

Cheers
Eddy

---

1Password Version: 4.6.0.604
Extension Version: 4.5.6
OS Version: Not Provided
Sync Type: Not Provided
Referrer: kb:undefined, kb-search:port, kb:undefined, kb-search:port

AGAlumB

@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

eddydc

Thanks for the extended reply, but I think there is a difference between specifying http(s) and specifying the port number explicitly.
E.g. I run my own domain and typical things are managed with cpanel, which runs on port 2083 in my case (which my provider determined). Roundcube webmail uses the same domain, but has port 2096 (again, nothing I have a say on). I need manage all this in 1password manually since it considers it as one URL.
That brings me to the other issue. This single webmail URL serves for all e-mail addresses, thus multiple different logins. 1 password won't let me save all of them and I need to add the manually.

jxpx777

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 the underlying idea, but I wished that - like with the competitors - difference could be made port wise. Also for saving multiple users for the same URL. Same thing btw for http basic authentication. The current copy/paste method is rather tedious.

AGAlumB

@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

Thanks for the (always) extensive reply. You forgot to mention the multiple accounts/credentials for the same URL. I'm not talking about ports, but 'simple' URLs like gmail, dropbox, etc. As a split personality, I have multiple accounts for these.
Once an account saved, I can't save another account for the same URL and need to add them manually. I've read that pwd are compared for an URL and if there is a match, it won't be offered to save again for the same URL. Testing on userid would be more appropriate.

jxpx777

@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.

eddydc

There is clearly room for improvement functionality wise when it comes to full-fill my needs. I'm looking forward to when this will be available. I hope they'll come some (preferable before my retirement ;) )

AGAlumB

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! :)

mylittlebeaker

I'd like to hijack this thread if it's okay. I know how to provide a password for the same site but different ports, but I'd like to provide a single password for a multiple servers on the same port. I know this sounds ridiculous in a way, but I'm using it for development purposes, where a virtual machine generates a completely unique IP each time it's deployed, but the port remains consistent (not an 8000 or 8080 type of port, obviously). Is this possible to do in 1Password? Thank you in advance. :)

jxpx777

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

HappyUser

I also need support for multiple logins for the same host but different ports. I need this both for remote servers and local servers (when developing locally I run about a dozen servers on different ports on localhost which all have different logins).
Thanks a lot! :)

matthew_ag

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

frog

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

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.

The example given is HTTP vs HTTPS, which is a very different situation to the issue people are having here—that example is just two different protocols, which are very often used interchangeably in the wild, and are both using default ports. The case in question is where non-default ports are being specified, which is very rare in the wild.

It's been a very long time since I've seen a public facing website use non-default ports. It's usually limited to local ad-hoc solutions (home network servers, services running on localhost, and some IT admins have been known to set up intranet services this way). In such situations, the lack of a single web server for the host to deal with requests individually also suggests a lack of consistent/integrated authentication across said services.

Given the 'default port' case can be easily separated out, I'd love to know if Brenty's statement remains true for non-default ports. I don't know if 1Password can gather such information without privacy violations, but it seems unlikely that the "vast majority of cases" would be affected by a change in behaviour. In fact, I would suggest it is the opposite.

I'd also like to suggest there are several possible approaches that could be helpful, and it doesn't need to be 'all or nothing':

First, if no port is specified, the current behaviour should apply to the host/domain/etc as normal. All potential matches show up.

If a custom port IS specified in one of the stored credentials, any/all of the following could be added to the 1Password login card:

• a checkbox allowing the user to limit the login credentials to just the specified protocol+host+port combinations listed (otherwise the current behaviour remains)
• a note/warning indicating the user may wish to specify other ports too, or remove the port (relevant if the default behaviour gets changed to target just the specified port)

When using the shortcut to fill in credentials in the browser:

• if multiple credentials are detected from the hostname, but the browser URL matches the protocol+port for one of them precisely, then limit the results to that alone
• OR at least put matching results at the top of the list (above credentials that match the domain, but not the port)

Or if all that's too much fiddling, perhaps the desired behaviour (matching limited to the specified port) could be at least enabled for hosts on private subnets and localhost?

AGAlumB

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.

mthome

Well that's disappointing. I'm surprised that you don't at least offer the option of hashing against the exact URL rather than trying to trim - would it really be that much of a change to offer a configuration option that does exactly that?

matthew_ag

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

danielcompton

Hi folks

I ran into this as well, and see the current behaviour as a (small) security risk. High numbered ports are unprivileged, and can be run by any process. If an attacker managed to open a high port on a privileged webserver, 1Password would autofill the login for this URL, even though http://example.com and http://example.com:56192 should be treated as two different sites. I realise there are a lot of other issues in this example, but I raise it as something that 1Password could/should protect against.

See for example the CA/Browser BR's that limit domain validation to only a few select ports: https://cabforum.org/2016/08/05/ballot-169-revised-validation-requirements/. I can't find the details right now, but I seem to remember there was an issue of certificate miss-issuance from a CA who accepted high numbered ports for verification.

littlebobbytables

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.

AGAlumB

@danielcompton: Indeed, while this may very well start a civil war here, ultimately I can't agree with this statement:

http://example.com and http://example.com:56192 should be treated as two different sites

I know what you're getting at, but this is technically the same website, and I think this scenario is a bit off anyway. I'm trying to imagine how 1Password would be involved in this port scenario (ignoring the fact that mis-issuance would allow an attacker to pose as anything matching the TLD, regardless of port); an SSL/TLS certificate is issued for a domain and just contains the intended server name. And, as lil bobby mentioned, there's not a lot they can't do if they've taken over the actual server (as opposed to merely impersonating it). Food for thought.

That said, I can see how this might be contentious philosophically. So I could argue either side, but I think we need to identify the type of attack we're trying to defend against, and focus on practical application for the purposes of 1Password.

danielcompton

Yep, fully agree that it's a little bit of a tenuous scenario, just adding it to the discussion as I hadn't seen that angle considered in the previously (though I may have missed it).

AGAlumB

I find it absolutely fascinating myself. I was looking into this more earlier to see some others' thoughts on this as well, but ultimately RFC 3280 just doesn't make any provisions for ports, only domains. And even if that changes in the future, it can often take decades for things like this to be adopted. Thanks for bringing this up! :)

0Neji

Hi,

I know this is an old topic but I wanted to raise it from the dead. Loving 1Password so far but this is a bit of a killer for me. I'm a developer and tend to develop a large number of sites all on localhost with different ports so naturally, I'd love to see this brought back up. An earlier suggestion of allowing this for localhost was suggested but never really addressed apart from you guys having to make a decision on whether it's worth it or not. Was there ever any movement on this or will I need to carry on my search to find the perfect password manager?

Thanks,

Ben

AGAlumB

@0Neji: It's not something we're focused on right now, as there are a lot of other things that have been requested by many more people. It may be that this is something we work on in the future, especially if we make other changes to how login matching works. But it's not something I can promise and I don't want to give you false hope. It's something we'll continue to consider, but ultimately we need to work on the things that will do the most good for the greatest number of 1Password users. This just isn't at the top of our list currently, given how little interest there's been here. :(

0Neji

Hi @brenty - thanks for the quick response! Understandable, it probably is quite niche. A shame because I'm loving 1Password otherwise. Having said that, I'm going to try playing around with different vaults, tags etc to see if I can get something together that works for me.

Thanks again!

matthew_ag

Hey @0Neji,

Thanks for your understanding and really glad you're enjoying 1Password. Great to see your passion for 1Password.

If you have any other questions about 1Password, please don't hesitate to write again. We're always here to help.

Best regards,
Matthew