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,
On Sun, Apr 15, 2012 at 11:21 PM, Tanvi Vyas <ta...@mozilla.com
<mailto:ta...@mozilla.com>> wrote:
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.
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 <http://mail.google.com> to
www.google.com <http://www.google.com>, and the security level
has also changed.)
Sounds good.
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).
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.
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 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
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
<mailto:dev-security@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security
--
-Eric
