Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
Adam Back wrote: I would think it would be safer to block the site, or provide a warning dialog. Before we do the first redirection, we do ask the user. However, since TrustBar is really part of our research on secure usability, we are aware that asking the user is a very problematic mechanism. Namely, we expect most users to simply click `yes` and forget about it. That's why I referred to it as default. Seems that I must repeat my request: a lot of you seem to agree that current browser security UI is broken, here are we developed a seemingly usable tool trying to fix it, takes 2-3 minutes to install - why don't you spend that time and then tell us how to improve (or to stop wasting our time as well as your 5 minutes)? Of course, what we'll really love (for our usability data) is for you also to get some non-expert users to try to use the system... someone who really uses e-banking and cares about the (very real threat) of spoofing/phishing... (This is what I was expecting when I started reading the head post; I was bit surprised at the interventionism to actually go ahead and fix the site, maybe that would be a better default behavior). Actually, from other feedback we got, I think we may extend the mechanism to be even more active, to protect also these pages which are not in our list of `known` unprotected login sites with a protected alternate site. What we may do is to archive a copy of these sites in your machine, and redirect you to the archived copy if/when the site `really` changes. This is a bit tricky as we need to ignore these small, insignificant changes that many of these sites do. btw Regarding unadvertised SSL equivalents, I have noticed if you login to gmail, you get SSL for login, but then http for web mailer. However if you edit the URL after login to https, it appears to work ok over SSL also. cool, this may also be something we can do for users (essentially requires us extending the auto-redirection features with wildcard functionality). -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Defending users of unprotected login pages with TrustBar 0.4.9.93
snip David Wagner writes: One thing that web sites could do to help is to always make https://www.foo.com work just as well as http://www.foo.com, and then browser plug-ins could simply translate http://www.foo.com - https://www.foo.com for all sensitive sites. Of course, web site operators may be reluctant to take this step on performance grounds. I think that this trades one security problem for others in the application security realm. Sites that allow for equivalent functional duality in either HTTPS or HTTP protocols often suffer from problems where the HTTPS site inadvertently references an HTTP URL instead of HTTPS when doing something sensitive. Most people won't notice the insecurity because the site still works. I prefer when applications break in insecure ways that they break loudly. Security is a delicate dance. Again, it all depends on the threat model and the relative probability and impact of each threat. -Jason - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
I would think it would be safer to block the site, or provide a warning dialog. (This is what I was expecting when I started reading the head post; I was bit surprised at the interventionism to actually go ahead and fix the site, maybe that would be a better default behavior). btw Regarding unadvertised SSL equivalents, I have noticed if you login to gmail, you get SSL for login, but then http for web mailer. However if you edit the URL after login to https, it appears to work ok over SSL also. Adam On Mon, Sep 19, 2005 at 04:20:07PM -0700, John Gilmore wrote: Perhaps the idea of automatically redirecting people to alternative pages goes a bit too far: 1. TrustBar will automatically download from our own server, periodically, a list of all of the unprotected login sites, including any alternate protected login pages we are aware of. By default, whenever a user accesses one of these unprotected pages, she will be automatically redirected to the alternate, protected login page. How convenient! So if I could hack your server, I could get all TrustBar users' accesses -- to any predefined set of pages on the Internet -- to be redirected to scam pages. A redirect to an untrustworthy page is just as easy as a redirect to a trustworthy page. The question is who you trust. BTW, TrustBar is an open-source project, so if some of you want to provide it to your customers, possibly customized (branded) etc., there is no licensing required. Also providing a handy platform for slightly modified versions, that will take their cues from a less trustworthy list of redirects. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
Dare I say that the best must not be the enemy of the good? --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Defending users of unprotected login pages with TrustBar 0.4.9.93
Amir Herzberg writes: However, quite a few of these sites invoke SSL/TLS only _after_ user has typed in her user name and pw, and clicked `submit`. This allows a MITM adversary to send a modified login page to the user, which sends the pw to the attacker (rather than encrypting it and sending to the site). See below link to a `Hall of Shame (HoS)` listing such sites. There are few things we can do about this. We can try to convince these sites to use SSL/TLS _before_ asking for userid and pw; I tried, and few fixed, but most did not. But this isn't enough. The only way for a user to be secure against such attacks is to type in a https:-style URL into the address bar directly, or to load a https:-style URL from a bookmark. Users have to always remember to type in https://www.bank.com; they must never use http://www.bank.com, or they will be insecure. Training users to follow this discipline is not a trivial task. I'm not sure it is fair to blame this solely on the web sites. The problem is that the https: model for web security is broken, if attackers are mounting active attacks, DNS spoofing, and other kinds of man-in-the-middle attacks. The problem is not with SSL; the problem is with the model for how SSL is applied to solve the web security problem, and with the user interaction model. Fixing this probably requires changes to web browsers and/or web servers. So, a Hall of Shame seems a little over the top to me, since there is no obvious way that the web site could fix this on its own. TrustBar's solution to this conundrum is a nice one. I like it. But it does require changing the web browser. One thing that web sites could do to help is to always make https://www.foo.com work just as well as http://www.foo.com, and then browser plug-ins could simply translate http://www.foo.com - https://www.foo.com for all sensitive sites. Of course, web site operators may be reluctant to take this step on performance grounds. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
Perhaps the idea of automatically redirecting people to alternative pages goes a bit too far: 1. TrustBar will automatically download from our own server, periodically, a list of all of the unprotected login sites, including any alternate protected login pages we are aware of. By default, whenever a user accesses one of these unprotected pages, she will be automatically redirected to the alternate, protected login page. How convenient! So if I could hack your server, I could get all TrustBar users' accesses -- to any predefined set of pages on the Internet -- to be redirected to scam pages. A redirect to an untrustworthy page is just as easy as a redirect to a trustworthy page. The question is who you trust. BTW, TrustBar is an open-source project, so if some of you want to provide it to your customers, possibly customized (branded) etc., there is no licensing required. Also providing a handy platform for slightly modified versions, that will take their cues from a less trustworthy list of redirects. John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
John Gilmore wrote: Perhaps the idea of automatically redirecting people to alternative pages goes a bit too far: Of course, users can turn this off for one page or for all, but that's not answering yet John's comments below - I respond following them... Also: I am not crazy about this solution either, but I think the current situation, where very large banks insist on providing unprotected login pages, is even worse. I tried convincing them, and I must say few did change, e.g. Wells Fargo I think. I'll be happy to hear of better solutions (or do you think the current state is better?). 1. TrustBar will automatically download from our own server, periodically, a list of all of the unprotected login sites, including any alternate protected login pages we are aware of. By default, whenever a user accesses one of these unprotected pages, she will be automatically redirected to the alternate, protected login page. How convenient! So if I could hack your server, I could get all TrustBar users' accesses -- to any predefined set of pages on the Internet -- to be redirected to scam pages. What if the list is signed by one or more authorities that users are willing to trust to this matter? Or just have the list in a trusted site - after all, if someone breaks Google, they can redirect much more than by attacking our server... A redirect to an untrustworthy page is just as easy as a redirect to a trustworthy page. The question is who you trust. We are not redirecting to a trustworthy site (e.g., your bank is insecure, try that one instead...). We simply redirect to an SSL protected page of the same entity (bank) if we know one. BTW, TrustBar is an open-source project, so if some of you want to provide it to your customers, possibly customized (branded) etc., there is no licensing required. Also providing a handy platform for slightly modified versions, that will take their cues from a less trustworthy list of redirects. Are you now against open source in general? After all, for this attack, Mozilla would be a much better target... In fact, since `everybody` uses Windows, any stupid program can redirect users to fake sites - and do much worse... Anyway - thanks for the feedback. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
David Wagner wrote: Amir Herzberg writes: However, quite a few of these sites invoke SSL/TLS only _after_ user has typed in her user name and pw, and clicked `submit`. This allows a MITM adversary to send a modified login page to the user, which sends the pw to the attacker (rather than encrypting it and sending to the site). See below link to a `Hall of Shame (HoS)` listing such sites. There are few things we can do about this. We can try to convince these sites to use SSL/TLS _before_ asking for userid and pw; I tried, and few fixed, but most did not. But this isn't enough. The only way for a user to be secure against such attacks is to type in a https:-style URL into the address bar directly, or to load a https:-style URL from a bookmark. Why? What's your threat model? From the follow on, it seems you are concerned that even if the site's homepage say http://chase.com would redirect to https://chase.com, like etrade for instance do, this can be redirected by a MITM attacker. Similarly, if the homepage only contains a link to the https: protected login page, like most banks do e.g. Citibank, then again a MITM may redirect this to his own page. The user may not notice this change in address. In fact, with current browser UI, we know - by common sense and experiments - that almost all users will fail to notice such attacks. But our early experimental data with TrustBar seem to show that with improved UI, most users may be able to detect such spoofing attempts. Moreover, a MITM attack may be done even if the user types https://... A MITM may reply to the SSL connection itself (e.g. via DNS spoofing). True, the browser expects a certificate for say chase.com and now will get a cert for a different site, so the user gets a warning message; however, this is the sort of messages that users often click-away without reading and definitely without understanding. Furthermore, the attacker may even get a cert for the original address from one of the less-trustworthy CAs supported by the browser, in which case there is not even a warning - with current browser UI. TrustBar provides indicators which seem to allow most or at least many naive users detect such attacks (involving a non-trustworthy CA). Users have to always remember to type in https://www.bank.com; they must never use http://www.bank.com, or they will be insecure. Training users to follow this discipline is not a trivial task. Impossible task, imho. I'm not sure it is fair to blame this solely on the web sites changes to web browsers and/or web servers. So, a Hall of Shame seems a little over the top to me, since there is no obvious way that the web site could fix this on its own. Web sites should use SSL to protect their login forms (and redirect from http if user tries to use it). This does leave the possibility of users being redirected to other sites, but at least the site has done the best it can. Indeed, very few non-US banks expose their customers in this way. TrustBar's solution to this conundrum is a nice one. I like it. But it does require changing the web browser. Thanks, and yes, I agree, this requires browser change, I don't think we can avoid this. Users can currently use our extension, and we hope that as more and more do so, browers makers will add such features. One thing that web sites could do to help is to always make https://www.foo.com work just as well as http://www.foo.com, and then browser plug-ins could simply translate http://www.foo.com - https://www.foo.com for all sensitive sites. Of course, web site operators may be reluctant to take this step on performance grounds. Correct. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Defending users of unprotected login pages with TrustBar 0.4.9.93
Most financial and other sensitive web sites use SSL/TLS to authenticate the server and protect data from eavesdropping and from modification by a Man In The Middle (MITM) adversary. However, quite a few of these sites invoke SSL/TLS only _after_ user has typed in her user name and pw, and clicked `submit`. This allows a MITM adversary to send a modified login page to the user, which sends the pw to the attacker (rather than encrypting it and sending to the site). See below link to a `Hall of Shame (HoS)` listing such sites. There are few things we can do about this. We can try to convince these sites to use SSL/TLS _before_ asking for userid and pw; I tried, and few fixed, but most did not. We can avoid using these sites, but this is a bit heavy penalty e.g. if it is your bank. We can also try to find an alternate login page which _is_ protected; in fact, we've found such alternate, protected sites for most ebanking login sites (see HoS). But this may be difficult for most (naive) users. So, we decided to add support for users of these unprotected sites in TrustBar. As of the latest version (0.4.9.93), available off my site (below), we added two such mechanisms: 1. TrustBar will automatically download from our own server, periodically, a list of all of the unprotected login sites, including any alternate protected login pages we are aware of. By default, whenever a user accesses one of these unprotected pages, she will be automatically redirected to the alternate, protected login page. 2. TrustBar allows users to assign a name or a logo to sites, protected or not (to help users identify fake sites). We now added a mechanism computes a hash of every unprotected site for which the user has assigned name/logo. TrustBar compares this hash on subsequent accesses to the same site. If the site is not modified in five subsequent accesses, TrustBar begins displaying `Same since date`; and when the site changes, TrustBar displays a warning. This can help users notice a fake version of their login page. Unfortunately, this mechanism does not work very well on most real-life login pages, since most of them contain a tiny bit of frequently-changing data such as date or `random` identifiers (mostly to identify a cookie-less client, we think). We are working on improving the mechanism so it will be tolerant to such tiny changes, without exposing the user to malicious changes. Please try it and tell us what you think of TrustBar in general and these features specifically. If you like it, please inform others, to protect them, help convince browsers to incorporate such features, and - last but not least for us - help us obtain more experimental data in our research on secure usability. Thanks! BTW, TrustBar is an open-source project, so if some of you want to provide it to your customers, possibly customized (branded) etc., there is no licensing required. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
On Mon, Sep 19, 2005 at 02:54:14PM +0200, Amir Herzberg wrote: We now added a mechanism computes a hash of every unprotected site for which the user has assigned name/logo. TrustBar compares this hash on subsequent accesses to the same site. If the site is not modified in five subsequent accesses, TrustBar begins displaying `Same since date`; and when the site changes, TrustBar displays a warning. This can help users notice a fake version of their login page. Unfortunately, this mechanism does not work very well on most real-life login pages, since most of them contain a tiny bit of frequently-changing data such as date or `random` identifiers (mostly to identify a cookie-less client, we think). We are working on improving the mechanism so it will be tolerant to such tiny changes, without exposing the user to malicious changes. You could consider hashing Just all SCRIPT.../SCRIPT content, the action URIs of all forms, and the targets of all links, ignoring superficial content changes and changes in layout (sort the hashed items). -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
