Create several fields (username\password) for Login type record

Got it, sloot, thank you! We'll look into the considerations around this.

Watchtower, plus this is on a system that requires me to change my password periodically, so having two items gives me the capability of having one of the passwords incorrect :-)

[two items is how I currently handle it]

Hi sloot, good question, and I'm happy to think through this with you.

Is there any disadvantage you can think of to maintaining two separate items, like so?

1. DOMAIN\user and password
2. user[at]domain and same password

(other than the fact that Watchtower will mark the passwords as a repeat, which is something we can consider in further design iterations on our end)

This is very similar to a question that I wanted to ask. Our systems all back onto the same AD, but some of them use user@domain to login and some of them use DOMAIN\user to login. I'd like to maintain one password for these two entries, is there any way to accomplish it?

Hi @Axell, thanks for the question. My ability to speak to the specifics here is a bit limited, but I can tell you that generally:

1. We understand that users may have more than one password associated with a given account. To take a random example, I think Protonmail used to ask users to enter two passwords, before changing the approach.

2. However, it's more rare to encounter a situation in which more than username would be associated with a given account (or login 🤔). Typically a username is associated with some piece of data (a UID, perhaps?) and this thing is fundamentally what the user is, from an authentication perspective. Any passwords they have are tied to the UID, the username, and other data associated with that (perhaps the device they use, characteristic IP login range and geographical location, etc).

While it might be technically possible to let folks create a login item with more than one username, there's a worry that this would lead to confusion or user problems more frequently than it would resolve an issue that a person typically faces. I hope that makes sense!

Thanks Tertius3 for your answer. Ok, one more thing.
Despite all of this, we still have the opportunity to insert the password field... So, in this logic we have 1 account with one username but more than one password.... as you know my logic was in this direction...
If we have in one record ability to create more then one password field, why, according to the same logic, we cannot have another field with a username....
Thats ok if the first login (username+password) will be auto fill in on sites...

If not - why we still can create more than one password fields.... pls delete it!! One account = 1 pass + 1 username....as you said.

1Password doesn't work like this.
1Password is designed to have its own entry for each username+password pair you have. So if you have 10 accounts somewhere, it's intended you create 10 different login items for these, each with its own username+password pair. This way, browser autofill works. If you set up your accounts this way, the 1Password browser plugin is able to find and autofill all your logins with 1 click if you want to login to some website. Copy+paste usernames and passwords is never required this way.
If you don't organize your data this way, you forfeit all the terrific convenience benefits of 1Password.

Even for app logins, where you cannot use the browser extension, you don't need copy+paste. Simply drag the username field, then the password field into the input fields of your app. 1Password backgrounds/foregrounds itself perfectly to support this workflow. At least the v8 client works like this.

Copy+paste is considered a security risk, because the clipboard can be watched and sniffed by keyloggers and is disclosed by clipboard history apps. Drag+Drop entries is protected from this.

Usually, it's not required to add even one custom field - it's all in the standard templates.