Is "unsecured web page" warning appropriate when form target is HTTPS?

GSnyder

The current version of 1Password (or at least, the Safari extension) gives an "unsecured web page" warning dialog when filling a form on an HTTP page, even if the form submission address is an HTTPS URL. An example of a page that gives this warning is ghc.org.

Is this warning really appropriate? I guess it's possible that some JavaScript code might grab the password and do something insecure with it, but in general, the form submission should be as secure as any other HTTPS transaction.

I notice that the warning message refers only to the URL of the current page, not the form submission URL. Perhaps it would be a nice enhancement for 1Password to check the target URLs of the forms it fills and make its decision to warn based on that more detailed information.

---

1Password Version: 5.3.2
Extension Version: 4.3.1
OS Version: 10.10.4
Sync Type: Dropbox

Drew_AG

Hi @GSnyder,

Thanks for taking the time to ask us about this!

The “Unsecured Webpage” alert will appear if the URL saved in a Login item is for a secure page, but the current page you’re viewing is not secure. We have more information about that here: Why did 1Password display an “Unsecured Webpage” alert?

I tried creating a test Login item for the ghc.org site, and because both the site and the URL saved in the Login item started with http://, I did not receive the warning when the 1Password extension filled the form. If the URL in your Login item starts with https://, you may have saved that Login item from a different page of that site (such as the registration form).

To avoid seeing that warning each time you log into that site, make sure the page where you sign in matches the URL in the Login item (as far as whether it uses http:// or https://). You can either sign in from the same URL as in the Login item, or you can change the URL in the Login item to match the page where you prefer to sign in.

Does that help? Let us know how it goes and if you have more questions about that, thanks!

GSnyder

I understand the mechanics of the current behavior. This isn't really a question about how to circumvent the warning in specific cases. It's a question for the developers as to whether the current behavior is really the best and most helpful policy that 1Password could implement for all users.

Is there some other venue for that type of feedback?

khad

This forum is a great venue for every kind of feedback, @GSnyder. And we greatly appreciate you taking the time!

I could write up a long reply explaining why serving an allegedly "secure" form (submitted over HTTPS) from an insecure page (served over HTTP) is a bad idea, but I wouldn't be able to say it any better than web security specialist Troy Hunt already has. Please read his post on exactly this issue and let me know if you have any additional questions or concerns:

Your login form posts to HTTPS, but you blew it when you loaded it over HTTP

Cheers!

GSnyder

That is certainly convincing. Thanks for the link!

I still think there's room for improvement in the way 1Password handles this situation, though. Ideally, you'd:

• Make it clear that 1Password knows exactly what's going on.
• Clearly communicate that there's a potential security problem, without using technical language.
• Provide some way for more technically inclined users to investigate.
• Allow the security check to be waived forever for this page, since it's unlikely the page will change.

The current warning is:

From "web site URL":

1Password warning: This is an unsecured HTTP page, and any information you submit can potentially be seen 
and changed by others. This Login was originally saved on a secure (HTTPS) page.

Do you still wish to fill this login?

[ Cancel ] [ OK ]

How about something like:

1Password warning: This page will transmit your login information in a way that is potentially not secure. Fill in anyway?

[ Details ] [ Cancel ] [ Fill ] 

<checkbox> Don't warn me again for this page

In this situation, it's really not relevant that the original login information was collected via HTTPS. According to the information linked above, the warning should appear anytime you attempt to fill an HTTPS-targeted form on an HTTP page.

khad

Your suggestion on this is very helpful, @GSnyder! We have been discussing changes to this prompt for the future, and we're on the same page with you. (No pun intended.) :)

1. An HTTPS URL in the Login item indicates the presence of a secure login page.
2. If there is no secure login page, then the URL can/should be changed in the Login item. You will not see the prompt if both the Login and page are HTTP.
3. The warning only appears if the URL in the Login item is HTTPS, but you are viewing an HTTP page.

In light of this, what we've considered is using the secure (HTTPS) URL that is already saved in the Login and using it to perform what we call "Go & Fill": 1Password will navigate to the secure page and then fill. A proposed example:

Warning: This page is insecure!

---

Any information you submit on this page can potentially be seen by others. The Login was originally saved on a secure page.

Would you like to fill on the secure page?

Don't fill Fill on Secure page

Don't fill is essentially the cancel button. It is the action that is taken if the user closes the window or presses Esc.

Fill on secure page is the default button. It does a Go & Fill of the primary URL in the Login item which, if they are seeing this message, will be a secure URL. It is the action taken if the user presses Return and thus should be highlighted by the OS.

Having a checkbox to not show the prompt again is not a good idea from a security standpoint. The goal is to never fill credentials on an insecure page if a secure Login page exists (as determined by the presence of the HTTPS URL in the Login item).

How does that sound to you?

GSnyder

It sounds good, and clever. I'd be worried, though, that many of the source URLs saved with logins are in fact from signup pages or password-change pages. But you would have a much better handle on how that data works out in practice than I would.

For example, I mentioned ghc.org above as an example page. My saved URL for that site is https://member.ghc.org/open/login/thankyou.jhtml?_requestid=805797, which is just a page that says "Thank You" with no other context. I know how to fix this, but many users won't.

One thing I've noticed with these HTTP/HTTPS login forms is that if you just click the login button without filling in any account data, you almost invariably go to a separate login page (with some kind of "account not recognized" message) that is itself wholly HTTPS. If the original form target is an HTTPS URL, you know the form is probably not going to be doing some kind of fancy JavaScript login. It needs to really redirect you when you submit the form in order to get you into the HTTPS world. The address of that second page is the one you'd really like to jump to if the initial page is insecure. Maybe there's some way to automatically determine or record that second-page address.

As a user, I'd really like 1Password to permanently resolve these situations for me so that I don't have to go through any dialog boxes the next time I visit. No approach that repeatedly gives me the same warning (to which I always give the same answer) is going to feel like a fix. Yes, it's regrettable that ghc.org doesn't use HTTPS correctly. However, I don't control their web site, and no amount of 1Password nagging is going to change that. If 1Password can find a secure login method, it's fine to confirm that once; after that, it should just use the secure method without me having to manually revalidate on every visit. If there's no secure version of the login panel available, I may indeed just want to shrug and accept the fact that a given web site isn't as secure as it could be.

I completely understand not wanting to put out a product that encourages a lackadaisical approach to security, especially when a security scandal could potentially undermine your reputation and business. But I want 1Password to solve my problem, not AgileBits' problem, which is that 1Password keeps nagging me about hypothetical security problems that I long ago decided to ignore and accept. If 1Password can make things better, I will gratefully accept its help. But I would prefer a merely-insecure login process to one that is both insecure and involves 1Password nagging me.

khad

We'll continue to iterate on this in future updates. We agree that there is room for further improvement. Thanks again for your thoughts on this!