7 out of 36 top web sites still transmit login passwords in the clear. I documented this recently in a blog post (http://tinyurl.com/ ycg4acv), and I'm trying to find solutions.
This is problem for (a) folks surfing the net over an unsecured wireless network, and (b) folks surfing in other conditions where their traffic may be monitored, most notably in states like Iran where use of deep packet inspection is well documented.
Part of the problem is user (and often the webmaster) ignorance about the insecure transmission.
Firefox might be able to change that.
I'm down to write the code if you all think this is a good idea, but I wanted to start by getting input on the feasibility and design from you guys, since you understand (and control) the browser experience far beyond where I'm coming from.
Here's how it might work.
We already know which user-entered content is a password just by looking at form fields' input type. During a page navigation or a javascript HTTP request we look at the payload to see if it contains the user-provided password in plaintext.
We can then do either of the following:
1) provide a hint at the bottom of the toolbar stating "this web site may have sent your password unprotected [more info]", or 2) show a modal dialog asking the user if they want to allow the HTTP request.
You could also imagine a UI that e.g. does #1 normally but #2 if the user is on unsecured wifi. (Just thinking out of the box for a second.)
The hardest problem to solve is distinguishing between a password being transported in the clear, versus an HTTP request that happens to coincidentally contain the text of a password form field. Of course if it's a vanilla form submission you can tell for sure. But a javascript driven request removes certainty since you don't know exactly they're using the password to form the HTTP request. You could imagine, for example, a heuristic that kicks in when the password has a certain threshold of entropy (i.e., is not "www").
I realize an overly paranoid browser drowns a good user experience, but if adopted this feature might be able to make the Internet much more secure, and some users would certainly appreciate the notice.
> We already know which user-entered content is a password just by > looking at form fields' input type. During a page navigation or a > javascript HTTP request we look at the payload to see if it contains > the user-provided password in plaintext.
Or even more simply, take the codepath for the exiting (disabled by default, last I checked) "submitting a form insecurely" warning but restrict to cases in which the form has an <input type="password"> in it?
> You could also imagine a UI that e.g. does #1 normally but #2 if the > user is on unsecured wifi.
I'm not sure we have a good way to detect this condition in general.
> The hardest problem to solve is distinguishing between a password > being transported in the clear, versus an HTTP request that happens to > coincidentally contain the text of a password form field. Of course > if it's a vanilla form submission you can tell for sure. But a > javascript driven request removes certainty since you don't know > exactly they're using the password to form the HTTP request.
How common is this situation, though? I'd think most login situation are in fact vanilla form submissions (which includes scripted form submissions, of course; it's all the same to the form submission code).
> What do you think? Worth doing, or no?
I think it'd be a heck of a lot more useful than warning on all insecure form submits.... Might be useful enough that I'd even turn it on by default.
The funny thing is I forgot Firefox has an insecure form submission warning. It's so intrusive and frequent that I'm sure everyone turns it off. Dialing it back to status bar text, making it specific to forms with password fields, and making it specific to HTTP requests that include the text of the password field should be helpful.
Regarding form submission types, I agree that most form submissions are vanilla. Indeed I looked at Facebook and Twitter; they both use vanilla submissions.
Slide.com is a good example of a javascript driven form; it just uses onsubmit="AppBase.login()" which creates, in this case, an INSECURE HTTP POST that includes "&password=foo" in the body. So that's a slightly harder edge case to handle.
RE detecting an unsecure wireless network (optional as far as the fundamental idea is concerned, but would be a great user experience I think, and definitely a wow moment), yes we'd probably have to add new code to the os abstraction layer. For windows there's a reasonably good API for doing this (the 'native wifi' api). We could approximate what we're after by just detecting the presence of a connected unsecure wifi adapter, and skipping trying to figure out if our specific HTTP request will go out over that adapter. There's also a graceful way to degrade if for whatever reason wifi status isn't available (e.g. on windows 2000).
> The funny thing is I forgot Firefox has an insecure form submission > warning. It's so intrusive and frequent that I'm sure everyone turns > it off. Dialing it back to status bar text, making it specific to > forms with password fields, and making it specific to HTTP requests > that include the text of the password field should be helpful.
I'm not sure why this last is needed if we're looking at a submission of a form with a password field to a non-https:// URL.
Ideally we'd do this also for cases when the originating URL is non-https://; I wonder how many banks would start hating us if we did.
> Slide.com is a good example of a javascript driven form; it just uses > onsubmit="AppBase.login()" which creates, in this case, an INSECURE > HTTP POST that includes "&password=foo" in the body. So that's a > slightly harder edge case to handle.
It sends this via XHR or something? I'm not sure there's a good way to correlate that back with a password field, unless we scan all XHRs done by pages with password fields on them or something. And even then, the POST data could encode the password in various ways that would defeat this mechanism without improving security.
On the other hand, the slide.com case would be caught by the "originating page is http://" clause above... Maybe that's a better approach? After all, if your login page is not https:// then it's trivial to MITM sniff your password no matter where the form action points. And if your login page _is_ https:// but your form action is http, then... does that ever happen? ;)
> <snip> > On the other hand, the slide.com case would be caught by the > "originating page is http://" clause above... Maybe that's a better > approach? After all, if your login page is not https:// then it's > trivial to MITM sniff your password no matter where the form action > points. And if your login page _is_ https:// but your form action is > http, then... does that ever happen? ;)
Heh, actually, looks like the form submission checks we currently have have a separate warning for that, so maybe it does? ;-)
(note also the *lack* of warning if you're currently on an insecure page and submitting to a secure one)
So it sounds like this could even be done from an add-on with relative ease - you can observe the topic "formsubmit" with the observer service, and then cancel it once the notification comes in.
Question is, should we want this to be an add-on, or should we just alter the current "silly" warning to only warn if passwords are submitted? As far as I can tell, the warning is now completely turned off by default. Seems more sensible to have it be useful and turn it back on (or, if really really really paranoid people *want* the normal warning, add this one and enable it for all users rather than for nobody).
> 7 out of 36 top web sites still transmit login passwords in the > clear. I documented this recently in a blog post (http://tinyurl.com/ > ycg4acv), and I'm trying to find solutions.
I agree that the current state of affairs sucks, but I'm very wary of adding this kind of nagging UI. [Well, more specifically, having it on by default. I don't think I'd object to having it optionally available.]
The problem is a combination of it being (1) a technical thing many users won't understand (2) having a high false-positive rate (ie, odds are no one is *actually* looking at the data), and (3) there's nothing the user can do to correct the problem, other than not using the site. #3 is probably the worst, because by the time someone is submitting a password somewhere, they've already made a decision to use the site (eg, done their shopping, filled their cart, created an account, then boom), so vague warnings are an ineffective deterrent. It might be more useful on sites that have both secure and insecure login pages, if we could suggest using the secure page instead, but knowing where to redirect the login (and when it's safe to do so) seems like it would be hard.
> This is problem for (a) folks surfing the net over an unsecured > wireless network, and (b) folks surfing in other conditions where > their traffic may be monitored, most notably in states like Iran where > use of deep packet inspection is well documented.
TBH, neither of these cases are compelling to me. Passive monitoring is pass , active MITM is all the rage now. If you're on an untrusted WiFi network, you should assume it has maliciously modified the page and is grabbing keystrokes as you type the password, before a form submission ever happens. You don't have any assurance who you're communicating with unless it's SSL, hence the stronger Bad Certificate warnings in Firefox 3.
There has been some interest in adding a "SSL only" mode, so that when you're on an insecure network you can simply disable non-SSL connections... It's not so useful for general browsing, but is good for making sure you don't accidentally get pwned when checking Gmail.
> We can then do either of the following:
> 1) provide a hint at the bottom of the toolbar stating "this web site > may have sent your password unprotected [more info]", or
It might be more interesting to put up a notification *before* the form is submitted (ie, when the page first loads).
Though this wouldn't help for malicious sites (you could spoof a password input field without using a real <input type="password>), or sites that change the form's action.
Also consider logins that are done purely through AJAX... No form submission to watch for.
> TBH, neither of these cases are compelling to me. Passive monitoring is > passé, active MITM is all the rage now. If you're on an untrusted WiFi > network, you should assume it has maliciously modified the page and is > grabbing keystrokes as you type the password, before a form submission > ever happens
Which is why the only way to make this safe is to put pressure on website authors to have all login pages SSL, always. Then train the user that if the login page (the one you're putting your password into) doesn't have the lock icon then they should run, not walk, away.
> Then train the user that if the login page (the one you're putting > your password into) doesn't have the lock icon then they should run, > not walk, away.
The trouble is that for many people, not using that website would be perceived as a bigger issue than being insecure. A little inconsequential warning dialog isn't going to change that much.
> The trouble is that for many people, not using that website would be > perceived as a bigger issue than being insecure. A little > inconsequential warning dialog isn't going to change that much.
Yep.
One thing I've been doing for myself is using long passwords and saving them with the password manager (which won't fill out an https:// login on an http:// site). If I stumble across the wrong login page for a site (like Twitter), I find that I can't be bothered to find my password (which I don't remember) to type it in manually, it's easier to just find the right login page. Making the password manager more appealing to people so they *want* to use it and then they *complain* when it a site doesn't work well with it helps for the not-always-SSL case as a side effect.
But I don't think that's going to be a strong motivator some many sites. I think the only thing that's really going to improve the situation is for better identity / authentication mechanisms to widely adopted, and displace the quaint old method of posting text passwords in forms.
Oops, my quota of wishful thinking is up for the day!
On Jan 18, 12:44 pm, Blair McBride <bmcbr...@mozilla.com> wrote:
> On 18/01/2010 1:44 p.m., Boris Zbarsky wrote:
> > Then train the user that if the login page (the one you're putting > > your password into) doesn't have the lock icon then they should run, > > not walk, away.
> The trouble is that for many people, not using that website would be > perceived as a bigger issue than being insecure. A little > inconsequential warning dialog isn't going to change that much.
> - Blair
I think we are on the right trail. I agree that popup notifications don't work, most notably because users are task focused and just want to use the site. Users are also unlikely to change the web sites they want to use when they are on insecure wireless networks; they will expect the same surfing experience.
The lowest hanging fruit is going to be encouraging _major_ web site owners to secure their login pages -- like the top 2000 sites. We don't have strong enough sticks to get every web site, but fortunately the top 5% of web sites are going to represent 95% of traffic. (I'm pulling numbers out of thin air but it's certainly going to be a pareto distribution.)
Here's a new / refined proposal: whenever a password is sent insecurely, provide some hint text to the user in the status bar, maybe with text suggesting that the user can contact the website operator for more info / to redress, and/or providing a mailto: with the web site's whois technical contact.
Maybe show the text for some number of seconds and then fade it away. (?)
I'm still not sure how to handle javascript. It's definitely needed. Maybe if javascript sends an HTTP request when a password field has been filled we show the alert, up to once, if there hasn't been an intermediate HTTPS request. This would at least sidestep looking inside the HTTP request for the password in plaintext. (I know I'm still drawing at straws here a bit / being imprecise. Would welcome further thoughts!)
> I'm still not sure how to handle javascript. It's definitely needed. > Maybe if javascript sends an HTTP request when a password field has > been filled we show the alert, up to once, if there hasn't been an > intermediate HTTPS request. This would at least sidestep looking > inside the HTTP request for the password in plaintext. (I know I'm > still drawing at straws here a bit / being imprecise. Would welcome > further thoughts!)
Show a warning (not alert; notification bar) any time the user is typing in a password field when either the document is HTTP?
That, plus downgrading the security state if an HTTPS document makes HTTP requests at all might work...
On Jan 19, 7:50 am, Boris Zbarsky <bzbar...@mit.edu> wrote:
> Show a warning (not alert; notification bar) any time the user is typing > in a password field when either the document is HTTP?
> That, plus downgrading the security state if an HTTPS document makes > HTTP requests at all might work...
> -Boris
Can't reasonably do that because many secure login pages are HTTP. For example, facebook.com uses HTTPS for its form submission but the form and post-login page are both HTTP.
(I know that means an active man in the middle could change the login form code, but that is beyond the scope of what we'll be able to fight for today.)
Alright fellow firefox followers, where do we go from here? There might be a document or past thread that explains this, but can someone give me a quick pointer on how the change process works around here?
Should I start writing an implementation of my latest proposal? Who makes the final call on whether it gets in? Is there a way or process to test it with users? Etc?
I'm pretty excited about moving forward after this discussion!!!
> Alright fellow firefox followers, where do we go from here? There > might be a document or past thread that explains this, but can someone > give me a quick pointer on how the change process works around here?
