Login to sites that obfuscate the login
For quite a while for me, 1Password has not been able to login to sites that obfuscate the login. That is, 1P properly fills the fields, but the site rejects the login because of a conflict with the obfuscation. For example, the site expects the username to look like ja****n9, but it looks like jasimon9, which is my username.
The result is that on such sites I have to type in the username, which then gets obfuscated, and I am logged in. This has been the case for at least a couple of years.
What I am bringing to your attention is a recent change at one such website, citibank, where 1P fills the fields properly, the login gets obfuscated, and the login succeeds. Naturally this is not a problem I am reporting, but an improvement in the combined behavior of the website, the browser and 1P. Something has changed, and I thought you should know about it, whether it was due to your efforts or the efforts of others.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Hey @jasimon9,
Thank you so much for letting us know - this is great news. Citibank has certainly been a troublesome login for 1Password to deal with. I'm not a City customer so can't test this myself however luckily @brenty is. In the past brenty has provided a nice workaround for how to use 1Password with Citi for the last known way to get things to work but hopefully things will work better now.
I suspect this is due to a change in Citibank's website itself. It would be great to know which web page from the Citibank website you have tested with so that we can tell others about your discovery. :chuffed:
Best regards,
Matthew0 -
It seems when I go to the site via the 1P login, it fails as in the past. But when I link from an address in an email (first verified by me to be an expected URL), the obfuscation/login works.
By the way, the 1P login has two websites in it. How does that work? The first website is https://creditcards.citi.com/; the second website is https://accountonline.citi.com/cards/svc/LoginGet.do. How does 1P handle this? Does it just pick the first one, and if that fails try the second one? What is the algorithm?
In any case, when I try to login using 1P, there is a redirect so that neither of those URLs appear in the address bar. Instead the first thing that appears in the address bar is https://www.citi.com/credit-cards/citi.action. No doubt this complexity is part of the problem. Yet we are only getting started with the complexity.
The link in the email starts with https://fm.info6.citi.com/ats/url.apsx?plus-a-long-query-string-here-that-likely-encodes-something-about-my-account. Yet that also redirects; in this case to https://www.citi.com/credit-cards/citi.action. What happens step-by-step is the following:
- Click on the link in the email after observing the domain citi.com is trusted.
- Gets redirected to https://www.citi.com/credit-cards/citi.action where there is a login page.
- Use my normal 1P login to login.
- Username populates for a fraction of a second, then is automatically obfuscated.
- Login proceeds.
Because I have been aware of the obfuscation issue for probably several years, I am used to having the populated, non-obfuscated login rejected, and then just typing it in. So when this new behavior started happening recently, it really stood out. Thus my desire to share with you about it.
0 -
In the above, "use my normal 1P login to login" means "click on the 1P mini icon in the browser, then click on my normal login".
0 -
Did someone say "Citibank"? :lol:
@jasimon9: Thanks for bringing this up! Let me know if I'm right about this:
@matthew_ag: I think this might be it. It isn't superficially different, but I do believe it was previously blanking out the username after 1Password filled it.
0
