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,
On Sun, Apr 15, 2012 at 11:21 PM, Tanvi Vyas <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://lists.mozilla.org/listinfo/dev-security
--
-Eric
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
