Firefox, the free open-source Web browser from Mozilla Corp., quietly gained enough users in March to finally grab 10% of the Web browser market, according to a report released yesterday by Web audience-measurement firm NetApplications.com.
Funny, I thought that happened long ago.... On the even better news front, Frank Hecker is now posting weekly diaries of action at the Mozilla Foundation. This is an excellent idea, as they are stuck between a rock and a hard place - a non-profit with lots of money and no obvious way to govern it. Here's a snippet of some relevance to FC but the real news is that Mozilla do seem to be taking the search for governance seriously. A snippet:
PKI R&D Workshop. I attended the PKI R&D Workshop at NIST in Gaithersburg MD, and participated on a panel discussion on browser security. Note also that Bob Relyea of Red Hat spoke about work by Red Hat and Sun to support elliptic curve cryptography in the NSS crypto library and hence in Firefox and other Mozilla-based products, as well as in server products from Red Hat and Sun. For more information see Bob's presentation; the rest of the workshop presentations and papers are also available online.
Presumably Red Hat and Sun are interested in supporting the NIST Suite B because of potential USG sales. It will be interesting to watch how this falls out - will the endorsement of NIST (and in the background, the NSA) push elliptic curve cryptography forward to adoption? Or will the patent free (and therefore cheap) alternatives we already have maintain their open dominance?
A great post by Cubicle on fraud over at eBay. He talks about how the company has drifted and postured to the point where they are now providing infrastructural support for scammers - because it is the scammers that pay their fees.
The mere existence of “Second Chance” is interesting because it indicates to me that ebay has significant enough outtrade and settlement risk issues that they’re losing a significant number of sellers, so they’ve created Second Chance as a mechanism to help sellers better mitigate settlement risk. Unfortunately, they’ve tilted the balance in favor of unscrupulous sellers in the process.Look at the risks of Shill Bidding from the seller’s perspective. If they get too greedy, they will exceed the limit of their bidders and wind up “winning” their own auction. This costs them whatever the listing fee on the item was and they still have to re-list (and re-pay the fee), doubling their transaction cost and hope that they don’t overbid the auction again.
Now, thanks to Second Chance, ebay has effectively provided a safeguard which mitigates the risk to a greedy seller of exceeding the buyer’s maximum price. The dishonest seller can now safely discover the real winning bidder’s limit without having to double their transaction fee to obtain the information.
Cubicle has it right. Either you take on fraud by the horns, or it takes you on in very nasty ways. eBay and PayPal chose the latter course, and will always provide a high-cost, low reliability experience for the users. Luckily they got there in an environment when the competition wouldn't stay the course, but things have changed in the payments business lately. Signs are that they recognise the party's over, and Paypal are madly diversifying their base into credit cards and cell/mobile payments.
Viega and Messier talk in ACMQueue about how using SSL to get security is likely to be a bit of a fantasy:
Security Is Harder Than You Think, by John Viega and Matt MessierMany developers see buffer overflows as the biggest security threat to software and believe that there is a simple two-step process to secure software: switch from C or C++ to Java, then start using SSL (Secure Sockets Layer) to protect data communications. It turns out that this naïve tactic isn't sufficient. In this article, we explore why software security is harder than people expect, focusing on the example of SSL.
I'd agree - saying that you use TLS for your security model has generally correlated with a lightweight approach. Likewise, Bruce Schneier writes in Interactions of the ACM that two factor tokens are "too little, too late."
Man-in-the-Middle Attack. [phishing ... snipped]Trojan Attack. An attacker gets the Trojan installed on a user's computer. When the user logs into his bank's Web site, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.
See how two-factor authentication doesn't solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.
Although people are now happy to point out that the SSL, certificate infrastructure, and the browser security model out there is like swiss cheese, there still seems to be a sense that if the developers and the implementers just read the right books and just did the job fully, then we would have security ... I think the major point here is that ACMQueue and Interactions are happy to print articles pointing out the flaws which is probably a necessary step if we are to move forward.
Posted by iang at April 22, 2006 10:26 AM | TrackBackso session authentication is vulnerable to trojans ... somewhat akin to man-in-the-middle attacks ... where the authentication porition is distinct from the operations to be performed.
the eu finread terminal
http://www.garlic.com/~lynn/subpubkey.html#finread
is somewhat countermeasure to that. each individual transaction is authenticated ... the finread terminal contains self-contained, independent keypad (for PIN "something you know" authentication), display (so the value of the transaction you are authenicating is the value you see), and reader (for the token "something you have" authentication). 3-factor authentication paradigm
http://www.garlic.com/~lynn/subpubkey.html#3factor
every transaction requires newly displayed value on the finread value and re-entry of PIN in response.
the eu finread terminal standard calls for certified terminal ... which may benefit the person buying/owning the terminal. this is countermeasure to compromises of the environment where the authentication is taking place.
however, one of the things allowed for in the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
is that a token can digitally sign a transaction (as "something you have" authentication) and the environment that the authentication takes place in can also digitally sign the transaction. this is a countermeasure to "copy" &/or counterfeit terminals ... aka the finread standard calls for terminals to meet a certain anti-fraud specifications ... but doesn't mandate a mechanism for proving that a finread certified terminal was actually used for any particular operation (a counterfeit finread terminal may still trivially contain a trojan).
a digitally signing token (single factor "something you have" authentication) can be certified (to the satisfaction of relying parties) that it only operates when there has been additional authentication, aka the token requies correct PIN ("something you know") before operation. The validation of a digital signature then can be taken as imply both "something you have" authentication as well as "something you know" authentication (i.e. two-factor authentication).
that normal PC end-point environments have been known to be trivially vulnerable to viruses and trojans for a long time. a certified eu finread terminal is countermeasure to such viruses and trojans by providing a separate secure environment where authentication takes place (as countermeasure to widespread viruses and trojans in the pc environment).
however, the eu finread terminal specification didn't mandate any provisions for proving that such a certified terminal was actually in use ... as a countermeasure to counterfeit terminals. x9.59 standard provided provisions for both digital signing by the authentication token as well as provisions for digital signing by the authentication environment.
one of the issues in previous comments (in other threads) about "yes card" attacks ... was that some authentication environment was compromised (either evesdropping in the physical area of the authentication or via compromised or counterfeit terminals). The result of the evesdropping was then used to create the counterfeit "yes cards" which were then used as far away as possible. This two-step process by the crooks was a countermeasure to rapid identification and elimination of the compromised authentication environment (and any associated compromised or counterfeit terminal).
This maximized the non-trivial investment to compromise the
authentication environment (and maximize the fraud return-on-investment).
another countermeasure has been privately owned PDA or cellphone devices for use in authenticated transactions (to unfamiliar terminals that may be compromised or counterfeit) ... assuming they have similar attack countermeasure properties as found in eu finread terminals. one of the more recent issues as that as PDAs and cellphones become more sophisticated, it seems to also be increasing their susceptibility to virus and trojan.
misc. past posts related to "yes cards"
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
vis-a-vis security is harder than you think
long series of postings (dating back to ancient history) on the evils of buffer overflows and that common C language environments are especially vulnerable to coding mistakes that result in buffer overflows.
http://www.garlic.com/~lynn/subpubkey.html#overflow
and of course long series of postings regarding SSL (also dating back to ancient history) ... especially SSL digital certificates ... and frequently that they have more contributed more to the feeling of "comfort" (than any actual security)
http://www.garlic.com/`lynn/subpubkey.html#sslcert
oh, for a little drift, some additional, recent comments regarding attacks on the "authentication environment" ... as opposed to attacks on the actual authentication ... and countermeasures.
http://www.garlic.com/~lynn/2006h.html#14 Security
Some quick comments:
1. The URL http://www.hecker.org/mozilla/foundation-activities will always give the latest version of my Mozilla Foundation reports.
2. I can't speak for Red Hat and Sun, but I don't think that their support of ECC is motivated solely by US government business. As Bob Relyea noted in his presentation, as crypto implementations move to higher key sizes ECC has a decided advantage over RSA in terms of relative performance.
3. I'm not a lawyer so can't give a definitive opinion, but my understanding is that the basic ECC algorithms are not encumbered by patents; rather the ECC-related patents are for specific ECC implementation techniques. (For more information see the Wikipedia article on ECC and the separate Wikipedia article on ECC patents.) To my knowledge the ECC code going into NSS (and hence into Mozilla-based products) is based on public domain ECC algorithms, and of course that code will be released under the standard Mozilla MPL/GPL/LGPL licensing scheme. So in that sense it will be just as free and open as the implementations for RSA, SHA-1, AES, and so on.
Posted by: Frank Hecker at April 24, 2006 01:44 PM1. fixed above, thanks!
2, 3. OK, my perspective is perhaps coloured by the experiences we had in the Cryptix group a few years back. Then, when esteemed cryptoplumber Paulo Barreto implemented EC in Java, he found that the non-patented set was so slow as to be completely uninteresting. Or so I recall... I guess Bob Relyea will have the last word when the code is done and some basic benchmarks can be cranked up.
Posted by: Iang at April 24, 2006 02:10 PM