Insecure password transmission notifications?
Adam Smith
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.
What do you think? Worth doing, or no?
Thanks y'all!
Adam
Boris Zbarsky
> 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.
-Boris
Adam Smith
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).
Adam
Boris Zbarsky
> 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? ;)
-Boris
Gijs Kruitbosch
> <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).
~ Gijs
Justin Dolske
> 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.
Justin
Boris Zbarsky
> TBH, neither of these cases are compelling to me. Passive monitoring is
> 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.
How can we get there?
-Boris
Blair McBride
> 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
Justin Dolske
> 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!
Justin
Adam Smith
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!)
Thanks y'all, and all the best!,
Adam
Boris Zbarsky
> 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...
-Boris
Adam Smith
> 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.)
Adam
Adam Smith
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!!!
Thanks all!,
Adam
Boris Zbarsky
> 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?
https://developer.mozilla.org/en/Hacking_Mozilla (and ignore the crap at
the beginning about "daunting", please!)
> Should I start writing an implementation of my latest proposal?
If you want to, sure!
> Who makes the final call on whether it gets in?
The module owner (in this case probably for Firefox or Security).
> Is there a way or process to test it with users?
That's what nightlies are for. :)
You probably want to file a bug, mention its bug number in this thread,
then work on attaching patches there and such.
-Boris
Gervase Markham
> https://developer.mozilla.org/en/Hacking_Mozilla (and ignore the crap at
> the beginning about "daunting", please!)
Fixed.
Gerv