On Sunday 19 June 2005 01:05, Tyler Close wrote: > I think it's also important that we move beyond the "blame the > customer" phase of this failure. Phishing occurs not because the user > is lazy and stupid, but because the current SSL UI is lazy and stupid. > The current SSL UI just blindly displays whatever the attacker asks > and punts to the user for the work of recognizing the site and putting > it in context. It's a 1.0 release design that was never followed up > on. We're paying the price for this design laziness now. Phishing is > our fault, not the user's. Until we accept this, we will fail to > understand or solve the phishing problem.
I think it's important to bear in mind the historical context of how this happened. Back in the early 1990s, this thing called ecommerce started up, and a few people were concerned about listening to credit cards. There was a bit of a precedent for this in account password sniffing that box crackers were after. A deeper analysis and the experience of SSH have shown this to be a shaky foundation, but it was a fair mistake to make, at the time. Coupled with the emphasis on "the search for the revenue stream" and a bunch of crypto venders who thought their time had come, the scene was set for a very big approach to this threat. They didn't adopt the original threat model, but picked up a military- inspired threat model - the MITM - which came from the best of crypto experience, going back through centuries of warmaking. They took it very seriously; and in the event, far too seriously. They went 'over the top' and fielded a system that was far more secure, far more developed than was required. It also made severe demands on the users and the browsers. Now, what the users discovered and the browser GUI people also discovered was that there was no threat. There was no-one listening to credit cards, at least. (Recall, online banking and thus a need to protect passwords did not turn up until later.) So users did the logical thing - they ignored the security. No threat, so no point in doing anything 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. Then, in 2003 or thereabouts, phishing took off. This was indeed a threat that the original designers of the secure browsing model had considered and covered. But it didn't exist as a threat back then, it was simply predicted as part of their total threat model. So everyone acted rationally. The result was a weak security system, and phishing. The challenge now is to unravel that. The challenge for the users is to recognise that their decade-long discovery of "no threat" is out of date, and there is now a threat. Which means they need to be part of the security model. The challenge for the UI designers is to figure out what the threat is and what the best way is to engage the user in the security model is. They have to debunk the inbuilt contradiction that there is "no threat", and that the security model that is in place conquers "all threats." The challenge for the security designers - the crypto people and the overall security community - is to debunk the assumption that the secure browsing system is secure. They need to examine it in the context of a 10 year old model that was overdone at the time, scaled back over a decade, and is now misaligned to a threat that is agile enough to enjoy its state of disrepair. Everyone of those groups need to do something. It's unfair to say that anyone of them is to blame, per se, but it is equally inaccurate to say that they don't need to do something. iang -- Advances in Financial Cryptography, Issue 1: https://www.financialcryptography.com/mt/archives/000458.html Daniel Nagy, On Secure Knowledge-Based Authentication Adam Shostack, Avoiding Liability: An Alternative Route to More Secure Products Ian Grigg, Pareto-Secure _______________________________________________ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
