Strange behavior on Social Security Site
Hi, logged into the following website, and observed strange behavior with the user ID.
https://secure.ssa.gov/RIL/SiView.action
My user ID format is : AaaaaAaaaaaa
When 1Password submits the log in credentials, the user ID is transforming to : AAAAAAAAAAAA
The user ID appears case sensitive, so the log in event fails. If I manually copy in the credentials, the log in succeeds.
Is this case transformation happening because of 1PW behavior or is the website doing this to the supplied user ID?
1Password Version: 6.8.9
Extension Version: 4.7.3.90
OS Version: OSX 10.13.6
Sync Type: Dropbox
Comments
-
Hello @Superfandominatrix,
As you kindly supplied the URL I've tried to reproduce the bad behaviour but so far been unable to do so. Certainly 1Password doesn't ever perform any form of transformation on values being filled with Login items so my observations were in line with what I'd hoped to see. Can you try saving an entirely new Login item for me please using the steps detailed on our support page How to save a Login manually in your browser and see if you find things behave better.
0 -
Since reporting this issue, I've upgraded from 1PW6 to version 7. That behavior seems to still be happening in the new version. Other weird stuff is happening...
For some reason, the migration of login in data from 6 to 7 went a bit wonky for https://secure.ssa.gov/. Website addresses were turned into field titles, and the website address was left blank. Because the web address was a field title, 1PW7 did not recognize that I already had this log in entry in my vault and prompted me to save a new login entry. I was able to successfully log in, but the new login in entry was truncated and not the full password supplied to the website.
Original 1PW6 password length: 25 characters
1PW7 new login entry captured today: 20 characters (the 25 character password truncated to 20)I can still log into the website with the 25 character password. Also seems like I can log in with the 20 character password. This all said, the new log in entry does not seem to cause the user ID to convert to all caps.
0 -
Edit: Looking at the first SSA login entry, I noticed a strange field called "user id disambig" with a data type of text. This field appears under the NOTES section. (Clarification: apparently the NOTES section is a user created section, not the actual 1PW notes section.) The content of this field is my user ID transformed to all upper case, like: AAAAAAAAAAAA.
Would this field cause 1PW confusion in the autofill process?
0 -
Hello @Superfandominatrix,
So moving from 1Password 6 to 7 shouldn't have altered the items at all. I can't explain what happened there and this is the only report I'm aware of.
If you entered a 25 character password but 1Password only saved 20 the site must have truncated it after you pasted. It would also explain why you find you can log in with just the first 20 characters if the site is actively doing this. I don't know if they changed their limitations at some point or if it's always been truncating your password.
I can't think what would have caused 1Password to add anything to the note field either. If there are conflicts when merging during sync 1Password would create custom fields in a custom section titled conflicts. The only items of mine with notes are ones where I know I've explicitly added a note, usually to record password limitations for future reference or backup codes after enabling 2FA. The note section shouldn't be impacting on filling either because if memory serves me correctly that entire section was never sent to the code that performs the filling just as it also ignores custom sections and fields.
There are a few puzzles here but I'm not sure if we'll find satisfactory answers. If a new Login item is working that may be the best we can hope for at the moment. Of course if you continue to see odd behaviour please let us know.
0 -
@littlebobbytables Thanks littlebobby~
So I went with your suggested route of creating a new login in entry. What happened next, I need to test again. So on the 2nd log in, I had to migrate information from the first account to the second (example, secret question and answers, info about where SSA gets your home address from, 2fa info, ex.). If I'm groking what I'm seeing correctly, the second account now is behaving as the first.
Don't worry about this for now, I need to attempt creating a 3rd login entry to see if I can recreate the problem a 3rd time and if yes, exactly where in the change process the problem starts to occur.
Sorry for the troubles.
0 -
Please do keep me informed. I tried saving a new Login item today and tested filling both it and one I created back in October when you first reached out to us and everything seems to be working. I don't have a real account to test but on the surface it looks like 1Password is doing the correct things. I will be very interested to learn what you discover and whether we can pin this down at all.
0
