Invisible characters being added to (at least) some password fields

twilsonco

I've come across a very frustrating problem in the current beta (1Password 7 Version 7.2.5.BETA-1 (70205001) AgileBits Beta) where invisible characters are being added to certain fields.

Here's a quick illustration:
1. Make new bank account item
2. Add dummy routing and account numbers: 123123123 and 145525336255
3. Also add new password fields with the same dummy numbers in order to better illustrate the problem.
4. Show the routing number, saved as a password field, in large type, and there are 11 characters listed, not the 9 entered, and the first and last characters are shown as empty in large type.

5. Do the same with the account number, and it shows a single invisible character at the beginning of the number

6. Copy the account number (the built-in field of the back account item, not the password field I added in step 3) by pressing the "copy" button that appears next to it when you hover over with the mouse pointer, and paste into TextMate (a fantastic text editor!) with invisible characters shown, and while it doesn't correctly show the invisible leading characters, it shows that the first digit of the account number is actually the 7th column of the pasted line (the following images show the line:column numbers as I pressed the right arrow key between screen shots. After one arrow-press it says the cursor is as column 4, then 7, then 8 when the cursor is finally between the first two digits. The two final images shows that there are 19 columns in the line even though there are only 12 numbers and no spaces or newline characters, then the final image shows 20 columns because I've added a space (the center dot).)

---, and finally -

I came across this because I was unable to paste my bank account info into a text field on a website, presumedly because it was expecting a number instead of whatever invisible character is being prepended (and appended) to these fields.

Without doing an exhaustive search through my many items, and without extensive testing of the program, I've found similar behavior (just according to the invisible characters as reported by the "large type" view. If a below field type does not have a large type view then I confirmed the problem by counting columns in the copy/pasted field content as illustrated in step 6 above) in the following places:

• account/routing number fields in bank account items
• extra password fields in back account items
• verification number fields in credit card items
• phone number fields in credit card items
• "member since" field in credit card items (this one was interesting because after copy/pasting to TextMate, while continually pressing the right arrow to scroll through the two-digit number, the column number kept increasing while the cursor was jumping back and forth. See screen capture here)
• "weight" field in drivers license item (same behavior as with the "member since" field)

That's probably enough to get you guys going. Very frustrating bug for users, but at least it's interesting! I'm happy to help with troubleshooting if necessary.

Tim

---

1Password Version: 7.2.5.BETA-1 (70205001)
Extension Version: Not Provided
OS Version: macOS 10.14.2
Sync Type: 1P account

twilsonco

Quick followup: BBEdit gave a bit more insight into the nature of the invisibles. When pasted into BBEdit, the dummy bank account number used above and copied from a new bank account item in 1Password, becomes . The symbol to the far right is the newline, but I don't know what the two invisible vertical bars represent. Here's the invisible symbol legend from the BBEdit manual:

Meanwhile, TextEdit in plain text mode simply refuses to acknowledges these sneaky invisibles, so when you paste and then scan across the pasted content with the cursor using the arrow keys, there doesn't appear to be any extra characters at all, but I assume that's just because of preprocessing TextEdit does before inserting the pasted content.

I suppose I could write up a python script or something that I could paste into to view the ASCII or unicode values of the characters, but I'll leave it to you guys!

rudy

@twilsonco,

These items were created in 1Password for Mac and not imported or synced from another platform into 1Password for Mac? I did notice that the wifi password i pasted into an item for the cruise ship had two whitespace characters before it. I don't think anything changed in that logic recently but we'll take a look next week to see what we can find.

twilsonco

@rudy, Except for a brief period where I attempted to escape the walled garden and was using 1Password on a Windows 10 machine, I've always been a 1Password macOS/iOS user, and I believe that all of my items were created on either macOS or iOS.

Regardless, the MWE I gave in the OP involved creating a new bank account item in the macOS beta logged into a 1P account. I haven't tested with local vaults or on iOS, since most of my editing/creating in 1P is done in macOS.

twilsonco

I forgot to point out that, apparently, for all the password fields that are affected by this problem, the positioning of the characters in the large type window is off. To me, it appears that the width of the large type window is being determined by the correct number of characters in the password, but then it shrinks the width of each column in order to make room for the invisible characters. I can only speculate as to why the characters are then not centered in their respective columns.

Here's a verification number in a test credit card item showing the problem in the large type view

And here an extra password field added to the same item that is not experiencing the problem.

You can also see this happening, though less noticeably, in the large type view image in the OP.

MrC

@twilsonco @rudy

It appears the bytes sequence:

e2 80 aa e2 80 ac

is being adding, which are the two UTF-8 code points for Unicode's LEFT-TO-RIGHT EMBEDDING followed by POP DIRECTIONAL FORMATTING.

I noticed that over in this post (search for <U+202A><U+202C> which is a different way of representing the same code points).

They probably should not be appending these to password fields.

1Password 7
Version 7.2.5.BETA-1 (70205001)
AgileBits Beta

thightower

Just noticed this today, filling a checking account routing number.

Mine filled part of the routing (first 7 characters) and then filled the (final 2 characters) in the account number field. The account number required a retype verification. It filled those last 2 in both boxes.

7.2.5 b1

ag_kevin

Hi @twilsonco and @thightower ,

I'm going to raise an issue with the dev team to look into trimming non-printable characters when pasting into a password field. Thanks for bringing it to our attention.

Cheers,
Kevin

ref: apple-3078

twilsonco

Thanks @ag_kevin ,
Please don't forget to trim before rendering the large type view as well!

And Thanks @MrC for posting the character values.

ag_kevin

Hi twilsonco,

Yes, we'll likely trim during pasting the password into the field, so it'll be saved without the control characters.

Cheers,
Kevin

Erik_NL

Hi, I have experienced the same problem (1P 7.2.5-BETA 1) with a log-in account number fields at two banks in the Netherlands.
After reading this article I re-installed 1P 7.2.4 and the problem was vanished.

tdotpawel

I also have the same issue with several bank account logins. Glad I came across this thread. Re-installed the latest stable version 7.2.4 and it's working fine now.

sfiske

Same problem with me. This started happening about a week or two ago. All of the 1Password entries that I created manually (with the "+" sign) do not work. All of the 1Password entries that I create with the "Save New Login..." work. When I figured this out, I just went back to the logins that I created in the past 2 weeks and logged back into the websites and selected "Save New Login...." to get them to work again.

Something else strange that I noticed is that under Preferences > Browsers > Autosave, if I uncheck the box "Detect new usernames and passwords and offer to save them", the box will automatically recheck itself if I completely close the Preference window and then reopen Preferences and go back to the Browsers header. I have never had this setting checked because I like to enter in the entries manually. Maybe this setting rechecking itself automatically may have something to do with it?

mirv

Aha! This problem prevented my rent from being paid this month on time. Luckily the landlord was forgiving since we didn't know why the account number was being rejected, and he had the IT people working on it. I finally figured out that typing in the account and routing numbers manually got the payment to be accepted!

I should add the specifics. I am running 1P beta 7.2.5 on my Mac, and I copied and pasted the routing and account numbers from a Bank Account entry in the main 1P app to the input fields in my browser. Obviously they must have had these control characters in them.

rudy

We'll have a 7.2.6 beta up shortly that addresses this behavior, you'll need to edit/modify/save those items to get it to clear out those control characters.

mirv

How do I know which items have invisible control characters????

ag_kevin

Hi @mirv ,

From what we've seen, it only affects numeric digit-only passwords, phone number fields, that were saved/edited in the last couple of beta releases. You can see it by choosing the "Show Large Type" option on the password, as shown in twilsonco's screenshots above. If there are spaces in front or at the end of the password, then you know it's happened there. Simply edit the password and backspace over the invisible characters, or paste the entire password in a text editor, copy back only the visible digits, and save.

Regards,
Kevin

MrC

Hmmm, this doesn't align with what I saw:

ag_kevin

Hi @MrC,

It appears I left out a condition. Sorry about that. We went back and checked the code. Here are the circumstances where those formatting characters would have been used:

1. Display of Credit Card numbers
2. Phone number fields
3. Fields (not just password fields) where the field was saved as blank, or only consisted of numeric digits.

So MrC, from the looks above, those fields were blank when the item was first saved, and then changed later. That also explains why those unicode characters appear at the front. Had that been a numeric-only field, the second unicode character would show up at the end.

Cheers,
Kevin

twilsonco

@ag_kevin, as a big fan of avoiding boring repetition, I loath the prospect of having to manual comb through my entries to remedy this. Is there some good reason that these invisible characters should ever appear in a password field? If not, isn't this something that can and should be programmatically?

ag_kevin

Hi @twilsonco ,

We're looking into the best way to remedy the situation. There was a reason for the characters, but for display purposes only. The bug is they got saved with the data.

Cheers,
Kevin

twilsonco

@ag_kevin Understood.

rudy

@twilsonco,

:) :+1:

mirv

Hm, I have over 2000 items in my vault. I will need some type of program to sanitize all of the fields in each item, if it is really corrupted like you are saying. Do these characters get synced to my iOS devices as well as the Macs?

ag_kevin

Hi @mirv,

No, you will not need to sanitize the fields for all of your items. It only affects items where the data was altered and saved during the previous couple of betas. So it is likely very few items were affected.

As I mentioned above, we are investigating the best way to fix it. We expect it to have that available for the next beta. So any items that had those codes saved in them, will be taken care of. Currently, we expect that it will not require any action on your part.

Cheers,
Kevin

verdi1987

@ag_kevin, this issue also occurs in the "cardholder name" field.

rudy

@verdi1987,

Thanks for the info. We're not restricting the clean-up fix to a specific item type, or specific fields.