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