Another warning option for submitting forms?

These are our current options for submitting forms in Firefox 3:
Firefox security
options dialog

I don't know anyone that has the "I submit information that's not encrypted" option checked. We used to prompt for submitting information that was unencrypted, next we added an option on the dialog that disabled the warning (and was checked by default), and finally we removed the warning by default all together. People submit so much information via searches, surveys, voting, sending quick messages, etc. that it would just get in the way and be ignored.

I've noticed lately that a lot of sites are showing login forms on unencrypted pages but submitting them via SSL to their target pages. This is a secure method of logging in but it's started to train me to not look for a secure connection before I log in and that's not a good idea in the long run.

I think our current option is too broad, so I'm proposing that we add an option that says "I submit credentials that aren't encrypted" or a sub-option for the current text that says something about "unless I'm sending a password."

In more technical language: If a user POSTs a form containing an input of type="password" to a non-encrypted page we should show a warning.

This would mean regular searches, filling in surveys, anonymous voting and polls would all pass transparently if unencrypted, but when you got to a form with a password you would be warned.

I bounced this idea off a channel in IRC and no one said I was nuts so I figured I'd take it here. It seems like too small of a feature to make an add-on out of but I might if I get some free time. What do you think?

20 Comments

I like this idea. I think having a message about low-grade encryption is useful as well as the sub-option for only showing it if there's a form field with input type="password".

I think the first option is worthless. I'd suggest removing it
-- Jose, 04 Apr 2008
While I just complain about the lack of https on so many web2.oh sites' login forms, you've came up with a good idea.

You should roll with it.
-- Barry, 04 Apr 2008
+1
-- ignacio, 04 Apr 2008
I’ve noticed lately that a lot of sites are showing login forms on unencrypted pages but submitting them via SSL to their target pages. This is a secure method of logging in


Not quite; what happens if someone can futz with your Internet connection and do a man-in-the-middle on the unencrypted page? Hijacking DNS at, say, an airport wireless service is eminently doable. The attack can produce the exact same page -- but instead of that SSL submission action, they switch it to their own servers to intercept the information you sent, and they potentially then redirect you to the actual site. You have no reason to suspect that your information has been disclosed to a third party, and if you're not observant you won't notice the interstitial interception and redirection.

The right approach to security is not to cut away the hard parts -- that usually leads to non-obvious failure modes like this one. The right approach is top-to-bottom security, with infrastructure optimizations to minimize the actual cost to users.

Regarding your suggestion, I'm wary of making promises about what constitutes "credentials", but the idea seems like it might potentially work. I'd need more time to really think about it before making a reasoned judgment.
-- Jeff Walden, 04 Apr 2008
Warning is no good if you can’t cancel the submission (well, maybe it’s half-good; you know you’ve let your password or credit card number out insecurely). There’s an open bug somewhere about making http->https navigation/submission cancelable, but I suspect the fix is pretty difficult.

As Jeff notes about, “credentials” are problematic; for instance, I’d want to be able to cancel a http->https (or otherwise insecure) submission of not only a login/password, but also my credit card number, birthdate, SSN, etc.
-- Smokey Ardisson, 04 Apr 2008
I think its a step in the right direction. But it won't solve the problem. Maybe have some extra checks to see if the form is being submitted to a different domain? Unfortunately, this still won't solve the problem of poisoned DNS.

Also have to be careful with giving people a false sense of security. Sometimes, that's worse than having no security at all.

Of course, it would help if websites did things properly - but I'm not exactly holding my breath on that happening any time soon. Or ever happening at all, for that matter.
-- Blair McBride, 04 Apr 2008
Why not just have the submission url in a tooltip when the submit button is hovered over, like in the Formfox extension - https://addons.mozilla.org/en-US/firefox/addon/1579
-- Steve, 04 Apr 2008
I think a "warn me when I submit a password insecurely" warning would be a nice option to have (there's a bug about making the HTTP auth dialog clearer about this too)... I'm not sure how usable it would be though, because so many sites don't do SSL at all (eg, most forums). You wouldn't see it as often as the old warning, but it would still be annoying.

Combining it with some other factor might help make it more useful. Ideas off the top of my head:
* A blacklist/whitelist, so users can configure (ugh) when they see it
* Comparison to existing stored logins / history (eg, if you stored a password for https://site.com, warn if you try and log in via http://site.com)
* "Never ask me for this network connection". Maybe I trust my home/work WiFi connection to not be sniffed, but want the extra paranoia when I'm browsing from Starbucks. Variation: something akin to private browsing mode where we become hyper paranoid.

Also, I hesitate to call sites that do SSL logins from non-SSL pages secure. It's better than nothing, and prevents passive sniffing, but if someone is actively able to modify the non-SSL page they can steal your password before you ever submit it.
-- Justin Dolske, 05 Apr 2008
Waldo is correct. I complained about this web site practice in http://www.squarefree.com/2005/05/28/banks-and-https/ a few years ago.

A more useful extension would be one that automatically takes you from http://www.wachovia.com/ to https://www.wachovia.com/.
-- Jesse Ruderman, 05 Apr 2008
This is a great idea.
-- Eric Shepherd, 05 Apr 2008
like comment 1, I am wondering what the first option is even about? Why would I want to be warned before viewing an encrypted site? While it makes sense at first sight (just so you realize that the page now being displayed is "secure"), it becomes utterly useless when you enter any data, since any subsequent action is not guaranteed to be encrypted anymore. Thus, the option does not seem to have any value at all?
-- Fred Wenzel, 05 Apr 2008
I always turn that warning on; I use it as the "Oops, you hit Enter by mistake" safety net! I also find it useful to give me extra vital milliseconds to spot typos etc. which means that I now have to be extra careful typing comments into Bugzilla...
-- Neil, 05 Apr 2008
Sounds like a nice idea, but the real fix is for the banks or other organizations to fix their sites. I suppose a prominent dialog box like this might embarrass them into fixing it, but this won't protect against hijacked connections, as mentioned by Jeff Walden (above). How could this dialog be avoided in an attack? Easy: make the form POST to an evil HTTPS server. SSL certs can be had for very little $$, and it would avoid this dialog. You could then add more code to make sure domains match...but it's an ever-escalating war between good and evil. I fear this sort of solution would give people a false sense of security.

I've also seen that some sites use JS/Ajax to do very strange forms of authentication, which might not be doing a real "action" and never trigger this warning dialog. Some of these AJAX gizmos submit their contents as plaintext, via HTTP, some via HTTPS, and some are quite clever and compute the MD5 locally and send it via HTTP (Yahoo Mail used to do this). As such, there's a /lot/ to consider.

Arguably the best thing to do would be to put a warning bar at the top (like the Add-ons warning) that notices password fields on HTTP sites and disables the password field unless it's accepted. This would be very annoying and I can't honestly say that users wouldn't lynch Mozilla for making such a move...but it would probably force major sites to go to SSL. However, a lot of small sites that can't make such moves would be at a supreme disadvantage, and it would be a disaster. Is this a security issue people should worry about? Yes. Can users be protected against every possible attack against their credentials? Sadly, no. I tend to think these approaches should be done via extension, and highly recommended, but not enabled by default.

P.S. This has also been mentioned by ISC SANS a few times, including here:
http://isc.sans.org/diary.html?storyid=1277
-- John Silvestri, 05 Apr 2008
How about a plugin with a big "paranoia mode" button. Once toggled on, a warning (and chance to cancel) is displayed for pretty much any non-https request and for any request to a domain not yet approved since entering paranoia mode.

Such a plugin would be annoying, but very tolerable for the 1 or 2 hours a month that I do banking and such.
-- Scott, 05 Apr 2008
@13: Pre-hashing a password and sending it in plain text then is horrible -- it suffers from an easy MITM-attack, because it can trivially be replayed when somebody gets their hands on the sent hash. If they want to do something AJAXy they could at least do some challenge-response protocol, which wouldn't protect against dictionary attacks for example, but at least nobody could easily replay the login session. But then again they could just "do it right" and do SSL instead.
-- Fred Wenzel, 06 Apr 2008
Fred: I never said it was a good idea, but it is 'clever.' I don't recall the specifics of it, only that I read about it in the Y[aho]oSucker source code ages ago. It is entirely possible that was a one time salt used which would keep a replay of that value from working. However, that's only good for the sites that were smart enough to do it this way. My point was not to advocate this technique, but to highlight ways this proposed security mechanism can be bypassed.
-- John Silvestri, 06 Apr 2008
Like Neil, I use the option to give me that second chance to consider if I want to submit the form or not. I'd say I end up using it at least once a day. Speaking of second chances, I hate blog comment forms without a Preview option.

Fred: LiveJournal uses a nonce when hashing credentials for HTTP submission to prevent replay attacks, I imagine other (well-designed) sites do too.
-- James, 06 Apr 2008
Only because the connection is SSL-encrypted, it doesn't mean that you are talking to the right site. From what I remember, there are lots of SSL-encrypted phishing sites out there. And as long as the logi page is unencrypted, a man-in-the-middle attack can easily give you the same page but send your credentials to a phishing site.

Something that might be more useful would be the option "I'm about to submit my credentials from an unencrypted page" which would consider both the login page and the form target. Not that it would really prevent phishing (a phishing page doesn't have to wait for you to submit the form, it can easily send the data itself) but it will bring more attention to the issue and might put pressure on sites like wachovia.com to fix this problem.
-- Wladimir Palant, 06 Apr 2008
Regarding Justin's comment:

" “Never ask me for this network connection”. Maybe I trust my home/work WiFi connection to not be sniffed, but want the extra paranoia when I’m browsing from Starbucks."

Vista classifies network connections as public or private. If Firefox can access that setting and knew what trust the user placed in their current connection it wouldn't need to ask the user. Only display the warning if they are on a public network reminding them of the fact "You are on a public network, are you sure you want to submit this form.", instead of asking the user to make a trust decision about the network each time a form is submitted which some percentage of users is always going to answer incorrectly (even users who understand all the issues may sometimes answer incorrectly in their haste to complete some action).

Of course this assumes that the user has configured their network connection appropriately but at least then the trust decision is only being asked once, and at the appropriate time when the user is setting up their network and should already be thinking about security.

If it helps anyone to think about this I made a diagram of all the transitions between encrypted/unencrypted and mapped them to the options dialog, as well as the different ways that passwords could be submitted:

http://sam.haslers.info/misc/firefox_security_options_and_diagram.png

(I'm not sure whether submitting from an encrypted page to an unencrypted page would bring up dialogs for both the third and fourth options.)
-- Sam Hasler, 07 Apr 2008
The real solution is for people to fix their websites.

I tried (and failed) to convince last.fm... (they have insecure content on a secure page, ie. just as bad.)

linky
-- Fowl, 07 Jul 2008

Post a comment

All comments are held for moderation; basic HTML formatting accepted.

Name: