Create linked Login items, i.e share same username and password between Login items

mklassen

Is there a way to create linked Login items where the username and password credentials are shared? The reason I ask is that I have an identity that is used on many different sites. In my particular case it happens to be different workplaces services that all require my employee credentials. I use multiple websites / locations in a 1Password Login item so the same credentials are used on all sites. However some the services use 2FA with one-time passwords which causes problems. Because the 2FA is separate from the normal employee credentials and different for each site, storing them within the same Login item does not really make sense. Plus keeping track of additional information like site specific recovery codes would make management within one Login item a nightmare. I resort to making separate Login items for each site, however this becomes painful when, in keeping with good security practice, I update my employee password. I now have to make changes to multiple Login items. I personally detest saving the same information in multiple location because you invariable forget to update some instances when required. A minor additional annoyance is that 1Password also warns me I am reusing a password, which in this case is unpreventable. Having linked Login items would let me update the password in Login item and have it automatically propagate to all the required Login items.

---

1Password Version: 7.3.2
Extension Version: Not Provided
OS Version: 10.14.6
Sync Type: Not Provided

ag_michaelc

Hey @mklassen! Thanks for reaching out. The short answer is no, there's not an ability to do this in the way you describe. You can link items so they're easily referenceable from one another, but there's not the ability to use the same username/password between items automatically. Some tips are covered in a similar discussion thread here. You might try using tags to note which items share a password, so you can easily navigate to each of those items when it comes to update them (usernames should be pretty static, I'd imagine). Or you could use one item, as you said you don't do currently, and create different sections in each, which could contain your 2FA codes and any other details for a specific website—for this route, you could store the website URL either in the main item details or under each site-specific section.

There was one bit of what you said I want to ask about:

however this becomes painful when, in keeping with good security practice, I update my employee password.

Are you referring to arbitrary forced password changes, or are you making the decision to update the password on your own? If you're changing it just to change it and you're not being forced to do so, I would advise you against this habit. It's outdated practice as long as you're using a password manager and have a strong, unique password for every site. The only time you need to change a password is if you know or think that the credentials have been compromised. Of course, if it's your employer forcing the password change, there's not much you can do here. 🙂

mklassen

@ag_michaelc, I disagree with your conclusions from the link you posted. The point the author appears to be making is that password expiration policies are not as effective as one might assume primarily because
1. Users tend to choose weak passwords when they know the password will expire.
2. Users tend to use transformations of their password when they change their password.

However if a user is using a good password manager then they will
1. Never choose a weak password.
2. Always make password changes that are completely unrelated.

Therefore the main issues that limit the effectiveness of expiration policies are eliminated if everyone uses a good password manager. My conclusion is that good password manager restores the effectiveness of changing your password, not that it obsoletes password changes. Of course the developers of the password manager need to make it easy to change passwords.

My employer is actually introducing a password expiry policy and I think it bad idea for all reason in the post you linked but only because most people still do not use a password manager. My hope is that 1Password might be able to add features that assist those of that must (or want to) regularly change passwords.

ag_michaelc

Hey @mklassen! That link I provided was just one author's "Reader's Digest" version/opinion of things—I'm sorry for perhaps not choosing the best article to link. I like to make sure I provide links I feel confident/safe sending to people, so rather than a random blog I picked an FTC page. I'd recommend checking out the actual NSIT guidelines, if you're super interested. Those are located here.

Therefore the main issues that limit the effectiveness of expiration policies are eliminated if everyone uses a good password manager. My conclusion is that good password manager restores the effectiveness of changing your password, not that it obsoletes password changes.

I think we'll have to agree to disagree here. :smile: If a password hasn't been exposed (from a breach, if you use it at another website, or maybe from a phishing attempt), then keeping your password as C8NNMwkLuFKUUT8v!!MY is no less secure than changing it to P82MhNejYUbEWsWrHB.f, for example. 20 years ago forced password changes were considered best practice and normal. Security experts nowadays do not recommend these guidelines.

But I don't want us to lose the forest through the trees — your original point about linked logins, companies with SSO, etc. is very much something I think we can think about and improve on. I only made the other points I made to try to simplify your life somewhat in the meantime. :smile:

ag_michaelc

Hey @Slobie Taboobie! That can certainly work well for some people. There's one circumstance where that doesn't work, and that's if different sites require different variations of the same username, e.g., maybe one site requires my email, another requires the domain before my username, and another is just my username. These can all be stored in one Login item, but autofill wouldn't work in this case, at least not 100%. And then in the case of the original comment, there were multiple one-time passwords involved, differing between sites, so that requires a bit of a different workflow, too.

kv3

While I dont have it quite so dififcult as the OP, this is one feature that I would consider valuable as well.
My solution right now is clunky.

I do have different usernames as well, since some systems authenticate through the AD, some via LDAP, others through some secondary server (ugh)!! fortunately, they go through a single password reset page that fans it out to all the right places.

So, right now, I have a single entry that satisfices Active Directory, and if/when that fails, I refill, and trim the username accordingly. All possible web sites are listed in the website list, and this generally appears to work ok,
but a cleaner solution would be useful.

In sum, +1

ag_ana

Thank you for sharing your thoughts about this :+1: :)

scotartt

Hi, I have a related problem, in regards to multiple logins that have different usernames, but are in fact use the same backend authorisation system, and therefore have the same password.

My work's corporate login is the culprit.

Now most we use Azure AD for authentication for work related sites and Office 365 logins. The login for this is my email address, e.g. me.myname@mycompany.com ... however we have some "legacy" websites which still use our internal ADFS login and therefore require the user identity to be of the form COMPANY\adloginname, or just adloginname.

I have two entries one for each of these, one with my email as the user, the other one with the adloginname. 1Password always complains that one of the two has "weak" protection because it shares its password, even though I have "linked" them in the app.

It would be nice if there was a feature to tell 1password that these two accounts are the same account with different userids? Or to ignore the "weak password" check because they are linked? Or to have an option to have one entry with two different usernames?

ag_yaron

Hey @scotartt !
This use case here is very niche and unique, it is very rare and the vast majority of users do not encounter such scenarios. However, it also doesn't really affect you in any way except that visual red banner that indicates this password is being used in multiple logins. You can simply ignore it and go about your day :)

Having an additional feature to disable this warning is not a great idea, although we can definitely see how it will be useful for such very specific use cases. However, looking at the big picture, if we put a feature in, some random users will use it without understanding it, as history teaches us, and it will compromise their security.