Re: certificate handling feature idea
One good reason to permanently reject a certificate is from a code signing perspective. Consider a publisher whose policies you don't agree with but is otherwise a legimiate company. By permanently rejecting their certificates you won't accidentally install their software (as a side note, MS didn't enable this UC for years but finally added it to the 'install signed code' UI). ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Unable to set Google preferences in FF with zone alarm firewall on
I'm using zone alarm security suite 5.5. My default browser is FF 1.01, which I use 99% of the time. In both FF and IE, I am unable to save (or at least access) Google preferences, unless I turn Zone Alarm OFF ENTIRELY. This despite the fact that both browsers are set to "allow sites to set cookies" and despite Google.com being set in Zone Alarm to allow mobile control, session, persistent & 3rd party cookies, as well as web bugs & personal headers (all variables). AND despite the fact that a Google.com cookie titled "pref" exists in FF's cookie file. If I go into Google preferences after seeing the site is ignoring my "100 results" rule, it says "your cookies seem to be disabled". Probably more of a Zone Alarm question, never had this with Norton, but I'm wondering if anyone here has any ideas. It's really getting to be a pita. TIA Dan ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Some Non-Critical Secunia Advisories
Allen Farley wrote: Nate wrote: On Tue, 15 Mar 2005 10:51:26 -0500, Allen Farley <[EMAIL PROTECTED]> wrote: From the article: The weakness has been confirmed in version 1.0.1. Other versions may also be affected. I also tested the sample code with FF 1.0.1, and they are right. It's not unusual for me to save a zip (because I want to keep a copy), and then right-away click "Open" when it's finished downloading. Now I know that could be a recipe for disaster, if I were not to notice the change in filename. So thanks for posting the alert. I suppose it's too-good-to-be-true that there is an email alert service for these exploits? One that covers only FF, not every thing under the sun? ...and it occurs to me yet once again, that one big reason for the proliferation of spam, spyware, viruses and on and on ad nauseum is that the bad guys hardly ever suffer any punishment. It's like burglars being allowed to try as many doors as they want to. In the too-good-to-be-true category, would a webpage do as a stop-gap measure? http://secunia.com/product/4227/ There may be other possibilities there as well. On punishing the bad guys, my suggestions would most likely be considered inhumane for these creatures. Just figured out, with some help from TB help and FAQ, another alternative in the Too-good-to-be-true category here. Secunia Advisories come also in RSS, others may also have this as well. You can setup a Saved Search Folder on an RSS. Yes it seems to work when I set one up to test on TB 1.0.2 I set it up to look for Thunderbird, Firefox or Mozilla in both the subject and body. You still have the Secunia Advisory RSS folder for the subscription, but at lease you have an easy way to access only the articles you are wanting. If you don't like that, you could still use the Secunia Advisory RSS, or which ever you prefer, with a filter! It's kind of interesting all of the possible solutions you have to choose from. Allen ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Password field check characters?
I read the blog and comments briefly. Maybe I missed something or maybe there is a solution that's not clicking for me but here's the problem I see. Let's say real-password = hash (domain-name + user-entered-password). Phisherman sets up a site and does not mark the password field as form element type password. He does however put a question mark (or whatever 'in page' feedback) as well as some javascript to asterisk out the not-really password field. The user will enter their password and the un-hashed password will be caught in the net. Since the algorithm and taget domain-name are know the bad-guy has all he needs. A solution to this is to make real-password = hash (domain-name + user-entered-password + salt). This way even given the password the bad-guy can't access the site with out brute force. The problem is that each browser instance must have it's own hard to guess salt and so site passwords are no longer portable with the user. A solution to that is to derive the salt from the master password; that works if I use the same master password at home as at work, though it still kills my ability to use my password at a kiosk where if they have mozilla they may not have a master password set, won't let me set a master password, or have a master password and won't tell me so that I can't change it. What did I miss? ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: How Can Mozilla Use Microsoft Certificate Store
Doh! I was wrong. I have used a non-Microsoft PKCS#11 shim CSP to access HSMs through CAPI. According to Microsoft: http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.asp?url=/Resources/Documentation/windowsserv/2003/all/techref/en-us/w2k3tr_cacrt_what.asp Excerpt: Because the Windows 2000 and Windows Server 2003 operating systems require hardware devices to support Plug and Play and power management features, and PC/SC includes support for these ease-of-use features, Windows Server 2003 does not support PKCS #11. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Password field check characters?
Ian G wrote: > Yes to both. By "solving password loss" I mean > reducing the incidence of lost passwords, both for > the user and the support department. The average > support department is facing costs in the order of > $20 per incident (+/-) and any lost password is > (at today's price, USD $14 buys 1gg). Even with CAcert the amount of people requesting lost passwords has gotten to the point that manual password recoveries are getting to be a major issue (labour wise) and we've started charging US$15 per incident... On the other hand we've also include ways to file disputes in an automated fashion, not to mention the existing lost password recovery system... Yet people still manage to screw up after all that... -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Password field check characters?
Gervase Markham wrote: Ian G wrote: Solving password loss is a big issue, support departments put this as one of their biggest problems. So addressing it at the browser is probably worthwhile. I'm not quite sure what you mean by "solving password loss". Are you suggesting this feature will help people to remember their password? Or are you talking about avoiding three-strikes lockout? Yes to both. By "solving password loss" I mean reducing the incidence of lost passwords, both for the user and the support department. The average support department is facing costs in the order of $20 per incident (+/-) and any lost password is way more expensive if dealt with manually. In the gold world, a lost password will cost you 1gg on one system, and 5gg on another system. One is undercharging and the other is charging at their programmer rate... (at today's price, USD $14 buys 1gg). From that pov, I'd suggest putting a radio button next to the password form field that turned on clear instead of stars. Much as I'd like to do this, I think it would scare people. Yes, that's a big problem in trying to improve security. In general, one way to do this is to package it with some other benefit to that people get used to the new system, and by the time they've done that, they've worked out for themselves why it is more secure and how to use it. In general, in a lot of security work, you've just got to do it and expect to take some bullets. In security, amateurs talk about bit strengths and professionals talk about body armour. Other options I've seen suggested are putting the last three characters typed into the box in a light grey, to allow easy noticing and correction of typos while making shoulder-surfing still hard. So many ideas, so many experiments to run :) iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Password field check characters?
Ram A M wrote: An interesting suggestion. I think Ian's suggestion of using something that is easier remembered than a number or letter is good. The UI issue is partially addressed by having a 'what's this' pop-up above it the first few times a user-profile submits a form. I like the password-hash concept [Blake and others] implemented within the browser (see a password field and at form-post time hash in the user [or autofill] entered password with teh site base-domain) as an anti-phishing measure though the problem is that it locks a user into a specific browser and probably specific installation of the browser as well. Indeed; this problem can be avoided by not doing it at form-submission time, but instead making the user perform a specific action to fill in the field with the password. If this is based on a master password, and all copies of Firefox use the same algorithm, it's portable to any installation of Firefox without reconfiguration. I've blogged about this; search my blog for "PwdHash". Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Password field check characters?
Ian G wrote: Solving password loss is a big issue, support departments put this as one of their biggest problems. So addressing it at the browser is probably worthwhile. I'm not quite sure what you mean by "solving password loss". Are you suggesting this feature will help people to remember their password? Or are you talking about avoiding three-strikes lockout? From that pov, I'd suggest putting a radio button next to the password form field that turned on clear instead of stars. Much as I'd like to do this, I think it would scare people. Other options I've seen suggested are putting the last three characters typed into the box in a light grey, to allow easy noticing and correction of typos while making shoulder-surfing still hard. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Ian G wrote: It's an americanism as far as I know. You sometimes see it in the Caribbean, but that would be a sign that they were trying to appeal to americans, which is actually a red flag (probably a scam). I was making the general point - company names are not unique, and CAs don't attempt to enforce uniqueness. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: How Can Mozilla Use Microsoft Certificate Store
Ram A M wrote: Microsoft supports the PKCS#11 interface to crypto-services, They DO? This comes as big news to me! a PKCS#11 interface to PSM (Mozilla crypto subsystem) is probably available somewhere. /Nelson ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
