TrustBar 0.4 beta 9.3.1, with Hey! Training Mode - please help test usability
I've just placed new version of TrustBar including Hey! component for testing usability and training users, please save to disk and then open via FireFox, from: http://www.cs.biu.ac.il/~herzbea//TrustBar/Latest%20TB.xpi The Hey! component is designed to support testing for other bars so I'll be happy to cooperate in testing with other bars. It is quite easy. I will really appreciate if you test it - yourselves, of course, but also if you try to find one non-expert e-banking user and have him try it for two weeks... This is a new, exciting (I think) way to test secure usability - by real usage!! Comments welcome... Thanks and best regards, Amir Herzberg Dept. of Computer Science, Bar Ilan University http://AmirHerzberg.com ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Is there a Mozilla security process?
Space Riqui wrote: --- Heikki Toivonen [EMAIL PROTECTED] wrote: after playing around for a while I managed to go to a site I had set a petname for but the petname field showed untrusted (I've been unable to reproduce this, though) This has happened to me a few times with the following web sites: https://tryowa.arvinmeritor.com/ https://chaseonline.chase.com/chaseonline/home/sso_co_home.jsp I tried both and didn't notice this particular problem. OTOH, I noticed petname (and spoofstick) does not handle multitab FF windows correctly, which is very confusing and annoying; maybe that was the cause of your problem? BTW, these sites work fine for TrustBar (now using our 0.4 alpha version which also lets me `rename` them in the bar directly, like `petname`; but I'm quite sure they worked also in the current 0.31 release). Best, Amir Herzberg Hope it helps. Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: new anti-fraud mailing list for discussing improving browser security UI
Doug Ludy wrote: I am a newcomer who knows a little bit about group process. It has been fascinating to watch this newsgroup at work--brilliant minds and powerful egos working toward similar goals. I am reminded of a debate in the English parliament. Rather than viewing the current impasse in terms of betrayal and trickery I think a more charitable approach might be the model of culture clash. How does a group accustomed to open process communicate and negotiate with another group whose approach is proprietary and secretive? What rules apply? Which compromises are life-enhancing rather that life-threatening? This is a very old dilemma. I sincerely hope this discussion continues, for trust is important to me. Interesting comment. But: the discussion was between two groups which are both claiming to follow and believe in open process; I believe Gerv in his note clearly indicates his personal preference for more open process. Anyway, considering Mozilla are currently pursueing a different, `closed` approach, the technical discussion moved to the new list Duane made (see original post). Best, Amir Herzberg ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: new anti-fraud mailing list for discussing improving browser security UI
Gervase Markham wrote: Amir Herzberg wrote: It is not an issue of fairness, it is an issue of open process. I am indeed disappointed to find that Mozilla is not acting openly. As a believer in open process, I am concerned that the result may be suboptimal. I would like the process to be more open. I hope and expect that in the future, it will be. However, to achieve the goal, it can't be open right now. Fine. Considering Mozilla are currently pursueing a different, `closed` approach, the technical discussion moved to the new list Duane made (see original post); please join if and when interested. This is not the way to encourage innovation. In fact, this situation, which was not even disclosed openly during this lengthy discussion, As I said, some of those involved are reticent about their involvement. I don't see why this prevented you from stating all this up front, instead of wasting people's time on trying to convince you to follow an open process you (temporarily?) abandoned. And I hope the occupants of this newsgroup won't go shooting their mouths off in blogs and on Slashdot. I'm rather surprised at this comment. After all, you (claim to) believe in open process, and surely criticism of your actions is a part of that. If somebody feels this is somewhat contrary to the stated goals and principles of Mozilla and the open community in general, what's wrong about voicing this in any forum? puts Heikki's advice on `develop code` in rather strange light. Not at all. Just because we're not in a position to accept your code now doesn't mean it's not valuable. It certainly does not mean the code is not valueable. OTOH, it is important input, which I think in fairness should have been disclosed. For example, I may have decided to put more effort into non-Mozilla development; we currently do only FireFox and IE, I may have focused more on the IE version, or even begun an effort on another browser. I am definitely considering such options now; regardless of my decision and actions, the fact that this new information resulted in re-evaluation indicates this information should have been disclosed. I am not angry, I'm sure you and Heikke simply did not consider the implication of your following a closed process and the need to dislose that decision. Frankly, a simple apology would have made me feel better about it, but I don't insist, after all sometimes `sorry seems to be the hardest word` :-) I'm not planning to stop coding (yet), but I think you should have indicated that at least the Mozilla group thinks that working in a closed committee will be more effective Please don't make it so black and white - it's not. I personally don't think a closed group is any more effective, but I'm not the only person with a view on the question. Ok, and even if you did, that's an understandable position, even if I think it is wrong. Best, Amir Herzberg ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Checking URL against black list - privacy and efficiency concerns
There were several good threads we left in Mozilla.security, which I think we may want to revisit and try to resolve in the new anti-fraud list. For now, I'm cross-posting, although I suggest we continue only on anti-fraud if nobody objects, simply since it is more focused. Heikki Toivonen wrote: One thing about a class of extensions that check the URL you are visiting against known bad ones from an online source: privacy. I read about some implementation which was IMO too invasive. When a security product like this comes from a commercial company and they get access to your browsing history in real time I see it as a deal breaker. Tweaking the settings and eliminating the commercial party from the picture would make it much more likely to get accepted. Hear, hear!!! This is absolutely absolutely correct, imho. Indeed, as I already mentioned, we got a kind offer (I'm serious) to access one of these DBs with `black list` of suspect sites, but decided to decline, due to these concerns (and also performance; you feel this very well if you are not close to the server, e.g. from Israel). We are now working (Ahmad, mostly) on a better solution. In a sense, this `blacklist` is really a variant on the old CRL problem, btw. The solution we work on is roughly: -- Have a local cache for the queries. This reduces privacy invasion substantially and improves performance. -- Specifically, we simply think of doing the requests in cacheable HTTP queries - the cache will be simply in the HTTP proxy (often hidden, of course). DNS could be an alternative, btw. But HTTP is really trivial solution. -- Each query will not be for a single URL but for a collection, following the efficient CRL techniques. Again: improve efficiency and privacy together. -- A variant on this mechanism will help us get additional positive credentials for the web page such as logo, BBB/Zagat/Fodor/eTrust ratings,... None of them have been usability tested in a browsing situation. Some tests were done and more will follow, I don't think you do this for any new UI feature, do you? Making them into extensions and gathering feedback is one way of getting it. In fact this is what I recommend. Iron out the bugs and usability problems in the extension model first. We did/do. I have my own opinions about these options. Ian has his own opinions, and Gervase has his own opinions. We could argue endlessly about it, but there comes a point where arguments are based on speculation and the only way to know is to gather empirical evidence. Do you do this as part of your closed process? I doubt. I don't think there is a written set of acceptance criteria. Writing one up would be a good thing. Another doc for the security area or wiki perhaps. Anyone could write/start it, but it would need approval from the Mozilla Security Group of course. I can't see many volunteers to write a draft of the Mozilla security group's acceptance criteria - esp. not from people outside this group... In the end it will fall into convincing the right people, but before that you really need to pass the not-yet-written-down-anywhere acceptance criteria. Well, seems like an impossible mission, then. Some rules of thumb could be gathered from my feedback to the petnames extension, like should not require too much (ideally anything) from users, should use minimal chrome real estate and so on. I'd also like to add: make it first into an extension, iron out the bugs, gather usability etc. feedback I think we do all that fairly well. I am grateful that you posted the link to the list of people on the Mozilla Security Group. It's helpful to know those names. It's just that there are over 60 people on that list, so I'd like to know a little more about how consensus is reached on design decisions. ... You can narrow down the list, though, by checking the affiliations of the people on the list, and if you can't figure who to contact you could always start with the owner. Well, sounds like fun, they are probably all very interesting persons and digging up their e-mails should be lots of fun, writing each of them - a very efficient, constructive use of my time. I've put it in the appropriate priority of my `to-do` list. Coding to other platforms is a bit higher, though. Best, Amir Herzberg ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
new list for open discussion of anti-phishing
Gervase Markham wrote: Ian Grigg wrote: This is clearly not the case - in partnership with the other browser vendors, we are together working out the most appropriate UI and then all implementing it. That's fine, but of course not currently an open process. Duane kindly setup an open forum, the [EMAIL PROTECTED] mailing list. This is for anybody interested in further discussing these issues; thanks! I am sure that some of the people in the `closed` group will also join/follow the open forum, and certainly hope that Gerv will. In particular, this list is an appropriate forum for feedback on our proposal (TrustBar) and other proposals, for developing agreed-upon criteria, etc For info or to join: http://lists.cacert.org/cgi-bin/mailman/listinfo/anti-fraud You (mozilla, you, everyone within) are not playing fair. It is not an issue of fairness, it is an issue of open process. I am indeed disappointed to find that Mozilla is not acting openly. As a believer in open process, I am concerned that the result may be suboptimal. This is not the way to encourage innovation. In fact, this situation, which was not even disclosed openly during this lengthy discussion, puts Heikki's advice on `develop code` in rather strange light. I'm not planning to stop coding (yet), but I think you should have indicated that at least the Mozilla group thinks that working in a closed committee will be more effective (and is unlikely to evaluate the code - as seems the case). Best, Amir Herzberg See the new TrustBar homepage at http://AmirHerzberg.com/TrustBar ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
new anti-fraud mailing list for discussing improving browser security UI
Gervase Markham wrote: Ian Grigg wrote: This is clearly not the case - in partnership with the other browser vendors, we are together working out the most appropriate UI and then all implementing it. That's fine, but of course not currently an open process. Duane kindly setup an open forum, the [EMAIL PROTECTED] mailing list. This is for anybody interested in further discussing these issues; thanks! I am sure that some of the people in the `closed` group will also join/follow the open forum, and certainly hope that Gerv will. In particular, this list is an appropriate forum for feedback on our proposal (TrustBar) and other proposals, for developing agreed-upon criteria, etc For info or to join: http://lists.cacert.org/cgi-bin/mailman/listinfo/anti-fraud You (mozilla, you, everyone within) are not playing fair. It is not an issue of fairness, it is an issue of open process. I am indeed disappointed to find that Mozilla is not acting openly. As a believer in open process, I am concerned that the result may be suboptimal. This is not the way to encourage innovation. Best, Amir Herzberg See the new TrustBar homepage at http://AmirHerzberg.com/TrustBar ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Is there a Mozilla security process?
Space Riqui wrote: --- Heikki Toivonen [EMAIL PROTECTED] wrote: after playing around for a while I managed to go to a site I had set a petname for but the petname field showed untrusted (I've been unable to reproduce this, though) This has happened to me a few times with the following web sites: https://tryowa.arvinmeritor.com/ https://chaseonline.chase.com/chaseonline/home/sso_co_home.jsp I tried both and didn't notice this particular problem. OTOH, I noticed petname (and spoofstick) does not handle multitab FF windows correctly, which is very confusing and annoying; maybe that was the cause of your problem? BTW, these sites work fine for TrustBar (now using our 0.4 alpha version which also lets me `rename` them in the bar directly, like `petname`; but I'm quite sure they worked also in the current 0.31 release). Best, Amir Herzberg Hope it helps. Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Criteria for an antiphishing tool
Ian Grigg responded to Gerv: Amir Herzberg wrote: So, Mozilla plays `follow the leader`? Nice to know. Not exactly the original goal of the project, was it? Up to this point, our discussions have been reasonably civil, but now you are just throwing clearly ridiculous assertions around. Sorry, I didn't mean to offend. Having a common and consistent security UI across browsers, no matter who comes up with it, is not inconsistent with the goals of the project. Of course. But, does it imply that Mozilla/FF will refrain from enhancing its security UI, until IE does ? Or until coordinating with IE (which may or may not happen... and via which process?)? Best, Amir Herzberg ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Criteria for an antiphishing tool
Gervase Markham wrote: To be safe, the user must verify that SSL is enabled and that the displayed domain name exactly matches the expected domain name (which implies that the user has also discovered and memorized the correct domain name). I don't think that's particularly unreasonable. What's the domain name of your bank? PayPal? Ebay? Really! What about my citybank incident? Or... just go to Citybank.com (no typo this time) and see what is the domain they use for home banking... And they are not unique, there are many such FIs using various, unrecognizable domain name, including CitiBank, and some that use domain belonging to other corporations, including e.g. BoA. Any site with which the user has a relationship involving money will have been visited by them several times, and they will know what the indicator is supposed to look like. Seriously, you expect users to even look at URL? Notice a difference? I'm not arguing the current UI is perfect, but I think you are dismissing it too readily. Gerv, really, this is common sense, and I present some usability data proving this in my paper. Users don't dig URLs! This is a straw man. We are not blaming the customer. Having said that, it's hard to protect a user who is happy to type their CC number into any form which asks for it. Funny... the CC# is in fact one of the least sensitive items for a consumer, we give it to every cafe, why not to every website? There, at least, the law protects the consumer. Banks don't think this is the case with e-banking. Although, at least for banks which do not use SSL to authenticate the login page, I think there is a possible claim of negligence / failure to maintain duty of care. But this need to be evaluated legally, of course, I can't be sure yet (trying to get this resolved). Best, Amir Herzberg ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Criteria for an antiphishing tool
Ian G wrote: As far as I know it was Netscape that invented SSL. They picked a scheme that was provably secure (from math point of view), which was good. Yes, it was Netscape. The first version was not so good, so I hear, and SSL v2 was pretty good and that stuck well enough to last until now. I have no idea what it means to be provably secure, maths wise, that's an idea that people played around with in the 90s, but these days it's fallen out of favour I hear, partly for reasons of security failures that we see here and now. Hey, wait, that's absolutely wrong!! Crypto is still much based on provable security, and most of my work, in particular, is in this area. If you have no idea, don't make statements, or better yet learn - provable security takes time and effort and is not applicable always, but it is a great tool and also trains the mind. It's hard to really state this without getting into a big long net argument, but here goes: we know a lot more about secure protocols than we did then. We also know a lot more about threats. If we sat down and re-did the whole lot, it wouldn't look anything like what you see now. Huh? I think TLS is a pretty solid protocol, and while there are some aspects that could be improved (like auth-then-encrypt choice), they are relatively minor. I teach it both as an improtant protocol as well as a good one. True, no complete proof yet, but just give us some time. And comparing SSH and SSL is not totally fair - usage differs. It is Anyway new SSH is simply using SSL/TLS so this seems irrelevant. (We need to be careful not to let the strength of the SSL protocol blind us from the weakness(es) of the secure browsing system in the browser. I.e., SSL may be provably secure, math wise, but secure browsing is provable insecure, money wise.) Now you make sense. ... but the minimum necessary. What browser manufacturers did was the logical thing - they reduced the security component on the chrome over time until it had all but disappeared. No threat, so no point in it being there. Are you inventing history here? I don't remember what the early browser's looked like, but was there really more security in the early days? Originally the lock was more prominent Correct, in particular, it was not omitted in unprotected page as it is these days. OTOH, recent changes in FF did improve visibility. and the CA was supposed to be named as the one who you could rely upon. I don't recall it myself, but Bob Relyea mentioned it. Yes, but I think that was only in the pre-release. Best, Amir Herzberg ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Installing Trust Bar
Doug Ludy wrote: I am new at this, but have been following the discussion of phishing at the n.p.m.security newsgroup for the past month. I would like to try the trustbar extension but when I try to download the program from http://trustbar.mozdev.org I cannot do so because I have JavaScript blocked. Should I unblock JavaScript in FF or have I reached a spoofed site? I think you can install w/o Javascript from: https://addons.mozilla.org/extensions/moreinfo.php?id=478 And I also began making a `TrustBar homepage` (with forthcoming IE version, can't only use Mozilla's sites!), at: http://AmirHerzberg.com/TrustBar.html. Best, Amir ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Criteria for an antiphishing tool
Gervase Markham wrote: Heikki Toivonen wrote: So that is why the status bar and title bar are the only places where security indicators can go and be available even if the site tries to muck with things. There is also the not-insignificant factor that IE has chosen the status bar as their compulsory UI, and keeping security UI and window-size compatibility with them is very useful. Gerv Funny... You may discover IE 7.0 changes that. They look at improved secuirty indicators very seriously, and give us much more positive responses than we ever got from the Mozilla security group (well, that was zero, so it is easy to beat). In fact I'm not sure our decision to implement TrustBar on FF was justified. Indeed, our next release of TrustBar will also be for IE (very soon). So, Mozilla plays `follow the leader`? Nice to know. Not exactly the original goal of the project, was it? BTW: the issue of placing the improved security indicator, on the top or bottom, status bar, as a regular toolbar, or title bar, is really secondary question in the design, and in fact I would argue that it is best to have it as a user-controlled toolbar so user can place it whereever she likes. Best, Amir Herzberg ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Cooperating and communicating on antiphising / improved security indicators
There has been an interesting and important debate on this list on the `Mozilla security process`. The discussion focused on improved security indicators, specifically to help protect against spoofed web site attacks (including phishing, pharming, etc.). This is also one of my main research interests. In particular, with Ahmad Gbara and now few other (great!) students, we develop TrustBar (http://TrustBar.MozDev.org), a browser extension (for FF and Mozilla, soon also for IE). There are, of course, many different ideas in this space; Ka-Ping listed five of them, including TrustBar (thanks!). I think many of the proposals have a lot in common in their goals and even functionality. In particular, as Ian noted, I believe we learned a lot from Tyler's and other works on petnames, e.g. http://www.skyhunter.com/marcs/petnames/IntroPetNames.html, and of course other proposals such as Gerv's. Indeed, we adopted a lot of this into our new release (in testing / finish process now), and I think it meets very well the requirements Ka-Ping listed (and others). In particular, it gives substantial value even for naive users, without requiring action or understanding (we have some usabilty data on this). I am a great believer in cooperation and open process. Our goal should be to try to reach `rough agreement` on what is the right security indicator, and not to get our code used... We should do more open comparisons, criticism, and try to reach agreements on goals and specific solutions. Is there sufficient interest to create an (informal/Mozilla/...) forum/mailinglist to pursue this? Any volunteer to take care of it? Best, Amir Herzberg ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Criteria for an antiphishing tool
I think all five criteria below are correct. I also believe we will meet all of them in our next release (in testing) of TrustBar, and meet almost all even in our current release (which has many downloads, happy users). Here are details: Heikki Toivonen wrote: Ka-Ping Yee wrote: 1. We want an antiphishing tool that does not transmit a record of the user's browsing activity. Absolutely. And yes, several commercial tools do, at large cost to privacy and even performance hit. 2. We want an antiphishing tool that occupies modest or minimal screen space. Agreed, and also admit that this is not so true for TrustBar 0.3.1. Fixed in version 0.4. 3. We want an antiphishing tool that is deployable without requiring major changes to server security infrastructure. Any short term solution will have a requirement that says: no server changes required. Long term everything is possible, but the less changes the better, of course. Agreed and of course TrustBar requires no such change in server. I think a fourth point is required as well: 4. No (or minimal) input from user. Agreed; and in fact, I believe `provide useful function even with no input` is actually a good goal, and we meet (even) that. Current SSL system generally requires no input from user (exceptions are when some problem with the certificate the server presents). petname is an example where input is required for every SSL-enabled site the user visits more than once. Not with TrustBar, which displays the name from the certificate (and the logo of the CA) by default. We do allow user to change the name/logo for the site (i.e. use `petname` model) but this is optional. And perhaps another point should be explicitly mentioned: 5. Easy to use. You could elaborate 5th a lot: trivially easy to use, idiot-proof, fail safely, ... Our usability experiments show TrustBar meets this as well. Best, Amir Herzberg ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: new citibank site uses wrong URL, certificate ?
Oops, sorry, my mistake, I typed citybank.com instead of citibank.com... Amir p.s. Citybank is a community bank (and yes, _they_ use unprotected login... but CitiBank is Ok). Amir Herzberg wrote: Hi, I noted that Citibank changed their login form at http://CitiBank.com. It now points you at the site: https://cib.ibanking-services.com/cib/login.jsp?FIORG=775FIFID=125106986id=1449852460 Ignore the parameters... notice the domain, ibanking-services.com! And whois reveals it belongs to Metavante Corporation... The SSL certificate also belongs to Metavante (and signed by RSA). Well, this site is protected by SSL, but not with the correct ownership (citibank/citigroup)... I guess I should add it to the Hall of Shame... Granted, most web users, using current UI, will not notice this at all, but I think it is clear that the bank should allow careful users (e.g. using TrustBar or checking manually) to identify that the site belongs to citibank. BTW, citicards.com still works Ok, as well as http://www.citibank.com/us/index.htm... Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Unprotected Login Hall Of Shame: http://AmirHerzberg.com/shame.html ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: do extensions compromise the security of mozilla/firefox?
Mike Henley wrote: Hi. I'm using mozilla and mozilla firefox. I often install extensions though only through the usual websites (mozilla.org, mozdev, texturizer). Today though I tried to install an extension from http://jgillick.nettripper.com/ and as such found myself wondering if extensions comprmise the security of mozilla or firefox. I use firefox to access sites such as paypal and my bank. In this case, you may want to try also our TrustBar extension (http://TrustBar.mozdev.org) to provide you with secure logo for these sites for easy and secure identification of spoofed sites... As such I would like to ask the following questions... 1 - can someone make an extension that would allow it (while performing its advertised function) to send my username/password either from those stored in mozilla/firefox or as i enter them? Yes. 2 - can such an application make it to the trusted sites? (mozilla, mozdev, texturizer)? Yes, it can. Our TrustBar is in mozdev, and while it is of course not doing anything like that (on the contrary, it improves your security), there is nothing preventing us from uploading a malicious version. or is there a review process before such extension is allowed to be distributed? Well, there was a short process to get us on mozdev; I'm not sure if they checked our personal credentials (don't think they did) and they definitely didn't go over the code. thanks ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: [Fwd: more comments on the protecting naive browsers paper]
Ian Grigg wrote: Amir, here are comments, not particularly well reviewed. http://www.cs.biu.ac.il/~herzbea//Papers/ecommerce/spoofing.htm Thanks! Mozilla people (2nd try), Please provide more comments... Here are some responses to your comments: Right, that idea. A couple of things - it's called a petname which has a defined meaning, you can probably google for the defining paper. It is a name that is explicitly not shared with the rest of the world, so it is distinct by definition with the nickname, which is shared. I didn't find the definition and didn't quite understand the distinction you made. SSL/TLS isn't used to confirm the public key. I think we use different terms here. When I say `confirm the public key` I simply mean `confirm that the site actually has the private key corresponding to this public key. Nothing to do with certificates, CA etc usually done using SSL. ... Existing web security mechanisms (SSL/TLS) may cause substantial overhead if applied to most web pages, as required for securing credentials (e.g. logo) of each page. ... ... Unfortunately, most web pages are not protected by SSL. This includes most corporate and government web pages, and other sensitive web pages. The reason is mainly performance; the SSL protocol, while fairly optimized, still consumes substantial resources at both server Amir! This has to be the worst reason to present! It's 2004, most everybody has cycles sitting there doing nothing on their web servers, even your PDA could do SSL without you noticing ... There is still valid concern about the cost of SSL esp at the server (check your own numbers... and remember that 512 bits is definitely insecure and even 1024 bits is considered insecure). All I'm saying is this is not a show stopper. If you think we don't need a lighter version, so much the better. But some may disagree (for them I'll show the light version). [Not] Protecting pages with SSL is 99% due to the cost of the certificate process. No manager in his right mind wants to futz around with that process, simply because its costly, ... I agree browsers should accept self-signed certificates etc... will clarify this further. But I'm not sure this could explain the situation where we have sites which are mostly unprotected with some protected parts. ... Customization: the visual representation of the different credentials should be customizable by the user. Such customization may So we now have a class of ideas where the USER tells the BROWSER something about the certificate in question. And then, this: In addition, our extension generates, upon installation, a private signature key, which it uses later on to sign logo certificates, linking public keys and logos, if the user (manually) specifies the use of the logo for the public key. So we now have a local signing key generated on install to record those decisions of all user trust metrics. Perfect. Right! Finally, popular browsers are pre-configured with a list of many certification authorities, and the liabilities of certificate authorities are not well defined; Yup! Not only are all CAs different, about the only thing they concur on is that they all want to escape liability. Quite. This is where I'm getting confused. The site has a logo. That much we are happy with as a consequence of (other) branding. Now, the logo can be signed. Sure. We could call that a logo certificate. Is that what is meant? A logo certificate is a signature over the (hash of the) logo and over the public key, binding them, and saying: the owner of the private key corresponding to this public key is also the owner of the trademark logo.. IMHO, this is better defined than identity certificates... Then, the question is, who signs the logo and thus creates the logo cert? The answer: somebody who can make the assertion (and have users trust it...). It would seem obvious at one level that the site cert should do so. That way they can do a dozen or more, and have control over the site layout, etc. Kind of critical, really, for efficiency. This doesn't make any sense to me. Have the site sign its own logo?? What's to prevent it from signing somebody's else logo? But, if a spoofer does acquire a cert validly signed by a CA, then it can also create its own logo set, just by copying the graphics. Bingo; which is why we definitely don't let the site sign the logo! I mean, Ok, the site can _suggest_ a logo, but this will require the user to manually approve it. Hence the notion of a Logo Certificate Authority, I guess. An LCA signs a logo and then acts as a kind of extended-trademark-authority. (E.g., it could be Verisign signing the cococola logo, or it could be the USPTO signing the Bob's bookstore logo.) Exactly. Or maybe USPTO will sign one format of the logo (or few), and VeriSign and company will sign other formats. The question then is - which? Is it one, or the other or both? Logos must be approved by a trusted
Re: Security Hole Found in PayPal Registration !
Xeon wrote: Recently thier is a security Hole detected in PayPal Registration server, Secure your hardly earned Money check out: www.onlinehacks.netfirms.com Thanks care lover This is a sting. It claims to `hack paypal`, hoping some will try... in the process, the victim (you!) should e-mail your paypal account and password to an unknown account - probably of the hacker... I wonder if they'll get any `fish`... Most phishing attacks try to impersonate as a trustworthy site... But these guys apply the more classical sting operation, and like they say `Youre responsible for your action!` Best, Amir Herzberg Interested in phishing / spoofing / spamming and their prevention? See `Current research` in my homepage http://AmirHerzberg.com ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: Protecting (even) Naïve Web Users from Spoofing and Phishing
Tyler Close wrote: I've written a paper that argues that global namespaces, such as those used in the current PKI and in Amir's proposal, are actually a cause of Tyler, we allow the user to select a logo or icon, so this is a local identifier, just like your petnames... Indeed, the site could also suggest the logo or present a logo certified by some authority, but this is only for convenience and a user that does not trust a particular (or any) authority can ignore these. Therefore, after reading your paper, it appears to me to be a subset of our proposals. Of course, you may object to our other proposals e.g. the use of logos as a better (imho) identification mechanism. phishing attacks, not a solution to them. The paper further argues that the phishing problem is best solved without creating any central authorities like today's CAs or proposed LCAs. The safest solution involves a local namespace maintained within the user's WWW browser. That's what we currently use as well (except with graphical logos rather than names). But we think users will want to select one or more authorities to automate this process - and we should enable that as well. The paper is available at: http://www.waterken.com/dev/YURL/Name/ Please compare to ours at http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing.htm There is a proof-of-concept implementation at: http://www.waterken.com/dev/Browser/ We are still experimenting with our implementation, which is a simple modular extension to Mozilla (in Javascript, etc.). It works great for our personal use and we will put it in the site later this month or next month. We want to be reasonably confident it works smoothly (we expect most people will want to use it regularly once they tried). I'd very much like to incorporate these mechanisms into the Firefox browser. I'd appreciate feedback on the concepts as well as implementation advice or assistance. We appreciate your (and others) feedback. So far, we manage the implementation Ok. Best, Amir Herzberg ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: Protecting (even) Naïve Web Users from Spoofing and Phishing
Frank Hecker wrote: Amir Herzberg wrote: We have created a Mozilla extension that creates a secure, Trusted Logo and Credentials Area, which displays logos and other credentials The proposal is described at: Protecting (even) Naïve Web Users, or: Preventing Spoofing and Establishing Credentials of Web Sites, by Amir Herzberg and Ahmad Gbara PDF at http://eprint.iacr.org/2004/155/ HTML via http://AmirHerzberg.com, or directly from http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing.htm ... at least some brief comments. I'm cross-posting my response to n.p.m.security because I think this is really a general Mozilla security issue (i.e., how to protect against phishing attacks) rather than just a crypto issue. Ok, I'll do the same, but cross posting is not desirable; I suggest the list owner/moderator will decide and let us know which is the appropriate list, posting a message on the other list so that people can follow the discussion if they wish. First, thank you all for doing this work. This is a very nice example of Thanks you! ... However I do have a comment about the particular strategy you've chosen. It seems that with things like the proposed Logo Certification Authority (or whatever you called it) that you are in some respects proposing creation of a parallel structure to today's regular CAs, probably with many of the same issues. (For example, we'd now have to worry about including LCA certs in browsers, evaluating LCAs prior to such inclusion, having users potentially accept new logos and LCA certs through some sort of security dialog, and so on.) Also, introducing a brand-new SSL-like protocol further increases the complexity of your proposal. I don't quite agree. First, our proposed `SSL-light` is completely optional, only designed to solve an efficiency problem we may have if we try to extend SSL protection to many more pages - so, we could always use existing SSL or not protect cryptographically at all some pages (as we do today). Second, I definitely expect some of the existing CAs to begin to certify logos i.e. become LCA (Logo certifying authority). Third, we believe it is preferable that the trust in a particular LCA is a user decision rather than a browser decision. It is very problematic for browser vendors to make a trust decision for their users, and this is particularly obvious for browsers developed in an open process by non-profit organizations like Mozilla (I believe it is non-profit...). So: no need for Mozilla or other browser vendors to include LCAs in the browser. In fact, the `bootstrap` process can be initiated using the existing CA certificates, since when we ask the user to approve a logo (for a LCA or for a site), it is quite reasonable to use the name (from a regular certificate) and not critical to use a logo (from a logo certificate), this being a rare, unusual event. The principle here is: you must get users attention by a strong interrupting clue (different graphics, sound) to cause them to notice a different (i.e. spoofing) environment; it is Ok to use textual information when the user is focused on your (unusual) message. Please allow me to play devil's advocate and propose an alternative approach: Rather than relying on the site itself or on third parties like LCAs to provide site branding information, why not just build this branding into the browser, and rely on the browser vendor (e.g., the Mozilla Foundation) to maintain the collection of logos? For example, one could imagine a FireFox extension that works roughly as follows: 1. Determine the site the user is surfing to. For the non-SSL case take this directly from the URL; for the SSL case cross-check this against the information in the server certificate. In the non-SSL case, this is insecure (against many adversaries; granted, it is Ok for the relatively weak `spoofing` adversaries). In the SSL case, this builds on the very problematic existing practice of certificate authorities as used in browsers (see Ian's notes...). 2. Map the site URL to a logo for the site. For some reasonable set of web sites commonly subject to phishing attacks (e.g., Ebay, PayPal, major banks, etc.) distribute the logos with the browser binaries, as a sort of pre-loaded cache. This would work, sort of, but creates a nightmare management - and security - problem, with substantial costs involved (liability!) - who will pay Mozilla for this? Or are you proposing that Mozilla (and other browsers) will charge sites for this? The Logo CA solution is much more efficient and simpler in the business sense, by using (fairly basic) crypto. For web sites whose logos are not in the cache, do a background lookup from a site maintained by the browser vendor, e.g., using a URL like: http://logos.mozilla.org/get-logo?site=example.com Of course this is insecure... you event didn't specify the use of SSL (https://...) - and also it involves the same expenses as the previous solution
protecting (even naive) web users against spoofing and phishing
We have created a Mozilla extension that creates a secure, Trusted Logo and Credentials Area, which displays logos and other credentials of the site. We believe this helps protect web users, even naive users, against spoofing and phishing attacks. We are still playing with the code but hope to begin providing it to others soon; in the meanwhile, if you are interested, we'll love to hear your comments. The proposal is described at: Protecting (even) Naïve Web Users, or: Preventing Spoofing and Establishing Credentials of Web Sites, by Amir Herzberg and Ahmad Gbara PDF at http://eprint.iacr.org/2004/155/ HTML via http://AmirHerzberg.com, or directly from http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing.htm -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
