Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
stealing saved passwords
108 views
Skip to first unread message
Jesse Ruderman
Apr 11, 2012, 3:54:53 AM4/11/12
to dev-se...@lists.mozilla.org
A wifi MITM attacker can steal all the passwords you have saved on
http sites, by sending you to fake versions of each site and watching
what the browser fills into the form.
You're safe iff you initially saved the password from an https page,
or if the site now uses STS, or maybe if you're extremely careful to
never open any http pages while connected to untrusted networks.
I have some ideas for mitigating this risk.
1) If a site sends an STS header, and the user has any data (cookies,
passwords, etc) that are not https-only, immediately mark that data as
https-only. (This helps if a site uses STS, but the user's privacy
settings cause the password storage to outlive the STS storage.)
2) When clearing history, retain the STS bit if any other data
associated with the site is retained. For example, in the common case
of clearing all history other than passwords, retain the STS bits for
sites that have passwords stored. (This accomplishes roughly the same
thing as #1.)
3) If you have a password stored for http, and you log into the same
site using https, move the password to https-only. (This helps if a
site moves from http to https, but does not set STS.)
4) If an identical password is stored for both any http site and any
https site, stop autofilling it on the http site. Instead, provide a
way for users to instruct the browser to fill it in (e.g. an infobar).
5) If an identical password is stored for both any http site and any
https site, and it is not used on the http site for 16 months, expire
the http version. (This helps in cases where the hostname has changed,
e.g. from mail.google.com to www.google.com, and the security level
has also changed.)
6) When connected to an untrusted wireless network, don't fill in passwords.
7) When connected to an untrusted wireless network, refuse to make any
insecure connections. If the user really wants to open an insecure
search result, they can open it in a separate browsing session.
Which of these seem practical and worth implementing?
http sites, by sending you to fake versions of each site and watching
what the browser fills into the form.
You're safe iff you initially saved the password from an https page,
or if the site now uses STS, or maybe if you're extremely careful to
never open any http pages while connected to untrusted networks.
I have some ideas for mitigating this risk.
1) If a site sends an STS header, and the user has any data (cookies,
passwords, etc) that are not https-only, immediately mark that data as
https-only. (This helps if a site uses STS, but the user's privacy
settings cause the password storage to outlive the STS storage.)
2) When clearing history, retain the STS bit if any other data
associated with the site is retained. For example, in the common case
of clearing all history other than passwords, retain the STS bits for
sites that have passwords stored. (This accomplishes roughly the same
thing as #1.)
3) If you have a password stored for http, and you log into the same
site using https, move the password to https-only. (This helps if a
site moves from http to https, but does not set STS.)
4) If an identical password is stored for both any http site and any
https site, stop autofilling it on the http site. Instead, provide a
way for users to instruct the browser to fill it in (e.g. an infobar).
5) If an identical password is stored for both any http site and any
https site, and it is not used on the http site for 16 months, expire
the http version. (This helps in cases where the hostname has changed,
e.g. from mail.google.com to www.google.com, and the security level
has also changed.)
6) When connected to an untrusted wireless network, don't fill in passwords.
7) When connected to an untrusted wireless network, refuse to make any
insecure connections. If the user really wants to open an insecure
search result, they can open it in a separate browsing session.
Which of these seem practical and worth implementing?
Kevin Chadwick
Apr 11, 2012, 6:04:26 AM4/11/12
to dev-se...@lists.mozilla.org
On Wed, 11 Apr 2012 00:54:53 -0700
Jesse Ruderman wrote:
> 1) If a site sends an STS header
In my opinion STS shouldn't be implemented professionally in it's
Jesse Ruderman wrote:
> 1) If a site sends an STS header
current state and with browsers treatment of valid dates. I looked to
implementing it and then realised that a user with a flat bios battery
(such as my mate) would be given DOS to my websites due to an incorrect
date and so certificate. I mailed an RFC maintainer but he saw that as
a users problem to fix. My mate would have no idea where to get that
battery from, never mind fit it unless I found the time and helped him.
There must be thousands if not millions like him.
SSL needs fixing properly with far less CAs. MITM shouldn't occur but
users should be protected as much as possible from it as it is a
rediculously possible occurence against the majority. A valid
certificate for a different site could also easily fool a user anyway.
Maybe (though I think SSL should be fixed at source by controlling cert
issue better and only by domain validation as it costs little more to
forge a company), accessing a non initially physically user interacted
ssl domain could throw a warning across the board (such as redirects),
blocking would likely break some sites and maybe email links.
> When clearing history, retain the STS bit
> When connected to an untrusted wireless network
hardware keyloggers being a greater risk as things like comodo firewall
and various other intenet services or home servers do/can provide VPNs.
I don't use the pass manager or form filler except when testing sites,
but they seem like reasonable ideas.
Gervase Markham
Apr 11, 2012, 10:47:28 AM4/11/12
to Jesse Ruderman
On 11/04/12 08:54, Jesse Ruderman wrote:
> 1) If a site sends an STS header, and the user has any data (cookies,
> passwords, etc) that are not https-only, immediately mark that data as
> https-only. (This helps if a site uses STS, but the user's privacy
> settings cause the password storage to outlive the STS storage.)
Sounds sensible.
> 1) If a site sends an STS header, and the user has any data (cookies,
> passwords, etc) that are not https-only, immediately mark that data as
> https-only. (This helps if a site uses STS, but the user's privacy
> settings cause the password storage to outlive the STS storage.)
> 2) When clearing history, retain the STS bit if any other data
> associated with the site is retained. For example, in the common case
> of clearing all history other than passwords, retain the STS bits for
> sites that have passwords stored. (This accomplishes roughly the same
> thing as #1.)
visited a site, then that fact is not hidden if you have a stored
password for it. Given that, there is no additional privacy issue with
retaining STS data also.
> 3) If you have a password stored for http, and you log into the same
> site using https, move the password to https-only. (This helps if a
> site moves from http to https, but does not set STS.)
"autofill stopped working on this site", whereas what actually happened
is that, just once, they clicked on an HTTPS link to visit the site
rather than HTTP.
> 5) If an identical password is stored for both any http site and any
> https site, and it is not used on the http site for 16 months, expire
> the http version. (This helps in cases where the hostname has changed,
> e.g. from mail.google.com to www.google.com, and the security level
> has also changed.)
> 6) When connected to an untrusted wireless network, don't fill in passwords.
Gerv
Ian Melven
Apr 11, 2012, 12:47:19 PM4/11/12
to Jesse Ruderman, dev-se...@lists.mozilla.org
Hi,
I agree with Gerv that #1 seems good.
#2, i have a slight concern about history leakage but don't think
this is an issue for correctly set up STS sites, and this isn't
an issue with the actual proposal here - which seems like a good
addition to #1
I also agree with Gerv that #3 definitely could confuse users,
assuming the site still allows http (which, it could be argued,
would be an incorrectly set up site).
#5 definitely seems good - i assume 16 months is arbitrary :)
#6 and #7 seem less practical to me.
slightly related : https://wiki.mozilla.org/Security/Features/HighlightCleartextPasswords
this won't help in the case of autofill though
thanks !
ian
----- Original Message -----
From: "Jesse Ruderman" <jrud...@gmail.com>
To: dev-se...@lists.mozilla.org
Sent: Wednesday, April 11, 2012 12:54:53 AM
Subject: stealing saved passwords
A wifi MITM attacker can steal all the passwords you have saved on
http sites, by sending you to fake versions of each site and watching
what the browser fills into the form.
You're safe iff you initially saved the password from an https page,
or if the site now uses STS, or maybe if you're extremely careful to
never open any http pages while connected to untrusted networks.
I have some ideas for mitigating this risk.
1) If a site sends an STS header, and the user has any data (cookies,
passwords, etc) that are not https-only, immediately mark that data as
https-only. (This helps if a site uses STS, but the user's privacy
settings cause the password storage to outlive the STS storage.)
passwords, etc) that are not https-only, immediately mark that data as
https-only. (This helps if a site uses STS, but the user's privacy
settings cause the password storage to outlive the STS storage.)
2) When clearing history, retain the STS bit if any other data
associated with the site is retained. For example, in the common case
of clearing all history other than passwords, retain the STS bits for
sites that have passwords stored. (This accomplishes roughly the same
thing as #1.)
associated with the site is retained. For example, in the common case
of clearing all history other than passwords, retain the STS bits for
sites that have passwords stored. (This accomplishes roughly the same
thing as #1.)
3) If you have a password stored for http, and you log into the same
site using https, move the password to https-only. (This helps if a
site moves from http to https, but does not set STS.)
site using https, move the password to https-only. (This helps if a
site moves from http to https, but does not set STS.)
4) If an identical password is stored for both any http site and any
https site, stop autofilling it on the http site. Instead, provide a
way for users to instruct the browser to fill it in (e.g. an infobar).
https site, stop autofilling it on the http site. Instead, provide a
way for users to instruct the browser to fill it in (e.g. an infobar).
5) If an identical password is stored for both any http site and any
https site, and it is not used on the http site for 16 months, expire
the http version. (This helps in cases where the hostname has changed,
e.g. from mail.google.com to www.google.com, and the security level
has also changed.)
https site, and it is not used on the http site for 16 months, expire
the http version. (This helps in cases where the hostname has changed,
e.g. from mail.google.com to www.google.com, and the security level
has also changed.)
6) When connected to an untrusted wireless network, don't fill in passwords.
7) When connected to an untrusted wireless network, refuse to make any
insecure connections. If the user really wants to open an insecure
search result, they can open it in a separate browsing session.
Which of these seem practical and worth implementing?
_______________________________________________
insecure connections. If the user really wants to open an insecure
search result, they can open it in a separate browsing session.
Which of these seem practical and worth implementing?
dev-security mailing list
dev-se...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
Eric Chen
Apr 11, 2012, 2:20:17 PM4/11/12
to Ian Melven, dev-se...@lists.mozilla.org, Jesse Ruderman
*Hello Everyone:
I am Eric Chen from CMU. We are working on a paper that is closely related
to the topic of this discussion, so I thought I should bring it up. Our
paper describes an attack that automatically crawls the password manager of
an user inside an unsecure wireless network. The attack can be launched as
follows:
1. User visits “any” unencrypted page inside a wireless network (e.g., it
can be their home page http://www.google.com) <about:blank>
2. Attacker use ARP spoofing attack to impersonate the gateway to intercept
traffic.
3. Attacker injects 1000 (an arbitrary number) invisible iframes, each
points to a different HTTP login page of the Alexa top 1000 sites (i.e.,
http://facebook.com, <about:blank> http://twitter.com). There are simple
tricks to make these iframes invisible to normal users, but for the sake of
simplicity, I won’t discuss them here.
4. Inside each of these iframes, attacker injects a username field, a
password field, and a script to read the autofilled password.
5. Browser autofills password for each of the 1000 sites, attacker reads
it, and send it back.
What’s interesting about this attack is that it’s very stealthy (virtually
undetectable), fast, and does not require the user to visit the vulnerable
page. Furthermore, even if the website moves all login forms to HTTPS
pages, the old passwords are still vulnerable.
We are also interested in a defense for this. The defense that we came up
with is actually very similar to proposal 1) and 3). Furthermore, for sites
that do not use HSTS, we were planning to check if the form target is a
HTTPS page, if it is, then we redirect the user to the HTTPS version of the
same page (if it exists).
As a side note, this automatic attack does not work for IE and Opera,
because these two password managers require the user to initiate the
autofilling process (by entering the first character into the username
box). *
--
-Eric
I am Eric Chen from CMU. We are working on a paper that is closely related
to the topic of this discussion, so I thought I should bring it up. Our
paper describes an attack that automatically crawls the password manager of
an user inside an unsecure wireless network. The attack can be launched as
follows:
1. User visits “any” unencrypted page inside a wireless network (e.g., it
can be their home page http://www.google.com) <about:blank>
2. Attacker use ARP spoofing attack to impersonate the gateway to intercept
traffic.
3. Attacker injects 1000 (an arbitrary number) invisible iframes, each
points to a different HTTP login page of the Alexa top 1000 sites (i.e.,
http://facebook.com, <about:blank> http://twitter.com). There are simple
tricks to make these iframes invisible to normal users, but for the sake of
simplicity, I won’t discuss them here.
4. Inside each of these iframes, attacker injects a username field, a
password field, and a script to read the autofilled password.
5. Browser autofills password for each of the 1000 sites, attacker reads
it, and send it back.
What’s interesting about this attack is that it’s very stealthy (virtually
undetectable), fast, and does not require the user to visit the vulnerable
page. Furthermore, even if the website moves all login forms to HTTPS
pages, the old passwords are still vulnerable.
We are also interested in a defense for this. The defense that we came up
with is actually very similar to proposal 1) and 3). Furthermore, for sites
that do not use HSTS, we were planning to check if the form target is a
HTTPS page, if it is, then we redirect the user to the HTTPS version of the
same page (if it exists).
As a side note, this automatic attack does not work for IE and Opera,
because these two password managers require the user to initiate the
autofilling process (by entering the first character into the username
box). *
-Eric
Justin Dolske
Apr 11, 2012, 6:37:58 PM4/11/12
to mozilla-de...@lists.mozilla.org
On 4/11/12 12:54 AM, Jesse Ruderman wrote:
> 1) If a site sends an STS header, and the user has any data (cookies,
> passwords, etc) that are not https-only, immediately mark that data as
> https-only. (This helps if a site uses STS, but the user's privacy
> settings cause the password storage to outlive the STS storage.)
Seems reasonable, because if STS is in effect the browser shouldn't ever
> 1) If a site sends an STS header, and the user has any data (cookies,
> passwords, etc) that are not https-only, immediately mark that data as
> https-only. (This helps if a site uses STS, but the user's privacy
> settings cause the password storage to outlive the STS storage.)
be talking to it over plain-old http, right? [At least to a first
approximation, sounds like there may be some details to think though?]
> 2) When clearing history, retain the STS bit if any other data
> associated with the site is retained. For example, in the common case
> of clearing all history other than passwords, retain the STS bits for
> sites that have passwords stored. (This accomplishes roughly the same
> thing as #1.)
a singular or fast way to check if we know anything about site X.
> 3) If you have a password stored for http, and you log into the same
> site using https, move the password to https-only. (This helps if a
> site moves from http to https, but does not set STS.)
process of adding SSL I had frustrations where there were different ways
to login, some SSL and some not. And because the password manager
strictly enforces protocol matching, you'd be SOL.
OTOH, this is a frequent enough problem that I would like to look into
ways of having the password manager give the user a way to use an
existing login when similar enough. eg https://site.com vs
http://site.com, www.foo.com vs foo.com, etc.
> 4) If an identical password is stored for both any http site and any
> https site, stop autofilling it on the http site. Instead, provide a
> way for users to instruct the browser to fill it in (e.g. an infobar).
I wonder if this should just be more general: if we see history for the
SSL version of the site, offer to redirect over to SSL. Though that
probably doesn't work for a lot of sites. So perhaps offer if you're (1)
on not-SSL and (2) there's SSL history and (3) there's any password
field (stored or not).
> 5) If an identical password is stored for both any http site and any
> https site, and it is not used on the http site for 16 months, expire
> the http version. (This helps in cases where the hostname has changed,
> e.g. from mail.google.com to www.google.com, and the security level
> has also changed.)
> 6) When connected to an untrusted wireless network, don't fill in passwords.
has such a notion. Might be able to usefully approximate this in the
browser by keeping track of which networks you've used in the last X
days, and treating new networks as untrusted.
> 7) When connected to an untrusted wireless network, refuse to make any
> insecure connections. If the user really wants to open an insecure
> search result, they can open it in a separate browsing session.
One additional mitigation: refuse to autofill within iframes. Bulk
harvesting would seem harder (or at least slower) if an attacker if
forced to cause new windows/tabs to open. Well, maybe... I guess if
you're allowing page modifications, one just needs a window.onload
handler to navigate to the next site on the list. [Insert side
discussion here about stealing login-cookies from site's you're already
logged into.]
Justin
Kevin Chadwick
Apr 13, 2012, 8:20:51 AM4/13/12
to dev-se...@lists.mozilla.org
On Wed, 11 Apr 2012 11:20:17 -0700
Eric Chen wrote:
> We are also interested in a defense for this. The defense that we came up
> with is actually very similar to proposal 1) and 3)
If you can work it without STS, do so as anything that turns users away
Eric Chen wrote:
> We are also interested in a defense for this. The defense that we came up
> with is actually very similar to proposal 1) and 3)
will not get widespread adoption especially as STS appears to be seen as
quite fallible.
Henri Sivonen
Apr 13, 2012, 9:25:26 AM4/13/12
to dev-se...@lists.mozilla.org
On Wed, Apr 11, 2012 at 10:54 AM, Jesse Ruderman <jrud...@gmail.com> wrote:
> A wifi MITM attacker can steal all the passwords you have saved on
> http sites, by sending you to fake versions of each site and watching
> what the browser fills into the form.
Last I had the misfortune to be able to check, Firefox was happy to
> A wifi MITM attacker can steal all the passwords you have saved on
> http sites, by sending you to fake versions of each site and watching
> what the browser fills into the form.
perform autofill on a non-EV-https site using passwords remembered
when the site used EV-https. Thus, EV doesn't protect against advanced
advanced MITM that can fake non-EV certs. (Dunno how important this
concern is. That is, I don't know how realistic it is for a MITM to
gain the capability to fake non-EV certificates but not to gain the
capability to fake EV certificates.)
> 6) When connected to an untrusted wireless network, don't fill in passwords.
After all, an encrypted wireless network could be operated by an
untrusted party such as a hotel.
It would be great if Firefox detected captain portals, though. It's
super-annoying to lose session state because restored tabs start
loading before you've logged in to a captive portal.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Kevin Chadwick
Apr 13, 2012, 11:34:53 AM4/13/12
to dev-se...@lists.mozilla.org
On Fri, 13 Apr 2012 16:25:26 +0300
Henri Sivonen wrote:
> (Dunno how important this
> concern is. That is, I don't know how realistic it is for a MITM to
> gain the capability to fake non-EV certificates but not to gain the
> capability to fake EV certificates.)
EV certs are pointless except for making money for CAs as sites worry
Henri Sivonen wrote:
> (Dunno how important this
> concern is. That is, I don't know how realistic it is for a MITM to
> gain the capability to fake non-EV certificates but not to gain the
> capability to fake EV certificates.)
unfortuantely quite rightly that without an EV they will lose customers.
In security terms the world is worse with the false sense of security
that EV brings than without EV at all.
Lucas Adamski
Apr 13, 2012, 2:14:13 PM4/13/12
to Henri Sivonen, dev-se...@lists.mozilla.org
On Apr 13, 2012, at 6:25 AM, Henri Sivonen wrote:
> On Wed, Apr 11, 2012 at 10:54 AM, Jesse Ruderman <jrud...@gmail.com> wrote:
>> A wifi MITM attacker can steal all the passwords you have saved on
>> http sites, by sending you to fake versions of each site and watching
>> what the browser fills into the form.
>
> Last I had the misfortune to be able to check, Firefox was happy to
> perform autofill on a non-EV-https site using passwords remembered
> when the site used EV-https. Thus, EV doesn't protect against advanced
> advanced MITM that can fake non-EV certs. (Dunno how important this
> On Wed, Apr 11, 2012 at 10:54 AM, Jesse Ruderman <jrud...@gmail.com> wrote:
>> A wifi MITM attacker can steal all the passwords you have saved on
>> http sites, by sending you to fake versions of each site and watching
>> what the browser fills into the form.
>
> Last I had the misfortune to be able to check, Firefox was happy to
> perform autofill on a non-EV-https site using passwords remembered
> when the site used EV-https. Thus, EV doesn't protect against advanced
> concern is. That is, I don't know how realistic it is for a MITM to
> gain the capability to fake non-EV certificates but not to gain the
> capability to fake EV certificates.)
The better solution to that problem might be: https://wiki.mozilla.org/Security/Features/CA_pinning_functionality
> gain the capability to fake non-EV certificates but not to gain the
> capability to fake EV certificates.)
Lucas.
Tanvi Vyas
Apr 16, 2012, 2:21:00 AM4/16/12
to dev-se...@lists.mozilla.org
There are some great ideas here. I think we should create a feature
page for at least #1&2 and add it to the Security Roadmap. I also think
we can do #5.
To go into detail...
On 4/11/12 12:54 AM, Jesse Ruderman wrote:
> 1) If a site sends an STS header, and the user has any data (cookies,
> passwords, etc) that are not https-only, immediately mark that data as
> https-only. (This helps if a site uses STS, but the user's privacy
> settings cause the password storage to outlive the STS storage.)
If a site is marked STS but a website (or by a user with ForceTLS), then
there is no reason to have http data for that site.
> 2) When clearing history, retain the STS bit if any other data
> associated with the site is retained. For example, in the common case
> of clearing all history other than passwords, retain the STS bits for
> sites that have passwords stored. (This accomplishes roughly the same
> thing as #1.)
If we are saving data from the site that can be used for fingerprinting
anyway, retaining the STS bit shouldn't cause any further fingerprinting
issues.
> 3) If you have a password stored for http, and you log into the same
> site using https, move the password to https-only. (This helps if a
> site moves from http to https, but does not set STS.)
This doesn't really work. Twitter and Facebook have login on both http
and https pages. So sometimes the users password will be auto-filled
and sometimes it won't. Hence, I think this proposal is out.
> 4) If an identical password is stored for both any http site and any
> https site, stop autofilling it on the http site. Instead, provide a
> way for users to instruct the browser to fill it in (e.g. an infobar).
I don't think this is going to fly either. Users will constantly get
this infobar on the http versions of facebook and twitter.
> 6) When connected to an untrusted wireless network, don't fill in passwords.
We aren't sure what networks are trusted vs untrusted. Instead of
starting with a heuristic that tries to guess this, what if we start off
with including an "network untrusted" mode in Firefox. When a user
enables this mode, passwords aren't auto-filled and inactive tabs aren't
allowed to send/receive requests. This way, when I connect to wifi at
an airport/hotel and have 3 windows open with 10 tabs each, there are no
http requests going out from any of the tabs except for the 1 active tab
I'm using. The user is aware they are using the active tab and is aware
of what websites they are visiting via http (and hence which cookies
they are exposing).
(Whenever I connect to an untrusted network, I first turn firefox to
work offline mode. Then connect to the network and vpn in. Once I'm
vpn'ed, I take firefox off work offline mode. This way, no requests are
sent with my cookies from one of my open tabs before I have a chance to
vpn. Yes, I know I am paranoid).
Adding 8 from Justin Dolske:
8)
widget that did this a little more than a year ago, and maybe still
does). This would break all sites that have their login form in an iframe.
~Tanvi
page for at least #1&2 and add it to the Security Roadmap. I also think
we can do #5.
To go into detail...
On 4/11/12 12:54 AM, Jesse Ruderman wrote:
> 1) If a site sends an STS header, and the user has any data (cookies,
> passwords, etc) that are not https-only, immediately mark that data as
> https-only. (This helps if a site uses STS, but the user's privacy
> settings cause the password storage to outlive the STS storage.)
there is no reason to have http data for that site.
> 2) When clearing history, retain the STS bit if any other data
> associated with the site is retained. For example, in the common case
> of clearing all history other than passwords, retain the STS bits for
> sites that have passwords stored. (This accomplishes roughly the same
> thing as #1.)
anyway, retaining the STS bit shouldn't cause any further fingerprinting
issues.
> 3) If you have a password stored for http, and you log into the same
> site using https, move the password to https-only. (This helps if a
> site moves from http to https, but does not set STS.)
and https pages. So sometimes the users password will be auto-filled
and sometimes it won't. Hence, I think this proposal is out.
> 4) If an identical password is stored for both any http site and any
> https site, stop autofilling it on the http site. Instead, provide a
> way for users to instruct the browser to fill it in (e.g. an infobar).
this infobar on the http versions of facebook and twitter.
> 5) If an identical password is stored for both any http site and any
> https site, and it is not used on the http site for 16 months, expire
> the http version. (This helps in cases where the hostname has changed,
> e.g. from mail.google.com to www.google.com, and the security level
> has also changed.)
Sounds good.
> https site, and it is not used on the http site for 16 months, expire
> the http version. (This helps in cases where the hostname has changed,
> e.g. from mail.google.com to www.google.com, and the security level
> has also changed.)
> 6) When connected to an untrusted wireless network, don't fill in passwords.
starting with a heuristic that tries to guess this, what if we start off
with including an "network untrusted" mode in Firefox. When a user
enables this mode, passwords aren't auto-filled and inactive tabs aren't
allowed to send/receive requests. This way, when I connect to wifi at
an airport/hotel and have 3 windows open with 10 tabs each, there are no
http requests going out from any of the tabs except for the 1 active tab
I'm using. The user is aware they are using the active tab and is aware
of what websites they are visiting via http (and hence which cookies
they are exposing).
(Whenever I connect to an untrusted network, I first turn firefox to
work offline mode. Then connect to the network and vpn in. Once I'm
vpn'ed, I take firefox off work offline mode. This way, no requests are
sent with my cookies from one of my open tabs before I have a chance to
vpn. Yes, I know I am paranoid).
>
> 7) When connected to an untrusted wireless network, refuse to make any
> insecure connections. If the user really wants to open an insecure
> search result, they can open it in a separate browsing session.
I also don't think this will fly.
> 7) When connected to an untrusted wireless network, refuse to make any
> insecure connections. If the user really wants to open an insecure
> search result, they can open it in a separate browsing session.
Adding 8 from Justin Dolske:
8)
>
> One additional mitigation: refuse to autofill within iframes. Bulk
> harvesting would seem harder (or at least slower) if an attacker if
> forced to cause new windows/tabs to open. Well, maybe... I guess if
> you're allowing page modifications, one just needs a window.onload
> handler to navigate to the next site on the list. [Insert side
> discussion here about stealing login-cookies from site's you're already
> logged into.]
>
What if a site allows login via an iframe widget (ex: twitter had a
> One additional mitigation: refuse to autofill within iframes. Bulk
> harvesting would seem harder (or at least slower) if an attacker if
> forced to cause new windows/tabs to open. Well, maybe... I guess if
> you're allowing page modifications, one just needs a window.onload
> handler to navigate to the next site on the list. [Insert side
> discussion here about stealing login-cookies from site's you're already
> logged into.]
>
widget that did this a little more than a year ago, and maybe still
does). This would break all sites that have their login form in an iframe.
~Tanvi
Tanvi Vyas
May 25, 2012, 6:55:25 PM5/25/12
to Eric Chen, dev-se...@lists.mozilla.org, Ian Melven
Hi Eric,
Great paper! I enjoyed reading it and found that some of your research
might be helpful for a feature that I'm working on:
https://wiki.mozilla.org/Security/Features/HighlightCleartextPasswords.
I too am looking at password fields that are served over http. I am
also looking for password fields hosted on https pages but sent over
http (a much more rare case). And will later consider https page with
mixed script content.
After reading your paper, I'm more inclined to create a Security Roadmap
item to improve our password manager with some of the ideas discussed
earlier on this thread. (Ex: Require user interaction before
autocompleting passwords on http pages- multiuser experience; remove
http passwords for pages that have sts set; attempt to fetch an https
version of a page if it exists and redirect user before autocompleting
the password.) This last item is something that I am trying to do for
all http pages with password fields; regardless of whether the password
is stored in password manager. This won't be too difficult for sites
where the http url and https url only differ by the protocol, but will
be more complicated when the https login page is on a different
subdomain or path.
I have a few questions and comments below:
* The word first is misspelled in the sentence "Fist, the malicious
iframes are made to be hidden from the victims."
* Is there a typo here? Should one of these be HTTP: "To protect
passwords submitted to web pages served in HTTPS, one could forbid the
password manager to auto-fill any login forms containing an HTTPS
destination address. "
* I have some questions on the stats you obtained from Alexa's top
website list and want to see if I can leverage that data for the feature
I'm working on. I'll send you a separate email for that.
Thanks!
~Tanvi
On 5/24/12 1:51 PM, Eric Chen wrote:
> I want to bring everyone's attention to our paper -- "Automated
> Password Extraction Attack on Modern Password Managers" (attached in
> this email). This is still a working copy and we can use some useful
> feedback :)
>
> Thanks,
> e.g. from mail.google.com <http://mail.google.com> to
> www.google.com <http://www.google.com>, and the security level
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org <mailto:dev-se...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security
>
>
>
>
> --
> -Eric
>
Great paper! I enjoyed reading it and found that some of your research
might be helpful for a feature that I'm working on:
https://wiki.mozilla.org/Security/Features/HighlightCleartextPasswords.
I too am looking at password fields that are served over http. I am
also looking for password fields hosted on https pages but sent over
http (a much more rare case). And will later consider https page with
mixed script content.
After reading your paper, I'm more inclined to create a Security Roadmap
item to improve our password manager with some of the ideas discussed
earlier on this thread. (Ex: Require user interaction before
autocompleting passwords on http pages- multiuser experience; remove
http passwords for pages that have sts set; attempt to fetch an https
version of a page if it exists and redirect user before autocompleting
the password.) This last item is something that I am trying to do for
all http pages with password fields; regardless of whether the password
is stored in password manager. This won't be too difficult for sites
where the http url and https url only differ by the protocol, but will
be more complicated when the https login page is on a different
subdomain or path.
I have a few questions and comments below:
* The word first is misspelled in the sentence "Fist, the malicious
iframes are made to be hidden from the victims."
* Is there a typo here? Should one of these be HTTP: "To protect
passwords submitted to web pages served in HTTPS, one could forbid the
password manager to auto-fill any login forms containing an HTTPS
destination address. "
* I have some questions on the stats you obtained from Alexa's top
website list and want to see if I can leverage that data for the feature
I'm working on. I'll send you a separate email for that.
Thanks!
~Tanvi
On 5/24/12 1:51 PM, Eric Chen wrote:
> I want to bring everyone's attention to our paper -- "Automated
> Password Extraction Attack on Modern Password Managers" (attached in
> this email). This is still a working copy and we can use some useful
> feedback :)
>
> Thanks,
> www.google.com <http://www.google.com>, and the security level
> dev-security mailing list
> dev-se...@lists.mozilla.org <mailto:dev-se...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security
>
>
>
>
> --
> -Eric
>
Tanvi Vyas
May 29, 2012, 3:18:38 PM5/29/12
to dev-se...@lists.mozilla.org
I've created
https://wiki.mozilla.org//Security/Features/PasswordManagerImprovements
with some of the improvements we discussed on this thread.
> https://lists.mozilla.org/listinfo/dev-security
https://wiki.mozilla.org//Security/Features/PasswordManagerImprovements
with some of the improvements we discussed on this thread.
0 new messages