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> 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 to 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 > https://lists.mozilla.org/**listinfo/dev-security<https://lists.mozilla.org/listinfo/dev-security> > -- -Eric
_______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
