Custom fields are properties of the vault’s entry (not the username/password)
thus there is no problem here when having more than one username/password for the entry.
However custom fields can link to other fields including username/password and in this case username and password should be treated specially and the value used in this case should be the one selected by user from the list of all usernames for this entry during autofill. In other words Username and Password below should be treated like an alias to the username and password used for autofill and not literally which would mean the first username and the first password (in case there is more than one).
TOTP 1
TOTP 2
Password History 1
Password History 2
What if the custom field is “account number”? How would one arrange for different account numbers per password?
What does the auto-fill overlay look like when there are two usernames?
When auto filling with ctl-shift-L twice, does it go to the next vault entry or the next username? And then, does it reorder the usernames so that the most-recently-used is first, so that a ctl-shift-L on the password field selects the corresponding one?
If one is a personal account and the other a shared admin account, how would sharing/access controls be managed per password?
Bottom line is that the Bitwarden design is one vault entry per account, not one vault entry per website. This is deeply engrained in its design. Changing that would not be easy, so the win would need to be big.
1 Like
I don’t think anybody in this thread has expressed clearly why such a feature would be necessary. If you would like to impose additional organization onto your vault data, you could create a folder for each website, and store the different accounts for that website inside the folder.
With due respect, the fundamental architecture of Bitwarden is to have a one-to-one correspondence with a different vault item for each distinct set of login credentials. So using Bitwarden as it was intended to be used is the solution.
If there is a valid reason why existing functionality is insufficient, then you will have to describe your use-case in detail and provide some rationale to justify the need for what you’re asking for.
@DenBesten mentioned a type of ‘elevation’ where additional verification is required to perform specific actions with an alternative or additional password associated with the current credential/vault item. In this case additional information might have to be manually synchronized to maintain it as an independent vault item (shared additional autofill fields).
In my case, we use an SSO provider. Usually, I am directed to the SSO provider to sign in; however, specific hosted solutions provide a unique login page and authenticate user credentials in the background. In our particular case, the SSO requires the use of a full email address, while our other solution only accepts the username portion.
In this case, the password is continuously ‘synchronized,’ but two separate login usernames are required. I want to configure Bitwarden to use a default username(login) for most URIs that use the credentials but override the username/password for specific URI filters.
Examples of the frustrations below:
Maintain multiple sets of credentials with distinct URI lists and update each credential during a password change.
Since this does not maintain any correlation between the vault items, it requires manually updating vault items independently by searching or exploring the vault for relevant items and using copy-paste.
This is the least cumbersome daily process, but it is prone to errors as a recurring manual process separated by significant gaps in time.
This also requires additional manual synchronization of any other updates, such as other autofill information.
Maintain multiple sets of credentials as unique vault items with overlapping URI lists.
This requires manually selecting the correct vault item during each login and updating each credential for each password change; however, it does ‘link’ the vault items to all sites, making it less likely the user will forget to update a vault item during a password change. However, it requires manually syncing each vault item.
Use a single credential and manually update the user ID for the site(s) requiring a different username/login. This automatically maintains the vault item’s synchronization but requires daily repetition.
Proposed solution/requirements:
Providing both an AltUsername and AltPassword fields would reduce the cumbersome nature of this use case.
AltPassword should be logged in history, similar to the current password field, allowing for additional authentication.
Both should include URI filters for where they will be used in place of the ‘default’ username/password pair.
The ability to add multiple URI filters to each AltUsername and AltPassword item.
The ability to add multiple AltUsername and AltPassword fields.
These features would allow the user to replace the username and/or password with specific URI subsets. This could resolve DenBesten’s ‘additional verification issue’ and my alternate username issue.
Best regards,
Kevin
One example is that Windows’ long history has resulted in multiple usernames that all refer to the same Kerberos entry:
- username (no with no @ sign)… SAMAccountName … for legacy windows authentication in a single domain.
- contoso\username for legacy cross-domain authentication (e.g in a forest).
- username@contoso.com … UserPrincipalName … for logging into newer windows devices.
- first.last@email.contoso.com …some SAML relationships want users to log in with email address (uugh).
That said, Username, AltUsername, AltUsername2, AltUsername3 seems like a design that would scale poorly due to the need for new semantics describing which username to select. It also would be a wide-spread change, greatly complicating autofill.
Much simpler in my mind would be to have a separate vault entry for each username format and then for the password to be a linked field to another vault entry. Then, I would have 4 vault entries, each with a distinct username, along with the URLs that use it, all sharing a single password that is updated in only in the “main” entry.
Expanding on the above example, some people chose to user their vault to store bookmarks for their SSO sites because my vault syncs to all my devices, whereas the browser bookmark manager does not work cross-brand. In this scenario, it would be helpful if the username could similarly be a linked field to another vault entry.
My workaround for both of these scenarios today is to have a folder named “Contoso.com” that contains all the vault entries which share the credential, so that when password change time rolls around, I can work my way through the folder, rather than go hunting through my entire vault.
1 Like
For the benefit of anybody who’s not aware of it, there is a separate feature request for this, here:
It is not possible to simply store multiple URLs in the saved login?
Note: As the (former) title somewhat suggested, that it wasn’t possible to store multiple logins for the same website (“Allow multiple logins/passwords for the same website”), I updated the title to better reflect the actual request.
(and obviously, it is already possible to create multiple login items for the same website)
If you mean this feature request as a whole, it requests more or less the opposite: to store multiple usernames, passwords etc. for let’s say the one same URL in one login item…
To be clear, in Bitwarden, it is possible to store (and autofill) multiple URLs/URIs for a single login item (which holds a single set of login credentials).
As noted by @Nail1684 above, this feature request proposes the opposite: storing multiple sets of credentials within a single login item, so that all credentials share the same set or URLs/URIs.
I understand. That would make the list of saved login data shorter and clearer.