clients
clients copied to clipboard
bitwarden
If master password has an accent, you need to toggle visibility to add the accent to the password
Steps To Reproduce
- Click the Bitwarden extension icon
- Try to enter a master password that contains an accent, for example `à``
- Password is considered incorrect
- If displayed in clear text, the accent is not there
Expected Result
We shouldn't toggle visibility when entering the master password, for privacy reasons.
Actual Result
You have to display the master password in clear text to add the accent.
Screenshots or Videos
No response
Additional Context
No response
Operating System
macOS
Operating System Version
No response
Web Browser
Chrome
Browser Version
No response
Build Version
99.0.4844.83
Hi @richardsd, we took a look at this and were unable to reproduce this issue on the Mac Chrome browser extension using "à" in the master password, on the latest production release. If you haven't yet, please update your extension to v1.57.0, then reopen this ticket and let us know if you're still seeing this issue. Thank you!
Hi @Larry-Sussman, I can confirm I'm reproducing this issue on my Mac running macOS 12.3.1 with the Desktop version of Bitwarden.
Here's a recording of the bug.
https://user-images.githubusercontent.com/10114131/171009214-c813df6b-6ad5-4ea6-938a-7d8d5099e532.mov
You can clearly see I'm trying to type in characters such as ê î ë ï and it only works when the visibility is toggled.
Let me know if you want me to open a new ticket regarding this (rather annoying issue).
macOS 12.3.1 Bitwarden Version 1.33.0 (2645)
Hi @richardsd, we took a look at this and were unable to reproduce this issue on the Mac Chrome browser extension using "à" in the master password, on the latest production release. If you haven't yet, please update your extension to v1.57.0, then reopen this ticket and let us know if you're still seeing this issue. Thank you!
@Larry-Sussman thank you so much for the feedback on this. I continue to see the problem with version 2022.6.0 on MacOS 12.4 and Chrome 103.0.5060.114.
Let me know if there's anything else I can provide you to help. Thanks.
@richardsd, thank you for following up on this! I was ale to reproduce this on the latest release of browser-v2022.6.1
@ggrelet, thank you for the information about this also affecting Desktop! It looks like this bug is affecting Web, Desktop, and Browser.
I am re-opening this issue and will get it added to our backlog for a fix.
@richardsd, thank you for following up on this! I was ale to reproduce this on the latest release of browser-v2022.6.1
@ggrelet, thank you for the information about this also affecting Desktop! It looks like this bug is affecting Web, Desktop, and Browser.
I am re-opening this issue and will get it added to our backlog for a fix.
@Larry-Sussman no problem at all. Let me know if there's anything else I can add or test that can help. Thank you.
This problem has existed for a year. I reported it to bitwarden support on 25 August 2021:
A few weeks ago, you updated the Chromium (desktop) extension and introduce a bug to the master password input field whereby letters with diacritics are replaced with their non-decorated / plain value, unless the input field is toggled to display the text being entered (which is obviously insecure).
And I also attached a screen recording of the easily reproducible problem (which support also claimed they could not repro; they clearly had not tried, and their response was clearly canned).
just adding here that this issue does not seem to affect Windows. it might be macOS-specific
just adding here that this issue does not seem to affect Windows. it might be macOS-specific
I confirm that this issue seems macOS-specific. I tested it on my Windows machine and everything seems to be working.
This seems to be an upstream issue. I replicated it in a regular chromium instance and found the following bug report for Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=1330916.
This needs to be fixed in Chromium, and once Electron has updated we can update to that Electron version.
@Hinton thanks for looking into this!
That does indeed seem to be it 🤯 https://jsfiddle.net/JakobJingleheimer/yjseg219/
https://user-images.githubusercontent.com/3012099/190682561-f0839843-6b4d-46e1-8b3c-7408e14fbe0c.mp4
(the és that get printed are the initial value of the field; the es are the result of entering é)
Bug title says "master password", but this applies to stored hidden values in the vault too.
I was about to create another issue, but this seems to be the same problem, so here's my input from another perspective (TLDR: accent modifier keys can also be used to type the related special character and they can't be entered in the password field too):
While helping family members to migrate I stumbled on the problem of not being able to actually enter certain characters in the master password field, in the Mac desktop app. A certain character could not be entered in the password field, without activating "show password". After activation the character could be entered normally. I tried several other ones and found the following list of character not working (hide password):
Characters: ´ (key on German keyboard) ` (shift - the one above) ^ (key on German keyboard, or option - shift - 6) ~ (option - n) ¨ (option - u) (Note: they can be copied into the field just fine, but they can the typed.)
They all are modification keys for accented characters. But each can be a simple single character too.
All listed not working special characters (except ´) can be directly entered in the web interface, without activating "show password".
Basically all other combinations with option and shift keys seem to work fine in the desktop app.
So, is my assumption correct, that this MacOS native app has some other limitations on the input than the web app (and probably all other native apps)? If yes, is there a streamlined common ruleset for master passwords, so they work on all clients? I would guess not, because otherwise I would not have encountered the problem.
Wouldn't it make sense to apply the same limitations to the master password ON creation, so it WILL work everywhere?
Doubling down on the last line, knowing now that this issue is documented since at least Jan '19 (#2632): shouldn't there be at least a note in the UI, indicating that passwords with the (at least) 5 characters and characters modified by them can lead to problems on some clients?
The upstream bug in Chrome is open and untriaged, meaning the Chromium team have so-far ignored it. If you want progress on the issue in Bitward, pester the Chromium team 😉
the following bug report for Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=1330916
In Firefox it is possible to unlock BitWarden extension and enter diacritics without toggling visibility
In macOS 14.2.1 w/ Safari 17.2.1 it is not possible to unlock the BitWarden extension when the password contains diacritics and the password fiels is invisible
@NeoRey73 please stop spamming this thread. As you can see within this very post, the issue is caused by an upstream bug in Chromium/webkit and there is nothing Bitwarden can do.
@JakobJingleheimer sure, no problem. Sorry for the frequent postings.
But can you please explain what Chromium has to do with diacritics not working in the macOS BitWarden desktop app, the Safari extension and how it does work in the Firefox extension?
The desktop app is (I haven't checked, but would bet) an Electron app, which is a Chromium wrapper. Many desktop apps do this (ex Slack).
The issue is rooted in a flaw in Chromium's <input type="password" />, which was introduced around August of the post I made some years ago (I believe I cited the Chromium bug report, which they've acknowledged but haven't bothered to fix). It would be easily pinpointed if they so cared.