Carefully Tuned User Irritation

Yngve has an interesting post about how to deal with the problem of banks etc. doing login by submitting from an insecure to a secure page.

The aim is not to protect each user’s form submission when using the broken page; the aim must be to get the bank to fix the site. So we need to change the browser to inconvenience the bank’s customers enough that they complain to the bank, but not enough that they try and change browsers to one which does not have this “feature”. In other words, we need to carefully tune the level of user irritation ;-)

So how can you inconvenience the users? One option is Yngve’s popup on submission; make the users press a big button marked “Submit Insecure Data”. That should cause a few panicky calls to the bank’s tech support line. Another option would be to delay the rendering of the next page by five seconds or so, while displaying some sort of warning in the blank space; banks like their sites to be snappy, and they don’t like worried customers.

If we are going to make browser changes, we’d need to do it in a synced up fashion, so people didn’t simply reduce their security by switching browser provider.

One last option would be to sponsor a 3rd party “major banks security assessment”, which took in details like this, the format of emails they sent out, whether they used third parties for email delivery, and so on. Publicise the results, and try and shame the lagging banks into compliance.

25 thoughts on “Carefully Tuned User Irritation

  1. A normal dialog will not work:

    ——————————————————————-
    A serious security problem has been found!
    Please call your bank’s help desk.
    Do you want to continue?

    [OK button] [Cancel button]
    ——————————————————————-

    What user will do:
    Scans the dialog for all buttons
    Finds OK
    Clicks OK

    You should do it like this:

    ——————————————————————-
    A serious security problem has been found!
    Please call your bank’s help desk.

    This message will automatically disappear in 5 seconds [count-down]

    [Cancel button]
    ——————————————————————-

    What user will do:
    Scans the dialog for all buttons
    Doesn’t find OK
    Reads the message to find out how to confirm

  2. Your first two ideas suck.
    The 3rd party “major banks security assessment” has possibilities.

  3. Fred: It’d help if you were constructive about why things ‘suck’.

    In general, I think doing a cross-browser evangelism thing to get bank to secure their apps is an excellent plan. I’d rather that *all* major browser vendors (Opera, Mozilla, MS, Apple/Safari/KHTML) take action on that field than ending up with one browser putting off website clients. If that happens, especially if it’s not IE, the tech support staff that you mentioned will probably wave it off and tell them to use another browser. Which would be a shame.

    As a note, I’m not really sure whether any of it applies to my bank. When you login, you need to provide your bank account number, and you need to stick your bank pass in a standalone hardware reader the bank provides you with, enter your PIN-code on the reader, and type an 8 digit randomized hash of sorts into an input field on the page (the code is different all the time). It would seem that there are no real security implications for how that gets sent as it’s a one-off key, as far as I’m aware. IE, as soon as you log in with it, you probably can’t login with it again (I haven’t tested it and I’m not really sure about the crypto/hashing that’s going on here).

  4. Frederik Vanderstraeten: While I didn’t say so explicitly, my message implied that there would be no “OK” button – only a “Submit Insecure Data” button. I am well aware of users’ tendencies to just click OK without reading dialogs.

    Gijs: Your bank’s system is possibly more secure; but if you typed the hash into a page not under your bank’s control, the attacker could be doing an MITM attack – i.e. he tries to log in as you, presents you with the challenge that the bank presents him, gets your response, then submits it to the bank and voila! – he’s logged in as you.

    So if the initial page you start on is insecure, then you are still not completely safe. It just makes the attacker’s job harder; they can’t do a “harvest and store”, they have to do a “real-time break in”.

  5. Unless IE and/or Opera is on board, I would be very hesitant about any sort of delay/popup. I think there is a good chance it would be ignored, misunderstood, or worse – blame goes to Mozilla. As already stated what happens when the help desk says to use another browser? How can Mozilla write a message that would explain the situation to the users so they can advocate for this change? And if the message is misunderstood, then there is a good chance that the user interprets such a message as a problem in the browser (or that it has been comprised). When they try it on another browser it works – i.e. what’s wrong with this thing that my kid downloaded?

    I like the idea of working with a third party to “shame” insecure banks. Perhaps the Foundation can give a grant to a group that would head something like this up and work with them to provide the results. Perhaps some type of extension built into Fx that tests for this problem and returns results to this third party group. The group could then release studies and results in press releases to really get at banks and government forms on-line. I think it would be a great contribution of the Foundation without hindering the Corporation to spread Firefox to the masses or giving away current users.

  6. Telling the user that there is a security problem is not sufficient. You need to tell them WHAT the problem is (submitting data on an insecure site).

    For informed users the action is simple. Contact the bank and tell them you will not submit data to an insecure site. If you are so inclined, tell them you will find another bank that does have a secure site.

  7. You must also remember that not all the login forms are related to banks so if they start seeing those kind of messages everywhere they will quickly forget about them.
    So the basic premise would be (as implied by the first sentence of your post) to only warn them if they are posting from http to https not from http to http.

  8. Interesting topic that I’ve always been concerned about.

    Bank of America has an interesting method for this. You can begin to log into your account from the insecure home page by providing your username and state. It then passes it to their secure server where you have to enter your password and validate your “site key” which is a picture that you choose to associate with your account. This is a case where an “insecure to secure” post warning would unecessarily worry a user because your password isn’t being passed unencrypted and the site key is a good method for preventing spoofing.

    Of course, I have the secure login page bookmarked and don’t go through the home page :)

  9. Maybe include it somehow in the Google anti-phishing feature.
    Make a list of banks who do this. That will solve the where to use/where not to use problem.

    Something like:


    The Firefox anti-phishing mechanism has detected a possible security problem in your bank’s website. Altough this most likely is your bank’s real website, it uses insecure data transfer. The site could be changed when sending it from the internet to your computer. This may cause your password to be revealed.

    This way, it’s made as clear as possible that this is a potential security problem in the site only DETECTED by Firefox, not caused by Firefox.

  10. There are definitely security vulnerabilities involved placing login forms on HTTP pages that submit to HTTPS pages. However, what is the solution for website developers?

    What if a website replaced the login form on its HTTP home page with a link to a secure login form? I would argue that this provides no additional security, since the home page (and its link to the secure login form) could be replaced with a fake version. We should keep in mind that fake versions can be done not only by hijacking DNS but with look-alike domain names.

    A more secure alternative would be for a company to require serving *everything* in HTTPS and train its users to check for the browser padlock.

    Even then, there are still some potential vulnerabilities: HTTPS pages can be vulnerable to XSS attacks. Is it possible to purchase SSL certificates for look-alike domain names?

    I think we should actually *encourage* form submissions to HTTPS pages, whether they come from HTTP or HTTPS pages. For starts, perhaps we could give the submit button a gold border if the form submits to HTTPS. This isn’t foolproof (a hacker could fake it with a submit image), but the idea is to gently inform users that some forms submit with security and other forms do not. This idea could be tweaked by using different visual effects (preferably something that only the browser could do) and modifying different elements (maybe the password field instead of the submit button).

    Another idea to encourage form submissions to HTTPS pages would be to always display a warning when a password field is submitted to an HTTP page. Unlike the generic insecure warning message, don’t let this warning be turned off. It should be a safe assumption that if user input shouldn’t even be displayed on the screen, it should be encrypted for submission.

  11. I don’t like the idea of punishing all uses of http-to-https form submission. That would punish many current and future legitimate uses of https. For example, it would cause problems for any of the pages off of bugzilla.mozilla.org that let you search Bugzilla, including http://www.squarefree.com/start/. It would discourage sites like Bugzilla and Google Search from going all-HTTPS, and that would not be a good thing.

    Furthermore, banks would be able to work around it by doing “form submission” through JavaScript instead of through the normal form submission path (there might not even be a FORM element on the page).

  12. The problem with most of these solutions is that, unless IE takes similar steps in their browser, which seems unlikely for IE7, banks are going to use ActiveX or other MS-propietary stuff and lock out not only Firefox, but Safari, Opera, etc. On the other hand, there are sites where is isn’t necessary to display warnings or switch to HTTPS, from an end user perspective. Searching in either Bugzilla or a.m.o are examples where security isn’t necesarily important.

    A better solution is if any web browser would warn if data is sent to a site with a different domain. For example, if I enter my information on http://www.mybankname.com, but it is sent to http://www.mbn.com, a warning would pop up. The only disadvantage is that Google would be unhappy with the warning messages.

  13. DavidSickmiller, the problem with logging in from an HTTP page is that passwords are not encrypted. We just can’t have that.

  14. AnotherGuest: You sure about that? It’s my understanding that in an HTTPS request the only unencrypted piece of data is the IP address of the server. Even the host command is encrypted, so I don’t see how a POSTed form wouldn’t be.

    The biggest problem is that search engines, as far as I know, still don’t spider secure pages. That means that any non-secure information wouldn’t be available to people doing a web search. And as businesses, banks want to have as much spidered as they can so they can draw new customers, provide information for potential stock purchasers, etc.

    I suppose you could twiddle the settings depending on what UA the server sees (Googlebot gets HTTP, Mozilla/* gets HTTPS) but that may technically run afoul of the “show us what you show the users” rule that Google has.

    Ideally, spiders will be given the ability to negotiate HTTPS connections, but it’s a chicken-and-egg problem: With a huge majority of HTTPS pages being things people don’t want to have searched there’s no reason to add that capability to your spider. And if spiders can’t negotiate HTTPS there’s no good reason to (and many reasons not to) make your site HTTPS all over.

    So for now that means that users would have to go to the non-secure home page, then click to the secure login page, then log in. Joe User doesn’t know about HTTP vs. HTTPS; he just knows that his bank is “stupid” for making him do an extra click when they could just put the form on the home page. Guess what happens when the bank gets enough irritated calls and e-mails…

    Of course, the search engines may have changed in the last few years, in which case this whole post is out the window. I welcome correction.

  15. David Sickmiller said: HTTPS pages can be vulnerable to XSS attacks.

    I would home most banks don’t display user-generated content, or content based on the URL, on their home page.

    Jesse said: I don’t like the idea of punishing all uses of http-to-https form submission.

    Perhaps we could only complain if there was a password field?

    Jason said: The biggest problem is that search engines, as far as I know, still don’t spider secure pages.

    Google for https to see the counter-evidence.

  16. Gerv said: I would hope most banks don’t display user-generated content, or content based on the URL, on their home page.

    I would too, but it’ll never be 100%.

    Until last year, my utility company’s frame-based website would accept a URL in the query string to be used for the bottom (main content) frame. Turns out this even worked in HTTPS with no warnings. Thus a specially crafted URL could take users to the utility’s HTTPS website that displayed the attacker’s HTTPS page in the bottom frame.

    Bank of America had a similar vulnerability on its website for launching new windows. This attack was done using HTTP URLS, but I suspect it would have worked the same using HTTPS. See http://www.antiphishing.org/phishing_archive/04-19-05_BOA/04-19-05_BOA.html

  17. Gerv said (In response to XSS on secure sites): I would ho[p]e most banks don’t display user-generated content, or content based on the URL, on their home page.

    It doesn’t have to be on the home page, it just has to be some site on the domain for the phish to work. For example, see the recent paypal XSS thing (details fuzzy) where the injection was through URL parameters. Or query BMO for “XSS” in products other than Core for examples from mozilla.org itself.

    How about another infobar-like warning for HTTP pages with password fields. Same idea as the tooltips, really, but comes up earlier and taints the entire page which might give more boost to the website fixing the problem.
    /!\ Passwords entered on this page are insecure (learn more)

    It’s not interfering the way a dialog would so there’s less for the sites to complain to us about. And we can hope that people who use a lot of insecure passwords on insecure sites (e.g. forced registrations) won’t be so annoyed they go to another browser (which is my fear about the tooltips).

    On a related subject, should the password manager offer to save passwords stick in an extra warning on HTTP pages? (“Web pages from this site are not fully secured against password theft, do not use the same password you use to secure high-value information”)

  18. Dan: I don’t think we could warn about all HTTP pages with password fields – people will get used to ignoring the warning, because there are loads and loads of sites out there (e.g. bulletin boards) who don’t use HTTPS and use the usernames and passwords just as a profile-fetching mechanism. No-one is ever going to make the effort to sniff people’s connections to Joe’s “Britney” Forum.

    One radical option would be to have a blacklist! So we would put the insecure login pages of a load of major banks on it, and warn just for them…

    The password manager idea is good, apart from the fact that it’s too late. The password manager only pops up when you’ve already submitted the page to the site (doesn’t it?). Actually, we need better text on those buttons. Does “Cancel” mean “Cancel the request” or just “Cancel the idea of saving the password”?

  19. Gerv: I stand corrected. Taking a look at the returns for BugZilla, it seems that for some reason it doesn’t pick up any actual content most of the time. I can’t figure out why that would be though.

  20. plz i just want to know much about this organisation many claim the wrigth poeple but some one tell me about it that is why i just want to be aflieted

  21. Gerv wrote: Dan: I don’t think we could warn about all HTTP pages with password fields – people will get used to ignoring the warning, because there are loads and loads of sites out there (e.g. bulletin boards) who don’t use HTTPS and use the usernames and passwords just as a profile-fetching mechanism. No-one is ever going to make the effort to sniff people’s connections to Joe’s “Britney” Forum.

    The concept that it’s okay to submit passwords using HTTP on some websites but it’s not okay to submit passwords using HTTPS on other websites adds a lot of complexity to the situation. It’s also counter-intuitive.

    I understand the common sense behind not needing HTTPS for Joe’s “Britney” Forum, but it’s well known that people re-use their usernames and passwords. Hopefully most users are smart enough to use a different password for their online bank account, but I bet many have made this mistake. Or maybe they use the same username/password for their e-mail. In a way, it’s ironic that Joe’s “Britney” Forum uses a type=password input field combined with an HTTP submit. In effect, the password is hidden from the person who types it in, but available to everyone along the network path. I’d rather have Joe use a regular text field than falsely imply that the password was protected.

    Let’s say, hypothetically, that the web browser displayed a (new) warning only on HTTP pages that submitted forms to HTTPS. The danger here is that the HTTP page could have been faked, right? Well, as long as the hacker who made the fake page was smart enough to make the form submit to HTTP, the browser won’t display any warnings. Thus, we’d be warning users of the legitimate site and quietly allowing the hacked site.

    Gerv wrote: One radical option would be to have a blacklist! So we would put the insecure login pages of a load of major banks on it, and warn just for them…

    Now, let’s say, hypothetically, that the web browser had a blacklist of URLs of all the important bank websites where form submission from HTTP would trigger a special warning. This time, a hacker who faked the HTTP home page (or possibly any HTTP page on the site as Dan pointed out) would simply do a meta refresh to a different URL or use an iframe in order to avoid being on the blacklist. Once again, we’d be warning users on the legitimate site and quietly allowing the hacked site.

    I can see how this fits in the strategy of making users worry, who will in turn call their bank, who will in turn hopefully stop serving any pages using HTTP. However, I agree with the general opinion that this is a risky strategy that could lead to browser switching.

    Separate from specifically thinking about bank websites, I can see how there is a gap in the browser’s security notifications. It’s impossible to look at a form on a webpage and tell whether it submits using HTTP or HTTPS. I don’t care if my search query is submitted using HTTP, but I do care if my password is submitted using HTTP. (Even if it’s Joe’s Forum, I like to be aware of it so that I remember to use a throwaway password.) As a user, I want to be appropriately informed of my information’s security. For certain websites, I would like my password to be secure all the way from my fingertips to the remote server.

    For this to happen, I think the following would need to happen:
    – The infobar would pop up when my cursor entered a type=password field in a form that did not submit to HTTPS. Or if the password was autofilled, display the infobar on page load. (Clearly, I like Dan’s idea of using the infobar.)
    – Javascript keystroke listeners would not “hear” anything I typed in the password field.
    – Javascript would not be able to read the value of my password.
    – On submit, the browser would confirm that Javascript had not changed to HTTP.
    – It would have to be impossible to simulate a type=password field using other means (e.g. using a regular input field with a keystroke listener that inserted asterisks, or something more elaborate with canvas)

    If all of these things were in place, I could enter my password on any page (HTTP or HTTPS) and know that it would securely be submitted using HTTPS. (And presumably, all the CA’s I trust only issue certificates to safe sites.) My password would even be safe from XSS attacks.

    Unfortunately, I can already see many drawbacks to this idea:
    – I think it’s impossible to prevent the simulation of the password field.
    – This would break form validation which often reads password values and lengths (although I believe this behavior is either prevented or flagged in Opera).
    – This would ruin many existing AJAX logins.
    – This would trigger the infobar on Joe’s “Britney” Forum.
    – Even if we had a feature to “Allow insecure passwords on this domain,” there would be an abundance of security warnings when the browser was used for the first time.

    To really provide fingertip-to-server password security without breaking so many existing sites, we’d probably have to introduce a new input attribute (e.g. <input type=password secure=true>). Typing into a secure password field would trigger some sort of chrome-based visual indicator that could not be simulated by javascript. (Probably not the infobar, because that has a negative connotation. Perhaps a pulsing padlock.) All of the security properties I mentioned above would apply to this password field. Hopefully users would learn to expect the chrome-based visual indicator while on their bank’s website and would get scared if it wasn’t there. Also, the password reminder would only prefill passwords that were saved with the same security level.

  22. Thus, we’d be warning users of the legitimate site and quietly allowing the hacked site.

    Yes. Exactly. Precisely. That’s the point.

    This is not a direct user protection measure, it’s a way to try and persuade banks and others not to put their customers in that situation. If legitimate customers get nagged, they’ll hopefully change their sites to avoid the nag.

    It’s impossible to look at a form on a webpage and tell whether it submits using HTTP or HTTPS.

    There’s no way to provide such an indication, for two reasons. a) The submission URL can be changed by JavaScript at the time you click the Submit button, and b) because the form is within the page, it’s very very hard to find some sort of non-fakeable indicator which says it submits to HTTPS.

    Anyway, HTTP to HTTPS is something we want to discourage, not to encourage with “well, it’s safe really” indicators.

    As for your other ideas, you are at the beginning of a path that others have trod before you. See http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/ for the latest thinking.

    Gerv

  23. I need your help.

    They have change my password and i need it back please help me out and send the password back to my email.Here is the email they changed the pasword kelvin_wayans007@yahoo.com and i will want you to help me by sending me my password back and i will always do anything to help you more.Send me email to kelvin_wayans00@hotmail.com.

    Thanks.

    Kelvin.

  24. Hi kelvin,

    This site was emailed to me by an indiviual I don’t know.
    Ineterseting stuff you wrote. Look forward to talking to you soon

    Yours Truly Rebbecca