Weird UI behavior in native app

gabrieljcs

I have encountered a few quirks when using the macOS native app, although definitely not breaking issues:

1. Besides not being fully translated, the buttons in the Import dialog are reversed, i.e. to change from "LastPass" to "From File" I need to click in the "LastPass" button instead of the "From File" button. The same happens when changing from "From File" to "LastPass". I tried quite a lot of sliding behaviors before realizing this, so definitely confusing.
   

2. The login password field will not fill accent glyphs when hidden. When the password is being shown, all characters work, but if the user types while hiding it will not be written, although the character itself will be drawn. This behavior isn't seen in the browser (I only tested in Firefox). It obviously causes a lot of confusion as well.
   

---

1Password Version: 1Password for Mac 8.10.0 (81000055)
Extension Version: Not Provided
OS Version: macOS 13.1
Browser:_ Firefox

andrew.l_1P

Hi @gabrieljcs,

Thanks for surfacing these! The switch on the importer is on our radar I look forward to seeing that improved, I also spent quite a bit of time clicking and dragging when I first came across it. 😅

Regarding accent glyphs, could I confirm exactly how you're entering these characters? I was able to reproduce something similar with the input method where you use a certain key combination to type an accent, and then you can press a letter to "complete" the character, in which case it seems the hidden view isn't recognizing the accent. Let me know and we'll go from there!

ref: dev/core/core#19687

gabrieljcs

Hi, @andrew.l_1P,

Yup, that's it -- now I realize it's probably also related to my keyboard layout. Although my physical keyboard is American, (well, Canadian actually, eh (: ), my layout is set as "Brazilian", so all accent keys present the behavior of "waiting" for the next key, because I can join, for instance, ' with c to get ç (which would be a physical key in Brazilian keyboards).

So if I write any accent while the password field is hidden, only the next key will be written instead. I think the main culprit will be the apostrophe in non-American keyboards because of this behavior -- it always waits for the next letter in my case -- but I can see how any other accentuated letter will have the same issue.

andrew.l_1P

Thanks for these details, @gabrieljcs! Setting my device input language to Brazilian I was able to reproduce the same thing. Input inconsistencies like this are why we generally discourage using any special characters in passwords: Should I use special characters in my 1Password account password?

If you'd like to read more about how or whether this impacts the security of your account, I recommend this post from our own Principal Security Architect: Do accented characters (ç ñ é à) add more entropy to passwords than regular special characters (# $ % &)? - Quora

All that said, I can certainly see the merit in wanting the obscured and unobscured versions of the password field to be consistent and I'll share our thread here with the rest of the team so we can explore ways to improve the experience.

If you do end up updating your account password, remember to update your Emergency Kit as well. Let me know if you have any questions. 🙂

gabrieljcs

Thank you, @andrew.l_1P .

I actually don't have any accented characters and the issue is from a standard ASCII accent listed in the link (not Latin exclusive, either, I've used it in this phrase).

In any case, I appreciate the time you took to check and respond to this. Like I said, definitely not a breaking issue, maybe just displaying a warning when the keyboard is non-US would be enough.

gabrieljcs

@andrew.l_1P found something else...

I'm having the same password showing as different strengths. One is imported from .1pux file and the other is from a KeePassXC .csv.

I checked both of their SHA256 by pressing the "Copy" button in the app interface and running through macOS' default shasum and they match, so there's definitely no extra characters being added or changed (although I'm not really willing to show it, you'll just have to take my word for it).

Happened to several different passwords and strengths -- would guess all of them, actually.

Kind of leads the user to think the passwords are different when they're not, but again, not really a breaking issue.

GreyM1P

@gabrieljcs

The password strength can be shown as different, for different generation methods. If 1Password knows that it's generated the password, it knows the password is truly random, whereas if it's come from somewhere else, the algorithm could be different, or even human-generated.

Try this to show this in action:

1. Create a new test item, and use 1Password's secure password generator to create a sample password that just about fills the password strength meter. Save the item.
2. Edit the item, then add a character to the end of the password, and remove it, so that the password is identical, but now human-edited.
3. Save the item, and see the difference in the strength meter.

Because the password is now not purely generated but human-edited, it's treated as slightly weaker, even if it's identical to the generated version.

I hope that helps explain why this happens. If you have any questions, please do let me know. :)

gabrieljcs

Thank you so much, @GreyM1P -- that makes a lot of sense!

GreyM1P

@gabrieljcs – You're welcome! :)