Re: stealing saved passwords
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 #12 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-securityhttps://lists.mozilla.org/listinfo/dev-security -- -Eric ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: stealing saved passwords
There are some great ideas here. I think we should create a feature page for at least #12 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
Re: stealing saved passwords
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 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. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: stealing saved passwords
On Apr 13, 2012, at 6:25 AM, Henri Sivonen wrote: On Wed, Apr 11, 2012 at 10:54 AM, Jesse Ruderman jruder...@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 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 Lucas. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
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.) 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
Re: stealing saved passwords
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 jruder...@gmail.com To: dev-security@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.) 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 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: stealing saved passwords
*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). * On Wed, Apr 11, 2012 at 9:47 AM, Ian Melven imel...@mozilla.com wrote: 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 jruder...@gmail.com To: dev-security@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.) 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
Re: stealing saved passwords
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 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.) This will probably be hard to implement in practice, since we don't have 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.) This is likely to be a problem... For example, as Twitter was in the 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). Possibly... Though I suspect most people will see it as a whatever button. 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.) We store time-of-last-use, so this wouldn't be too hard to implement. 6) When connected to an untrusted wireless network, don't fill in passwords. Someone needs to define untrusted, but sure. ISTR Windows 7+ already 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. That's going to be a hard sell! :) 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 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
