Password length conflicts when sites limit length.

hawkmoth

Even though I am using the beta versions, I don't think this is a beta issue, so I put it here. If that's wrong, I won't be insulted if you move this post to the beta forum.

Sometime ago there was a discussion about a web site that limits the number of characters that can be used for logging into the site. But when the user engages the password generator from 1Password to make a new password, the site appears to be content to accept the new password, even though it exceeds the number of characters permitted. It's only when you return to the site and attempt to login via Cmd-\ that you discover that the new password actually is unacceptable. Your attempt is rejected. I only figured this out at usaa.com by trial and error. At that time I generated another new password that met the length limits.

I've now discovered some other sites in my records that behave in a similar way, only this time with a new wrinkle that I had not discovered before. The sites are for Hertz and American Airlines. In both cases, when I attempted to log in to my accounts, I was turned back with a message to the effect that the password was incorrect. What I discovered this time was that if I went to the relevant 1Password record and manually used the copy buttons to transfer my credentials, they worked, even though if I attempted to autofill, they did not. (Now I wonder about how many unacceptable passwords I actually have. This isn't confined to just one of the sites I use. I guess I now need to audit all of my logins.)

Here is the new discovery to me. After I entered the password by copying from the record, I received a prompt from 1Password to save a new login! Even though it seemed I was entering the very same credentials manually, the application was behaving as if they were different. So I agreed to save the new record. When I compared the two, I discovered that the new record contained a truncated version of the password that I had created in the past. The last characters were omitted, but the password was otherwise unchanged. Manual pasting apparently only pasted in some of the password characters, not all of them. And this truncated version is the one the web site is accepting; I can log in successfully. Seems odd to me that autofilling with Cmd-\ sends different data to the web site than manually pasting the information does, but that's what's happening to me.

Someone advocated for 1Password to immediately test new logins against the site they were created for. Given this experience, I'd add my vote to doing that, if it could be implemented. In the future< I will be doing that myself for each new record.

These logins were created in version 3, well before version 4 came out. But for the record, today's discovery came under OS X 10.9.2, 1Password Version 4.2.BETA-10 (420010), and extension version 4.2.0.b11 with Safari Version 7.0.2 (9537.74.9).

Ben

Hi @hawkmoth‌

Thanks for reporting this issue. I agree that it is not limited to the beta.

Sometime ago there was a discussion about a web site that limits the number of characters that can be used for logging into the site.

This is fairly common practice, and there is a widely accepted standard for how web pages should implement it:

HTML input maxlength attribute

If a website deviates from this standard and uses another method of detecting the number of characters entered and prevent further entry when the max has been entered (e.x. in JavaScript) there is little we can do to detect and work within that.

If the website uses maxlength, then 1Password should detect and respect that. It appears that there is currently a bug where that doesn't necessarily happen.

1Password record and manually used the copy buttons to transfer my credentials, they worked, even though if I attempted to autofill, they did not.

I don't claim to be an expert of the inner workings of the 1Password extension (at a code level) but I can say that the extension does not use the clipboard to fill, so it isn't entirely surprising if filling and using copy & paste have different results.

Someone advocated for 1Password to immediately test new logins against the site they were created for.

I agree that is something that should happen, but I don't know how we could really automate it. There is no industry standard way for a website to report if the login attempt was successful or not. As such this will likely have to be a manual process, until such a standard arises and is adopted.

I've added a vote to our bug tracker indicating this issue is causing a problem for you. Hopefully our developers will be able to figure out how to make the generator respect the maxlength attribute again for extension v4.3. If the site is using another method of limiting input though, all bets are likely off.

Thanks for the report!

Ben