Multiple usernames with same password

Comments

@brenty Just putting my thought here, but you already can save multiple URLs inside an item so basically the only thing you have to do here to achieve that is "couple" username with a set or URLs. So something like this:

@brenty if you have a connection between the username to url then it knows -> from my example if I am on service2.com and ask it to fill, it will fill the first username. If I'm on service3.com, then it will fill the second one.

@ondrejfuhrer: I get what you're saying, but I don't see how that is any better than having two separate Login items, since you'd still have to select that each time. The only difference is between choosing between two Logins and between two sets of login credentials in the same item.

At work, the only company we work for has me use 1 login and 1 password for about 7 different sites that they own/run. I actually do the idea that @ondrejfuhrer does. I have all 7 URLs listed in the login thatcher credentials work for.

@prime: I definitely have a lot like that, both for work stuff, financial accounts involving different sites, and also some for testing (which I suppose also qualifies as work). I think the difference though is that those are multiple addresses where a single set of login credentials can be used. That's something 1Password has supported for a long time (version 4?) I may have misunderstood, but I think what ondrejfuhrer has in mind is storing multiple sets of login credentials in a single Login item. Maybe I'm missing something.

Hey @brenty , kind of yes. The problem here is, that it is not a set of “whole” credentials, but only usernames. So you have centralised user management system (with LDAP or whatever) which creates and updates logins for all work related sites. So far so good.

The problem is, that some site requires your username (firstname.lastname) and some sites your email address. But in all the sites you have same password.

By having multiple login items you end up with inconsistency, because if you change your password in the user management system, 1Password will ask you to update only one login item and then you have to manually update the rest or forget about it and then wonder, why you cannot login there.

Also having 2 different login items causes security audit to scream at you, that you have reused password, but you just simply cannot have a different ones there.

@ondrejfuhrer: Okay, I missed part of that. So the password is the same, but only the username is different? I'm not sure I've heard of that before, and it seems insane to me. Thanks for clarifying, and bringing it up in the first place. I'm not sure we can justify making changes like this given the seeming rarity, but it's something we'll keep in mind going forward, especially if it becomes more common.

First of all, I really need this feature too. A single login with multiple site and each site having its own username. I know it gets complicated, but given the fact that anyone using SSO has this issues (universities, corps, etc), it is definitely needed. @f1337
I like your solution the most. However, I wasn't able to create a login entry that doesn't have "username" field. It submits the username field even when I leave it empty.

Thanks for the feedback. For that to work, you'd probably have to create web form data fields with the correct ID for the username, and also give it the "username" designation. Again, 1Password isn't designed for this use case, since greater than 99.9% of sites on the internet use a single username (that's even in the W3C spec), but it may help.

Hi, same requirement here, and thinking of a feasible solution, I thought about the possibility to link an login item to a password item instead of entering different links or user names. So users would have to adjust only one password on change and had freedom to link any login (independent on web adress, user name and so on) to one password. Just a thought.
Regards & Thank you for the great product

I'm in the same boat. And since I've brought several coworkers into the 1password fold as well, so are they.

As for how to manage it .... I'm thinking first of all a setting to even enable the functionality so as not to confuse people that don't need it. And then when you add a URL there's an option to specify a username for that site. If you don't specify one, it falls back to the username defined for that login.

I also like sumobaer's suggestion as then you could have all sorts of attributes vary by site but still tied to the same password.

I am also struggling with a good way of handling this in 1Password. I am working as a consultant. Most of my clients have different username requirements for different sites/tools with the same password/SSO account.

I really would appreciate the ability to have multiple user names in one login entry, along with corresponding tools/web site URLs, as suggested above.

Another possible approach could be to allow existing 1Password login entries to be linked with a "same account/password" link. This could be a new menu option to choose from when 1Password complains about reused passwords. Whenever a password for one of the linked accounts are updated, 1Password could automatically update, or ask if the linked "same account/password" entries should also be updated.

Seems like getting embedded within some enterprises would be beneficial for 1Password product folks. The situations of multiple identifiers for the same credential is not at all uncommon in enterprise settings.

I'll just add that if the only solution is "maintain multiple Login entries with the same password", then anytime you are forced to change your password (which is unfortunately, something that large enterprises still insist on contrary to the science on the matter), you have to go and manually find and change every entry with that same password. What happens if you don't? Well, you could have another thing happen which is common in enterprise configuration - you could get locked out of your account if you try to use a password entry that you forgot to update.

My organisation just bought us 1password for use at work and it seems the solution of linking passwords across multiple Login entries would totally fix this issue. While not a problem for home users, it must be a common one for corporate customers like us.

I'll just add that if the only solution is "maintain multiple Login entries with the same password", then anytime you are forced to change your password (which is unfortunately, something that large enterprises still insist on contrary to the science on the matter), you have to go and manually find and change every entry with that same password. What happens if you don't? Well, you could have another thing happen which is common in enterprise configuration - you could get locked out of your account if you try to use a password entry that you forgot to update.

If the logins have the exact same credentials it may be helpful to maintain a single Login item that has multiple website fields on it.

@Ben you're talking about a different issue. The same password can have multiple user identifiers associated with it. 1password assumes it's a 1:1 cardinality. But it's many:1.

Websites require different formats of user identifiers for various reasons. 1password needs to associate the user id format with one or more websites to know which to send.

One reason for different user id formats is to route logins to particular identity providers based on the user's domain name in email address. But many can use a default if not provided so support both userid formats.

Exactly, many cloud service providers adopted email address as username so they know where to redirect to. E.g. using SAML with an on-premise identity provider for authentication (so, different "username" format for these services, same password as everything else because it's ultimately authenticating against the same LDAP). In my case the username isn't even a substring of the email address. There's nothing weird or edge-case going on here. Any organisation with a mix of on-premise and cloud systems are going to have this issue with 1password because the current list of websites feature assumes all sites use the same username format.

Thanks for your feedback, @jaxley and @sam_hall. What both of you said makes sense to me, but I can see it being very tough to get right and avoid confusion. We'll continue to look into ways of making 1Password more useful for everyone, but I can't make any promises when and if something like this will be implemented.

I have the same issue as other here, in corporate context too. Simply put, on-site services are using a username (j.doe) while cloud services are using an email address ([email protected]) to log-in, but both use the same LDAP for authentication, and thus needs to have the same password.

My current solution (as for many others) is to have two logins, each with multiple addresses (one per service). This has the following issues:
- Watchtower is bringing a "reused password" issue.
- Each password change (every couple of months in my case) must be done on both logins, and at least one of them has to be updated manually.

The @sam_hall suggestion of disabling the reuse password warning for linked accounts might be a workaround for the first issue (even if it might hide real security issue for some people), it would not solve the second one, which is the most important in my opinion as corporate accounts are often locked after a few unsuccessful login attempts.

What I would like to see is a way to link multiple logins with a "must use same password as ..." link which would ensure that all linked logins are using the same password, and disable the "reuse password" warning on those.
This might be less confusing as a single login item with multiple username (per website), and as the link explicitly states that the password has to be reuses, suppressing the associated security warning in this case seems reasonable.

Hi @NBz, thanks so much for taking the time to explain your use case in detail. Such posts really help us understand different ways companies manage credentials. I'll share your thoughts with the rest of the team, and we'll continue looking into this. As I mentioned previously, however, there's no timeline I can give you on when and if we'll be able to address this in the near future.