Field References (Ability to set different usernames for different websites using the same password)

I second this, and I also wanted to propose a slightly different solution.

Besides the option to just link fields between separate entries (the KeePassXC method), I suspect most of the use cases for this feature could actually be covered with a much simpler, less disruptive implementation.

Ability to specify different usernames per URI

When specifying multiple URIs for a single entry, add the ability to specify a custom username for each of the URIs as well.

Feature function

  • What will this feature do differently?

Adds the ability to specify different usernames per URI to the same vault item.

  • What benefits will this feature bring?

There are situations where a single user account, with a single password, requires different usernames depending on the platform where the login is being done. Today, we need to have a separate entry for each username. This not only clutters the vault, but also makes it harder to maintain as we need to update the password in every different entry whenever it changes.

Example Use Case

In corporate environments where each employee has a personal account to access all systems company-wide, it’s very common to require different usernames depending on where the login is being done. E.g.: some cloud-based systems may require the full email address ([email protected]), whereas some on-prem systems may require a shorter, local username (john.doe), and others may even require a prefix with the domain the user is logging into (e.g: //ROOT/john.doe).

Today, we need to create a separate entry for each of those usernames, even though the password is common across them. Additionally, corporate environments typically require their employees to update their passwords very frequently, which further exacerbates the problem as it makes it tedious to manually update each of the entries one by one.

A very simple solution could be to add an (optional) setting whenever we add a new URI to an entry, where we can also specify a custom username that’s different from the default username in this entry.

So for a single entry, we could have:

  • Username + password
  • URI 1
  • URI 2 + username 2
  • URI 3 + username 3
  • etc.

For those URIs where no custom username is provided, the default one is used of course.