Comments on: Another warning option for submitting forms? http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/ because at 3am anything sounds good Sat, 06 Sep 2008 02:41:19 +0000 http://wordpress.org/?v=2.5.1 By: Fowl http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-5241 Fowl Mon, 07 Jul 2008 16:11:33 +0000 http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-5241 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.) <a href="http://www.last.fm/forum/21713/_/409093" rel="nofollow">linky</a> 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

]]> By: Sam Hasler http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2414 Sam Hasler Mon, 07 Apr 2008 10:39:48 +0000 http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2414 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.) 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.)

]]> By: Wladimir Palant http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2412 Wladimir Palant Mon, 07 Apr 2008 06:09:06 +0000 http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2412 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. 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.

]]> By: James http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2411 James Mon, 07 Apr 2008 05:26:26 +0000 http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2411 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. 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.

]]> By: John Silvestri http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2408 John Silvestri Mon, 07 Apr 2008 00:48:11 +0000 http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2408 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. 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.

]]> By: Fred Wenzel http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2404 Fred Wenzel Sun, 06 Apr 2008 14:21:30 +0000 http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2404 @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. @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.

]]> By: Scott http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2395 Scott Sun, 06 Apr 2008 02:12:53 +0000 http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2395 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. 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.

]]> By: John Silvestri http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2392 John Silvestri Sat, 05 Apr 2008 18:03:25 +0000 http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2392 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 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

]]> By: Neil http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2390 Neil Sat, 05 Apr 2008 16:22:53 +0000 http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2390 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... 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…

]]> By: Fred Wenzel http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2388 Fred Wenzel Sat, 05 Apr 2008 13:09:09 +0000 http://micropipes.com/blog/2008/04/04/another-warning-option-for-submitting-forms/#comment-2388 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? 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?

]]>