Option to only fill the password field?

[Djhg2000]

General information

• Operating system + version: Debian Sid
• Browser + version: Vivaldi 3.8.2259.42 (Stable channel) (64-bit)
• Information about the host app:
  • How did you install it?
    Installed via Debian package manager (webext-browserpass 3.7.2-1+b1) and ran make hosts-vivaldi-user as per instructions
• Information about the browser extension:
  • How did you install it?
    Installed via Debian package manager (webext-browserpass 3.7.2-1+b1)
  • Browserpass extension version as reported by your browser: 3.7.2

---

Exact steps to reproduce the problem

1. Fill in username

2. Click the BrowserPass extension button

3. BrowserPass starts filling out login details

What should happen?

If the password file doesn't contain anything but a single continuous line it's probably just a password (as generated by pass generate [filename]). There should be an option to respect this behavior. I append _username to the files that actually contain a username (and _seccuritytoken for security tokens, etc.), and most usernames I simply share across multiple sites where I don't mind connecting the identities (like Steam and GOG). Alternatively don't fill the username field if it isn't empty (might cause conflicts with sites that populate the field with "username" until clicked?).

What happened instead?

Depending on the currently set options, the username will either be filled with the filename or the default username. There is no option to only fill in the password field and leave the username field as-is.

[max-baz]

Hello! To clarify, did I understand correctly that you configured a default username in extension options, but you don't want that username to be filled? If so, that option is specifically to make sure username is always entered.

One approach I can suggest you is to split your password store in subfolders, one with entries that you want to have a default username for, another for entries where you don't want to have default username. Then set default username only for one subfolder, either via extension options or via .browserpass.json in that subfolder.

Let me know what you think!

[erayd]

There is no option to only fill in the password field and leave the username field as-is.

Browserpass does allow you to set an empty username in whatever file you don't want a username entered for (see #232). This achieves exactly what you mention above - i.e. it will fill the password, and leave the username field untouched.

[Djhg2000]

Hello! To clarify, did I understand correctly that you configured a default username in extension options, but you don't want that username to be filled? If so, that option is specifically to make sure username is always entered.

One approach I can suggest you is to split your password store in subfolders, one with entries that you want to have a default username for, another for entries where you don't want to have default username. Then set default username only for one subfolder, either via extension options or via .browserpass.json in that subfolder.

Let me know what you think!

I tried configuring a default username in the options after I found it always replaced the username field with the password filename, which was a slight improvement (correct some of the time instead of never) but still not ideal.

There is no option to only fill in the password field and leave the username field as-is.

Browserpass does allow you to set an empty username in whatever file you don't want a username entered for (see #232). This achieves exactly what you mention above - i.e. it will fill the password, and leave the username field untouched.

No, if I leave the default username blank it will still always fill in the username field but it will use the filename the password is stored in. For instance, I have the password for Steam stored in "Games/Steam", so when I click the BrowserPass button it fills in "Steam" in the username field and fills in the password in the password field.

This happens even if I fill in my actual username before clicking the BrowserPass button. Is this a bug then?

[max-baz]

Ah right, I remember now. Yes we intentionally fallback to file name. To disable that, inside your password entry file set user: (with empty value).

[erayd]

This happens even if I fill in my actual username before clicking the BrowserPass button. Is this a bug then?

No, this is not a bug. If you want to disable filling the username for a particular file, you need to set an empty username inside that file. For example:

myAwesomePassword
login:

If you don't explicitly set an empty username in the file, then it will try to obtain the username from elsewhere, and fill that. The username selection behavior is documented in this section of the README (point 3).

[Djhg2000]

Ah right, I remember now. Yes we intentionally fallback to file name. To disable that, inside your password entry file set user: (with empty value).

I'd rather not do this for my entire password store since it will affect my normal workflow outside BrowserPass. What I'm asking for is a way to change the fallback into behaving as if BrowserPass had seen an empty user: string when there isn't one.

This happens even if I fill in my actual username before clicking the BrowserPass button. Is this a bug then?

No, this is not a bug. If you want to disable filling the username for a particular file, you need to set an empty username inside that file. For example:

myAwesomePassword
login:

If you don't explicitly set an empty username in the file, then it will try to obtain the username from elsewhere, and fill that. The username selection behavior is documented in this section of the README (point 3).

Correct, what I want is an option to behave as if that was the case without modifying my entire password store.

[erayd]

Correct, what I want is an option to behave as if that was the case without modifying my entire password store.

Can you expand a bit on your use-case for this feature request? Wanting to fill a password, but ignore the username field, is quite an uncommon thing to do, so wanting to disable it for your entire store seems like quite a strange request.

What is the login workflow that you are trying to achieve here?

[Djhg2000]

I have a few places where I need to pipe the password directly to another tool. Adding other data, or even just a newline, into the password files would break those. It's why I use separate files for auxiliary info in the first place and usernames fall into that category for me. In this scenario, pass [filename] works exactly the way I want it to with the key unlock presented in a native GPG prompt and then the password is emitted completely transparently on stdout into wherever I need it.

Which is why the current behavior in BrowserPass is a problem for me. I mainly store just the passwords as basically plain strings in my password store, while BrowserPass assumes the files follow a particular structured format. Since migrating to that structured format would be a very disruptive change, I'd rather take the path of least resistance and have BroswerPass handle plain single line files in a nicer way.

[erayd]

I have a few places where I need to pipe the password directly to another tool. Adding other data, or even just a newline, into the password files would break those.

I'd rather take the path of least resistance and have BroswerPass handle plain single line files in a nicer way.

Is there a reason why something like the following isn't suitable? I'm reluctant to add such a niche feature to Browserpass when your use-case appears to be trivially solvable.

pass show projects/browserpass/login/example.com | head -n 1 | tr -d '\n'

$ myOtherCommand --with-password=$(pass show projects/browserpass/login/example.com | head -n 1 | tr -d '\n')

Or if you wanted just a single-word command, this could be easily done as a single line script:

#!/bin/sh
pass "$@" | head -n 1 | tr -d '\n'

$ myOtherCommand --with-password=$(pass-single-line.sh projects/browserpass/login/example.com)

[Djhg2000]

Well sure there are workarounds, but I don't think using pass generate [filename] to generate passwords as per the manual is a niche use case?

Honestly, I don't see what the big deal is here. It's clear to me that pass was (at least initially) designed to have passwords stored in single line files by default and the built-in clipboard feature even required it until version 1.2, and required it was the first line until version 1.7 when you could select which line should be copied into the clipboard buffer.

It's not exactly an undocumented use case we're talking about here, it's even explained in the first paragraph of the DESCRIPTION header in the manual:

DESCRIPTION
       pass is a very  simple  password  store  that  keeps  passwords  inside
       gpg2(1)  encrypted  files  inside  a  simple directory tree residing at
       ~/.password-store.  The pass utility provides a series of commands  for
       manipulating  the  password  store,  allowing  the user to add, remove,
       edit, synchronize, generate, and manipulate passwords.

[erayd]

I don't think using pass generate [filename] to generate passwords as per the manual is a niche use case?

It's not, but this isn't what you are asking for here. You can already do that just fine.

The niche part is where you're asking us to modify Browserpass in order to cope with a very uncommon scenario (namely, having an entire password store of single-line files, and wanting to not fill usernames). That workflow is extremely rare; as a general rule, people who autofill a password into a login form also want the username filled. Manually typing them removes much of the utility of a web browser password manager.

Honestly, I don't see what the big deal is here.

We try, very deliberately, to keep the number of settings to a minimum. This makes it easier for users to learn, and reduces the support & maintenance load.

If there's a compelling reason to add something, we generally do - so you are welcome to try and convince us that your feature request is a good enough idea to warrant another setting. However, please note that it does need to be compelling; if we implemented every option that was suggested to us to address someone's individual odd case, the UX would be a complicated mess.

[Djhg2000]

I don't think using pass generate [filename] to generate passwords as per the manual is a niche use case?

It's not, but this isn't what you are asking for here. You can already do that just fine.

The niche part is where you're asking us to modify Browserpass in order to cope with a very uncommon scenario (namely, having an entire password store of single-line files, and wanting to not fill usernames). That workflow is extremely rare; as a general rule, people who autofill a password into a login form also want the username filled. Manually typing them removes much of the utility of a web browser password manager.

That works as a general rule but using pass as the backing password store is an uncommon scenario to begin with, especially with non-default file contents, so I don't think that's a very strong argument against it. I also disagree on that not filling usernames removes much of the utility of a web browser password manager. What you're describing is a web browser identity manager. Managing identities is certainly possible with pass (as demonstrated with BrowerPass) but it's not its main feature.

Honestly, I don't see what the big deal is here.

We try, very deliberately, to keep the number of settings to a minimum. This makes it easier for users to learn, and reduces the support & maintenance load.

If there's a compelling reason to add something, we generally do - so you are welcome to try and convince us that your feature request is a good enough idea to warrant another setting. However, please note that it does need to be compelling; if we implemented every option that was suggested to us to address someone's individual odd case, the UX would be a complicated mess.

Personally I don't even need a UI option here, I'm fine with modifying config files. But adding a small checkbox called "Fill username" (checked by default) shouldn't add much clutter either. I also have to ask; how common of a use case is it to have the username as the file name? Because to me that sounds like encouraging shared passwords across sites, which is a very bad thing security-wise.

[erayd]

...using pass as the backing password store is an uncommon scenario to begin with

This is why Browserpass exists. To bring a common browser workflow (logging into things with a secure credential store) to a non-browser credential store (gpg files on disk).

I also disagree on that not filling usernames removes much of the utility of a web browser password manager. What you're describing is a web browser identity manager.

You are arguing semantics, poorly. The primary function for most browser-integrated products categorised as "password manager", is using saved credentials to log into things. This includes usernames. Whatever you wish to call it, this is very much what Browserpass is intended to do, and what most of our users use it for.

But adding a small checkbox called "Fill username" (checked by default) shouldn't add much clutter either.

It does, actually - another option is enough to overflow the options viewport on some platforms.

...how common of a use case is it to have the username as the file name?

Extremely common. path/to/example.com/username (with the password on a single line within that file) is the organisation style where that approach is typically used.

Because to me that sounds like encouraging shared passwords across sites, which is a very bad thing security-wise.

No idea where you got this one from, but it's incorrect. How people choose to organise the layout of their password store has nothing to do with encouraging or discouraging the reuse of credentials.

I suggest you also take a look at our anti-phishing features; while preventing reuse isn't the primary point of them, it is a handy side effect.

---

Ultimately, I'm still not seeing a strong argument in favour of adding this option. As it stands currently, there is nothing about Browserpass which prevents a "fill password, then type username" style workflow (which appears to be what you want to do), and there are already existing mechanisms for extracting the first line of a multi-line file.

I am going to close this issue now, as it feels like we aren't making any progress here towards establishing a good case for it. However, if you do have a strong, compelling argument in favour of adding this feature, please feel free to post it below.