Multiple usernames with same password

13»

Comments

  • Just to chime in here by adding another use case.

    Some websites allow you to enter multiple email addresses (I'm beginning to lose track of how many I have...!), and this is a convenience factor that helps to prevent accidentally creating multiple accounts where you need only one. Sites like PayPal allow you to do this, and in fact you can log in using any one of your email addresses, obviously the password applies to the entire account regardless. What is filled in automatically is often driven by a web site where you are making a payment, and the email address used can relate to what your email address is being used for (i.e. personal business vs. private vs. employer related expenses, etc.).

    The password manager in both Google Chrome and Safari actually already handles this seamlessly and provides a popup to decide which username to use (and which password, if you have several username/password combos, which is a slightly different situation to having a single password but is supported as a side-effect).

  • brentybrenty

    Team Member

    Indeed, I don't use that feature for PayPal or other websites because it can be pretty confusing (and it doesn't seem to be mandatory), but it's worth noting that some sites do things that way for whatever reason. :)

  • I'd like to add myself as another counterexample to the claim early in this thread that surely not many people would need this.

    I'm in the same situation as many others in this thread. My employer syncs user accounts across several third-party systems, so I use the same password (and same TOTP), but different usernames on different sites.

    Like some others in this thread, I want to strictly maintain the invariant: 1 password = 1 login item, while also dealing with the reality that corporate single-sign-on often requires using 1 password with different usernames on different sites.

    The invariant is important for security, since it keeps my watchtower audit clean, and also for usability, since it avoids having to update passwords (and TOTP tokens) on multiple login items when my employer forces me to change my password every 90 days.

    Currently, maintaining the invariant means that 1Password is unable to fill the correct username.

    I understand that implementing solutions is rarely straightforward, but at least the concept seems quite simple to me: You already support multiple websites per login item. All we want is multiple pairs of (website, username) per login item, and to fill the username based on the website that it is paired with in the login item.

  • brentybrenty

    Team Member

    It helps to get the specifics. Thank you! :chuffed: 1Password only supports a single username, period. It's certainly possible it could support more in the future, but that would mean pretty deep changes to about seven different apps with regard to data structures, UI, and -- perhaps most significantly -- filling. As an extreme example, iOS 12 Password Autofill simply supports only three things: one username, one password, and one URL (not sure offhand, but I think the same may be true of Android). I mention that to illustrate that what seems superficially a minor change has far-reaching implications, not just for 1Password, but for the platforms where literally millions of people use it. Given the relatively small number of requests we've had for this, it's difficult to justify making the kinds of changes that would be required of us, and taking on the support burden that would result from our inability to change other people's software that 1Password integrates with. Not saying it will never happen, but we do need to be realistic about all of this. :)

  • So, I think I have an alternative solution for this issue that seems to be working pretty well.

    I had the same problem as all the others. In some places, my username is my email address, and in others, it is just the first part.

    I started down the route of creating separate logins for username and for password where the password one left username blank and listed all the various websites it can be used for, then separate username logins with no password for the various subsets that expect one form or the other.

    After getting that all set up though, I took a look at the View Saved Form Details button and realized that the tooltip for the username field had a value that I recognized as matching the HTML input tag's name attribute on one of the sites.

    So, I edited the card, and tried adding a couple of other variants. For sites using the email variant, the field was named "identifier" and "hiddenEmail". For sites that were wanting the short form, they had the names "user" and "j_username".
    I created four fields in the Saved Form Details section, filling in the appropriate value for each.

    At first it didn't work, but then I thought to delete the original entry that had the little person icon next to it, and suddenly, it started filling right on each specific site!

    Follow-up questions for the 1p people, it would be great if you could share any details about what exactly the ";opid=__0" part in the tooltip means, and whether there is a syntax that can be used to provide more specific matching. I have one conflict case where a site expects the email variant, but the input field is named "user". It has a different HTML id attribute, and it is contained inside a form tag with a different name, so if I could either refer to the id (I tried #uid but it wasn't picked up) or by CSS path (I tried ".login_form > .user" and a few like that but couldn't get any to work) then it would be possible to disambiguate that particular case as well.

    Also, it would be good to know how that little person icon influences things. If it is set for any field, will that always take priority or is it possible to have it be overridden in certain cases?

  • brentybrenty

    Team Member
    edited April 25

    I took a look at the View Saved Form Details button and realized that the tooltip for the username field had a value that I recognized as matching the HTML input tag's name attribute on one of the sites. So, I edited the card, and tried adding a couple of other variants. For sites using the email variant, the field was named "identifier" and "hiddenEmail". For sites that were wanting the short form, they had the names "user" and "j_username". I created four fields in the Saved Form Details section, filling in the appropriate value for each.

    @deinspanjer: That's a really good point. It won't work in all cases, and it depends entirely on the way the site(s) are coded (they may all use the same ID for username fields that require different usernames), but that could help some people. Thank you for bringing it up! :)

    Follow-up questions for the 1p people, it would be great if you could share any details about what exactly the ";opid=__0" part in the tooltip means, and whether there is a syntax that can be used to provide more specific matching. I have one conflict case where a site expects the email variant, but the input field is named "user". It has a different HTML id attribute, and it is contained inside a form tag with a different name, so if I could either refer to the id (I tried #uid but it wasn't picked up) or by CSS path (I tried ".login_form > .user" and a few like that but couldn't get any to work) then it would be possible to disambiguate that particular case as well. Also, it would be good to know how that little person icon influences things. If it is set for any field, will that always take priority or is it possible to have it be overridden in certain cases?

    Yes. That's just the UI for 1Password designating which field should be treated as "username". Often username fields in web forms have at least somewhat logical IDs for these, but then in many cases they don't. So when 1Password is able to match the saved field designated as "username" (the "person" icon) to the appropriate field in the form it can work even in some weird situations. One rule of thumb we use is that the field preceding the password field is the username field...but of course that isn't always the case; web developers can be too "creative" sometimes. :tongue:

  • IntlOrangeIntlOrange Junior Member

    +1 for introducing linked logins, whereby multiple logins (1Password entries) could share the same password on purpose. Instead of displaying the "reused password" warning, some indicator showing the password value is "linked" could display. Changing a linked password on any one of the linked entries would apply the change to all other linked entries.

    My use case is working that my company uses SSO and enforces periodic password changes. So I frequently need to change my primary SSO password, but since it is used across so many different services, in 1Password I store the same password in several different logins. 1Password thinks the password is "reused" but I know it's really the same password (keyed into the same authentication service) but it gets entered into many different services.

    Thanks for your consideration.

  • brentybrenty

    Team Member

    @IntlOrange: Thanks for getting in touch! You can add multiple URLs to any Login item, rather than having multiple Login items with the same password. It sounds like that would help in your case. Have you tried that? :)

  • IntlOrangeIntlOrange Junior Member

    @brenty Thanks, but wouldn't that limit my ability to use "open and fill", since 1Password would only "open and fill" the primary URL on the list?

  • brentybrenty

    Team Member

    @IntlOrange: I wasn't sure what you meant at first, but I guess you mean as far as pressing Return on a selected Login in the item list? Sure, that would only work for the first URL saved, since 1Password has to have some default action, so it is best to put the most commonly-used one first. But there's nothing stopping you from selecting a different URL in a Login item using the mouse or keyboard, and 1Password will also Open and Fill when click or press Return there. :)

  • IntlOrangeIntlOrange Junior Member

    @brenty Thanks, I'm testing what you suggested and will let you know how it goes this week. The first thing I notice is: Each of the services I use can have their own security questions. I capture those in the "notes" field of each login. So by merging these logins all into one, I also just have slightly messier "notes." I can probably live with that. :)

  • brentybrenty

    Team Member

    @IntlOrange: It's really a matter of personal preference as to just how you go about it, but I'd suggest using custom fields for some of that. I like using those for "security answers/question" because it puts them each in little bite-sized chunks for easy copy/paste, and also easier reading, in my opinion. :)

  • IntlOrangeIntlOrange Junior Member

    @brenty Great tip, thanks! I can even use the "sections" to group related items.

  • brentybrenty

    Team Member

    Yes! Sorry for not mentioning that, but it sounds like you've got it. :)

  • We have exactly the same problem at my university. Our course management system and other logins require a complete email address, while all internal services just take the username. I really wish you could come up with a way to easily share a password across multiple logins.

  • IntlOrangeIntlOrange Junior Member

    +1 to what @cportner says! @brenty I discovered this today: While I have many logins that share the same password (linked due to SSO), the usernames can vary. One service could prefer [email protected] while another is just username. I even have one service that requires [email protected] (no .com).

    So far, using the workaround we've discussed above, I have to manually remember which service needs which version of the username.

    Can I store multiple usernames on one login?

  • brentybrenty

    Team Member

    @cportner: I have no doubt that we can "come up with a way to easily share a password across multiple logins". :) The issue is that we a change like that requires a great deal of work in development, testing, and support -- more because 1Password is already a thing, millions of people are already using it, and it needs to continue to work across about 7 different apps now. Ideas are easy. Implementing them in a way that is useful for you yet doesn't ruin a ton of other people's days/workflows is the challenge, and doing it right would mean not doing a lot of other work on things that would help even more people. Hopefully this is something we'll be able to tackle in the future, but for now the workarounds mentioned above are something that's actually feasible -- e.g. having the various login pages save your various usernames, and using 1Password's existing multiple URL feature to avoid having the same password in multiple items.

  • brentybrenty

    Team Member

    @IntlOrange: You can, but 1Password can't do anything with them. Nevertheless, saving them in custom fields allows you to name the fields in a way that makes sense to you, and easily copy and paste a single username as needed. Copying a field in 1Password mini should also dismiss 1Password mini to make it easy to paste it.

  • IntlOrangeIntlOrange Junior Member

    @brenty Thanks, I'll try using custom fields for this purpose!

  • brentybrenty

    Team Member

    You're welcome! Custom fields can't be used for filling because 1Password doesn't know anything about what they're for, but I find them really useful for organizing stuff within items. :)

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file