Master password exposed on web vault

[anonymous1184]

Accessing the settings in a web browser with the extension installed and auto-fill activated exposes master password in Master password hint field.

Is filled correctly in Change Email but not filled in Change Master Password or Encryption Key Settings. Also, is not filled when clicking the View Recovery Code button or managing 2FA options.

Currently is not auto-filled in the 3 Danger Zone options and most likely should remain like that.

[mprasil]

If I understand this correctly that would imply that you have your master password stored in your Vault which sounds like bad idea. Is that what you do?

[anonymous1184]

BW is a password vault (id est stores passwords). Judging which ones are "good idea" or "bad idea" to have is not its purpose. Is exactly the same storing BW own password and codes to launch Skynet.

If I leave the vault locked makes no difference if BW password is stored in it. If the vault is unlocked all my logins/cards/identities/notes/attachments are exposed (including BW password).

The operations I described need the password; going trough each item and copying it... not. Is it safer not having BW password in the vault? No; is it easier to retrieve information? yes (all at once instead of one-by-one).

It's the flaw per se of the password managers: as soon as you leave them unlocked you lost the supposed certainty of you being the only one in possession of them. There are still plenty of attack vectors: key loggers, man-in-the-middle attacks, people looking over your shoulder, etc... Nothing is really safe. Encryption can be broken, not even plausible deniability is fail-proof... if someone has certainty that you posses any knowledge they want, you can be forced to give that information away.

That being said... master password should not be human-readable in the Hint field if auto-fill is turned on and (obviously) BW password is in the vault. As for the others, if the goal is to avoid re-typing: it should auto-fill; if the goal is to make sure the user does not inadvertently go trough those options: it shouldn't auto-fill.

OTOH, a simple conditional in the URL field can deny storing own password (thus avoiding the auto-fill trigger, even tho password can be stored anyway).

Now... I'm sorry if I sounded bitchy. I'm a developer myself and before relaying on a product I conduct a extensive testing. I started with the CLI version and now I'm using it to fill desktop applications logins (since I couldn't with desktop versions). Now I'm stressing web vault and browser extension (simple usage on iOS version for my devices too) and I think the main developer will gladly accept non-biased input on his product rather than the "BW does not do XYZ like SuperCoolPasswordManager ProPremiumPlus version 666.42.1984".

[mprasil]

Ah sorry, I didn't mean to imply that you are wrong in storing the password in Vault, it just looks like bad idea to me and I'm really curious about the reason. I mean if you remember the password you can just enter it and if you forget it, having it in the Vault won't help you because you need the password to access it. But perhaps there's some use case I haven't thought about?

I think you're observing the consequence of Bitwarden auto filling password into a field that it thinks is password field. AFAIK there's some heuristics going on to figure this out. It's worth pointing out that auto filling the passwords is also marked as experimental feature and in the past this was common vector for malicious extracting of passwords, (talking about other password managers) so keep that in mind. Again not implying that you're doing anything wrong, but there are certain risks worth considering.

I think you can maybe work around this problem by setting more strict URL matching in bitwarden - this is why I was curious about your use case.

[anonymous1184]

In fact BW password is the only one I really care about and memorize (since all of my logins have long and complex auto-generated ones). So for me, the beauty of a password manager is not to write usernames/passwords (or switching back and forth copying them).

And I agree with you completely that is an experimental feature and strict URL matching will get rid of this, the downside is that also get rids of a crucial feature of a password manager: type them form you.

Haven't touched JS in a long time and don't have certainly is an Angular issue or the specific behavior of the browsers themselves.

WebKit don't fills the field if accessing from other section (e.g. going from tool/generator to settings/account); but if you do a page refresh (and subsequently to login) is the same as Blink; field is auto-filled leaving exposed you master password. I really dislike the heaviness of Firefox and never used Mozilla software since they stopped active development on Mozilla Suite, so I don't have any insight with Gecko/Goanna.

And I know I'm as rusty as the Titanic itself but a quick peek in the code tells me that a validation is in place, but can be derivation from is "like" password check commit.

Now is just matter of waiting input from the developer to tell us what's the intended behavior and if it'll be a TODO, Known Bug or Won't Fix item. Either way thanks for your time and for pointing out a workaround for the issue!

[mprasil]

And I agree with you completely that is an experimental feature and strict URL matching will get rid of this, the downside is that also get rids of a crucial feature of a password manager: type them form you.

I'm not sure I follow you here. It sounds like you want bitwarden to fill in the password on some other page, but not on this one? If that's the case then you could just set URL matching on pages you want to fill in.

As for the heuristics, they are kinda simple but I'd be worried to change them too much because that could actually break valid use cases on other sites. Maybe it could check for hint string in the field id or name? Alternatively the field itself could be renamed so it doesn't match the heuristics. (masterPwHint maybe?) But this would require server API change.

As a general note, I'd love to have some way to tell Bitwarden the actual field name to fill in.

[anonymous1184]

Sorry if I'm not clear... let me try again with a different approach.

Point 1

(About visible passwords)
No. Under any circumstance BW should fill passwords to the clear (NEVER fill-in a password in other than <input type="password" />). In this particular case BW's own password is revealed, but the behavior can be triggered in any site.

Point 2

(About auto-fill)
Of course as you previously mentioned an "exact match" can help but it also minimizes the effectiveness of auto-fill. In example.com/login with exact match the desired functionality (not to type or copy/paste) will work. But in example.com/changePassword you'll lose said functionality.

Point 3

(About heuristics)
Heuristics are precisely that... a hit-and-miss, there's nothing you can do to validate 100% of the cases. As of now, haven't seen anything wrong with them, I need to import another few dozens of password and test them.

Point 4

(About crosstalk)
Now, the root of the misunderstandings might be that I'm not a native English speaker... so if you want to try and have a call of some sorts (Skype/Hangouts/etc...) and further discuss this UI/UX conundrum I'm always willing to help.

[mprasil]

So if I understand you correctly, the core of the issue is your assumption that bitwarden should only automatically fill input with type="password". I think I kinda agree with you, if I follow the code correctly it's using the same logic to autofill the password and to fill the password on-click.

The commit was obviously made to enable filling some password fields that are not type password - if I had to guess it was because in reality a lot of sites use that, (perhaps with some extra CSS to make it behave somewhat similar to password type) so I'm not sure if that can be removed without causing some regression, but perhaps a slightly different (more conservative) heuristics could be used for auto filling the password?

I guess we will have to wait for Kyle's opinion on this. You got my attention with the title of this issue, I thought it's something more serious. Perhaps something like "Bitwarden should not auto-fill non-password fields" would convey the intent better?

Thanks for explaining.

[tgreer-bw]

Hey @mprasil & @anonymous1184 , can you folks perhaps start this in a thread over at community.bitwarden.com? As is true in many fields, in security there are always 1000 ways to do it, all of them being wrong to someone ;-)

But - at least in the forums you guys can raise this use-case and we can see feedback across the user base. Kyle, myself - and the rest of the team certainly appreciate it.

[anonymous1184]

10-4, closing as a bug and opened in forums.