Multiple-page login process with Verizon Wireless site

MikeT

This discussion was created from comments split from: Attempting to log in to PNC.com. Able to set up UserID (on one page), but will not accept password..

Amarand

I'm having the same issue with Firefox (my preferred browser) and VerizonWireless. It ends up saving the username and password into a single entry under Logins, but when I go to the site via Open in 1Password, it fills in the first part (username), presses Submit/Send, and on the second page, it doesn't fill or send. I've followed two or three of the step-by-step guides for creating separate entries, and also manually saving. Hopefully this is the correct place to ask?

MikeT

Hi @Amarand,

on the second page, it doesn't fill or send.

Did you press Control + \ shortcut or click on the 1Password icon to fill on the second page? 1Password will automate it on the first page because you asked it to but it will not fill automatically on additional pages for security reasons, imagine if the next page takes you to an unrelated page and 1Password fills in your password. As long as you press the shortcut on each page, it should fill and submit to the next page.

If you did press it, what happened; nothing fills or you got an error?

Amarand

I did, and that works. Reading through the responses on the previous (and other) posts, though, I'm seeing a lot of folks saying that two-page authentication doesn't work because it shouldn't work. I have several accounts, namely credit unions and such, where the two-page authentication "just works." I'm wondering why Verizon's doesn't work? It clearly has a Password entry/box which could be watched for, just like with my credit unions' authentication method. It -feels- like a bug, or the software not being updated to watch for specific triggers. If I can manually trigger a Control + \ on the password page, and the password page clearly has a Password field, it should be trivial for 1Password to detect that second page. Am I missing something?

AGAlumB

@Amarand: The key here is that 1Password doesn't fill and/or submit on your behalf without any action on your part and probably never will, as this is by design. When you Ctrl \ on the first page, a second page loads; 1Password isn't going to do anything with this second, completely separate webpage unless you tell it to.

Now, you may view these as a single entity, as they are each a part of a login process you're trying to complete, but 1Password just isn't going to assume that you want anything filled. It's 1Password's job to help keep you secure, not make decisions for you. I hope this helps! :)

Amarand

My workflow on my PC is such:

1) I determine the need to go to a web-site.
2) I right-click the entry in 1Password and use Open
3) The web-site opens to the login page, and the credentials are filled in.
4) If a second page shows up (like for my bank) the password is filled in.
5) Profit!

I just tested this workflow on both of my credit union web-sites. I select Open in 1Password, it opens in a new tab in Firefox, it detects the Username field (whatever that may be named) and fills it in (and presses send/submit/enter), then on the second page, it detects the Password field (again, whatever it's called form-wise) and fills that in (and then presses send/submit/enter). It does this, and works, exactly as expected, on two of my credit union web-sites.

With Verizon, when I do this, and right-click on the entry and select Open, it creates a new tab, properly detects the Username form field, enters my username, presses send/submit/enter. On the second (Password) page, the site prompts for:

Your User ID is:
XYZ
Sign In as a different user
Enter Your Password:

And there is a Password field - just like with my credit union. The field is named IDToken2 (I verified this in Page Source), which I've "designated" as a type of "password."

Again, this all works with ALL of my other two-page authentication entries. I'm finding it difficult to understand why it works in numerous other two-page sites, but it fails to work on Verizon.

Also, the Ctrl + \ is only required, for me, for Verizon, on the second page. I don't -ever- need to enter Ctrl + \ for any other entry. Something on Verizon's web-site is tripping up the auto detection mechanism in 1Password. Otherwise, why would it work flawlessly for, say, my credit unions' web-sites, where the connection workflow is identical? It's simply two, tagged POST entries in a row. Each of the POST fields is named, and this name is available to 1Password within the entry for the site, and each is tagged with a designator of either "username" and "password."

I'm not asking it to do anything it's not doing in several other sites I have in 1Password. Yet, it's sitting on the Password screen (second page), where it's being prompted for a Password, it knows the POST field's name (IDToken2) and yet it won't move forward with entering the field or pressing submit.

It seems like a bug. If something works as expected for several other sites, but fails to work on one specific site, something is wrong. Or, the fact that it works for the other two-page sites -correctly- is a bug/feature, which you guys should work on incorporating into the system for real, because the only thing I expect 1Password to do -really well- is to detect username and password fields, fill them in, and press the submit/send/enter button when required.

Amarand

* Now, you may view these as a single entity, as they are each a part of a login process you're trying to complete, but 1Password just isn't going to assume that you want anything filled. It's 1Password's job to help keep you secure, not make decisions for you. I hope this helps! :)

But this is the important part: When I tell 1Password to Open a site, it appears to "assume" that I want items filled in - on both pages of a two-page login form. That's its job. It seems to do this job 100% accurately on at least two, two-page entries flawlessly. It fails to do this same exact thing for Verizon. Why does it work for two, two-page sites, and not work for another? Something's different. It appears to work as expected on two sites, but not on the other. I'm a very technical person. I fix things for a living. When I see something working (the way I expect it to work) in two use cases, but not work in a third, it makes me think (hope?) that the third use case is a bug, not that the first two use cases were unintended. 1Password SHOULD log me in, if it can. The whole login sequence has been going on since the days of 300 baud modems and before. You are prompted for a username, you enter the username, you press enter, you are prompted for a password, you enter the password, you press enter. There's no magic. If 1Password can detect POST form fields (which it apparently can), and it can do this successfully across two pages (I have at least two examples of where it does this successfully with zero interaction on my side), then there's no reason why it cannot do this for my Verizon entry.

Is there something I/we can do to help debug this problem?

Amarand

on the second page, it doesn't fill or send.

The key here is that 1Password doesn't fill and/or submit on your behalf without any action on your part and probably never will, as this is by design.

This statement is false. 1Password fills and submits on my behalf using the Firefox browser extension for ALL of my entries EXCEPT for Verizon, when I select that entry in 1Password and choose Open.

Now, I realize that most of those are single page entries, but there are at least two that are double page logins that work just fine. Verizon seems like the outlier.

When you Ctrl \ on the first page, a second page loads; 1Password isn't going to do anything with this second, completely separate webpage unless you tell it to.

When using the 1Password application on my PC, I select the entry and choose Open. Aside from Verizon's second page for the password prompt, I never have to use Ctrl + \ to have 1Password complete this process in Firefox. I can see it fill the fields with the 1Password animation, and press submit/enter. I have 31 entries in 1Password there is only a single entry (Verizon) where this does not work. So, in my mind, Verizon is the odd man out, not the other way around.

Using Ctrl + \ shortcut key is only ever used for a single entry out of 31 entries I've entered so far. When using the Open feature of 1Password it seems like the process is automated. I don't ever need to select Ctrl + \ except for Verizon.

I'm entering more Login entries into 1Password each day, so hopefully I'll have enough eventually to have overwhelming evidence, but to me, 28 single pages "just work" with no interaction, two double pages "just work" in the same way, and there's a single entry for Verizon that fails to "just work" like the other 31 entries. What's happening with Verizon's site that is tripping up this clearly automated scripting mechanism?

MikeT

Hi @Amarand,

This statement is false. 1Password fills and submits on my behalf using the Firefox browser extension for ALL of my entries EXCEPT for Verizon, when I select that entry in 1Password and choose Open.

You just found a big bug for us, I was able to reproduce the incorrect behavior in Firefox and we'll get this fixed. It is absolutely not supposed to do anything more than the first page, it looks like Firefox has a bug where it is looping our method without stopping.

Do you use Chrome? I can reproduce it in Firefox but Chrome is doing it correctly, can you test it if you have Chrome installed?

Amarand

Chrome appears to work as AgileBits expects it to work.

Having said that, I almost prefer the "buggy" behavior or Firefox iterating through the username and password fields. As a UNIX/Linux Administrator, I've used the Expect scripting language for a couple of decades now, and I'm used to the logic of stepping through authentication handshakes. Would it be possible for AgileBits to develop - say - an alternate/optional method of authentication management where the browser does step through a two-page authentication scheme? If I know that a site uses two-page authentication, I could tell 1Password that it's a two-page site, and it would just figure that out.

Assuming the main TLD didn't change (for example: both page one and page two are VerizonWireless.com), and the page following the POST/username page contained a POST/password...it could go ahead and move forward with entering that form as well. Firefox/the plugin is obviously doing this accidentally, but what if it did so intentionally? I see a lot of sites shifting away from the single-page authentication scheme, and it might be nice to have an all-in-one program that handles most things that can be thrown at it with a single click.

Also, I've read in the forums here that there's a security philosophy at AgileBits against handling two-page authentication. Can you explain the details behind that? I've seen a few instances (my credit union, for example, which -sometimes- forgets I haven't used a specific browser due to a lost/cleared/expired cookie, and prompts me for a security question, rather than a password) where instead of P1: username, P2: password; it's P1: username, P2: security question. The form's field name changes, so there isn't a "password" in the second use case, and in a secure world, the auto authentication (1Password in this case) would just stop. But where a password -is- asked for on page two after asking for a username on page one, I can see that making things convenient for most folks.

Thoughts?

MikeT

Hi @Amarand,

Chrome appears to work as AgileBits expects it to work.

Thanks for confirming this.

Would it be possible for AgileBits to develop - say - an alternate/optional method of authentication management where the browser does step through a two-page authentication scheme?

Yes, we could do that and it is something we'd like to add optionally. The problem is someone could hijack the process and could add an iframe to redirect users to various domains while the one we're getting from the browser remains on the same TLD and so on that can fool password managers to fill in continuously. Basically, you can be on Verizon.com and if its iframe were hijacked to point to a different page, the password manager can fill within that iframe and the information would be sniffed. That's why we don't allow this in the first place but it makes our algorithms more complex and thus fragile to add an option for certain users who wants 1Password to do this and not care about the security risks.

We're more cautious by default and only add features slowly when it might have some security risks. As you saw with Firefox vs Chrome, this isn't solid as it can be because each browser handles it differently and each feature must be verified in every browser we support.

Also, I've read in the forums here that there's a security philosophy at AgileBits against handling two-page authentication.

It is not that we're against two-page authentication, we're against filling automatically without knowing exactly what the next page takes you to because the users do not have control over what happens on the next page.

That was what Brenty was trying to point you to, to our reasons behind this and the security paper that have validated our concerns, here's the link: https://support.1password.com/why-no-autofill/

Amarand

That was what Brenty was trying to point you to, to our reasons behind this and the security paper that have validated our concerns, here's the link: https://support.1password.com/why-no-autofill/

Ahh, awesome, thanks! Knowledge is power! :)

MikeT

You're welcome and don't hesitate to ask any questions about this, we're always happy to answer.