Cannot save login for U.S. Trust account page

cdp

U.S. Trust uses a 2 page sequential login at https://www.fs.ustrust.com/login/login.aspx
I was previously able to create a login that would work stored as a single saved login even though it was split over 2 pages.
I can no longer do anything that will get through the first (username) page.
If I go to the page, enter the username and then do the "manual save" method, the username disappears from the page as a side-effect of saving the login. I can manually re-enter it and proceed with a successful login, but 1password does not manage to type the username in automatically after saving the page. 1Password has successfully created a stored field containing the username, but when trying to use it you can see the username flash briefly into the text box, but it then disappears instantly and the login fails.
Enabling Auto Type doesn't seem to help either.

---

1Password Version: 4.6.0.604
Extension Version: 4.5.3.90
OS Version: Windows 7
Sync Type: Dropbox
Referrer: kb:fix-website-login, ug:windows/, ug:windows/save-login, kb:save-login-manually, kb:create-multi-page-login

littlebobbytables

Hi @cdp,

So our standard filling technique does indeed seem to have trouble with this site. We perform various actions before and after setting the value of a particular field (how we fill) and my understanding is these actions have built up over time as the set of actions that allow us to be compatible with the majority of sites out there. In other words these actions help mimic certain behaviours the site expects to see and by doing this we help them accept what we're doing on your behalf. On this site though these actions seem to be causing an interaction and as you say, the field clears as a result. So there will be work needing done here to improve not the compatibility with their page.

Now I'm not a customer of U.S. Trust, indeed I'm not even in the right country to be one but what little I've been able to test would suggest that Auto-Type should help. The reason I'm thinking this is when I try a standard filling attempt I find like yourself that the field seems to either remain blank or is erased and then I get the following error message when it tries to submit

Please enter required information.

Now if I enable the option Use Auto-Type in web browser for this item I instead get a different error message when I try to submit. With Auto-Type I get the message

Invalid User ID. Please retrieve your User ID or contact us for assistance.

That error message isn't entirely surprising given I'm not a customer and the user ID I'm testing with is totally fictitious. So I'm wondering, when you sat enabling Auto-Type doesn't help does anything change at all and how are you using Auto-Type? One way is to enable the option I mentioned earlier and when you try to fill using this Login item it will use Auto-Type. This method isn't perfect for this situation though for the following reason. It assumes the username and password fields are on the same page so it first uses Auto-Type to "type" in the username, then the tab key to move focus to the next field, which we assume is the password field, before it then uses Auto-Type to type in the password. Given the nature of their login page process this isn't the best option. On our page Using auto-type there is a section titled Field-level auto-type. If you try using this does the site behave any better?

cdp

Thanks for all that work. I could indeed use your proposed solution of field level auto type. But, that's very annoying to have to fire up the main 1Password program to jump through all those hoops. I have actually implemented the simpler workaround of using 2 separate logins, #1 for the username and #2 for the password. It seems I don't even have to turn on auto-type to make this work. So, that would imply that the failure of trying to do both in a single login has something to do with groping around the page to try to find the place to type the password. When the password is not in the login, it does not cause the username to fail.

So, my procedure now is to invoke the first login item, and then hit Ctrl-\ and select the 2nd item to complete the login. Only slightly more clunky than normal.

Do you guys work up specific processing for troublesome websites and distribute a template through software updates for the program to use that customizes the approach for dealing with those websites? On the one hand that would be great because it would simplify things, and make the program much more user friendly, particularly for the people that just can't hack it, if you'll pardon the pun, when you have to do the magic workarounds. The downside of course is that websites are a moving target and that would turn into a lot of baggage to maintain when the websites change.

I would hope there is some work going on behind the scenes, particularly with financial organizations that seem to be the major culprits. Their paranoid security tricks that break programs like 1Password actually encourage users to store their passwords insecurely or repeatedly use the same one. They could leave that trickery on the "normal/manual login page" and then have a different "auto login page" that is designed to work with 1Password (and generically with similar software), but bolstered with some more advanced, automated key exchange or something (like Apple Pay authentication?) that would provide even better security than their trickery, but which would cooperate with, instead of fight, the secure password program.

jxpx777

Thanks for the update, @cdp. I'm glad you have a process that works for you for now. I would love to get a peek at that password page, though, because unless it has multiple password fields or some other very crazy logic, 1Password should be able to fill the password field from a login that wasn't saved on the password page.

You're right that it does seem to be financial institutions that have the most Rube Goldbergian of login processes. (Here's one example I investigated yesterday if you're curious as to how deep the rabbit hole can go…) We would love to work with financial institutions to create real security for every website user. There are some other interesting possibilities on the horizon that we're keeping our eyes on that might help push the financial institutions in a better direction. We shall see. :)

Do you guys work up specific processing for troublesome websites and distribute a template through software updates for the program to use that customizes the approach for dealing with those websites?

We take a look at a variety of things related to website filling, and you're right that it is a big job to keep up with everything. But it's also a lot of fun to investigate and see where we can improve. Sometimes we do have to add some special handling for special websites to get them to work better, and we have some planned improvements to help us be more agile with them in the near future. But when we encounter a particular problem site, we first look to see if there is some generic way we can improve our form filling logic so that 1Password works for the problem site in a way that might also benefit other sites that use similar coding techniques. We add these as new tests to our automated testing suite to make sure the improvements do not regress other sites.

So, while we will add site-specific code when needed, we're more interested in generic filling improvements. More interesting still is when we notice a website development pattern that allows us to fix one site and by doing so improve filling in many other places. One example that springs to mind is when we figured out how to properly fill credit card expiration dates in Amazon's form for adding new payment methods. They were using a particular pattern we hadn't considered before and then we noticed a lot of other sites were using the same pattern, so fixing it on Amazon fixed it on several other prominent sites as well.

I love that you're interested in this stuff! I hope that sheds a little light on our process. Let us know if you have any other questions.

cdp

The problem page is actually the username page (before you even get to the password page). The username disappears before it has a chance to be submitted. But, this only occurs if 1password has the password saved in the same login as the username. When I let 1Password autosave the page there are a boatload of fields with crazy complicated names that get saved. In the end it behaves the same whether I leave them in or strip them all out. I have a feeling there is a hidden field with the same ID as the password field already present on the username screen, and if you try to touch it then it blows out the username as a defense mechanism. As in, no human being would be trying to set a password on this page, so if you do you're not welcome.

Does that seem plausible?

If you really do want to poke around with this page it is at:
https://www.fs.ustrust.com/login/login.aspx?sgt=1

The field name of the username is:
ctl00$ctl00$cphNestedUtility$cphLeft1$loginWidget$widgetctl$ctl00$validateUserControl$ctl00$txtUserid

If you were to manage to make it on to the password page, the field name of the password would be:
ctl00$ctl00$ctl00$cphNestedUtility$cphStage$cpLoginContent$ctlValidateUser$ctl00$txtPassword

littlebobbytables

Greetings @cdp,

Thank you for posting back. Your post prompted me to look at this site again and I'm grateful I did.

We see all sorts of crazy behaviour in the sites that get brought to our attention and we do our best to work with the craziness when it seems to be a common practice. One element of crazy is the fact that a invisible field can sometimes be used and we occasionally need to fill. What looks like a simple login page for the username only actually holds five input fields hidden from the user that are all of type password. So when we try to fill the page and the Login item has both a username and password present we do our best to fill both and that's what is happening here. We fill the username first and then we attempt to fill your password into one of these hidden fields. This has the side-effect of clearing the username, probably because the site didn't like us touching that hidden field as you say. So it isn't an HTML ID mismatch, it's 1Password desperately trying to fill the password and finding fields that are of the correct type. The presence of the password field in the Login item is all that is required to set this behaviour off.

I'm not sure what the answer here is. @jxpx777 will have a much better idea than due to his keen eye and intelligence. I suspect this will be an excellent learning point for myself as to what we might be able to do.

It's really like juggling sometimes, do x to try improve filling in y number of sites but then later discover somebody does things completely the other way round and you've broken it there. Every site brought to our attention though helps us improve the extension and reliability of the filling behaviour :smile: