non-SSL is the problem

I am suggesting that browsers stop filling in for non-SSL, and that the SSL whitelist selection be based on the organization information in the certificate rather than on hostname/DNS. (At least the non-SSL and hostname based password traffic should be denigrated.) These two small steps make a significant difference. This defends against:

a) Man in the middle attacks by phishing.

The password threat is basically a MIM threat. As an old fart I still read email in text mode, and I frequently see phishing emails that have used the http://good-site for all but the password portion of the interaction. That one little piece frequently has a text label of https://good-site, but the actual link is http://bad-site. All of the icons, pictures, and other site interactions are with the actual good-site, so the victim is correct in thinking that this is the actual site. Anything sent via http will be from the good-site. The only thing that the bad-site cannot do is generate an SSL connection that shows the exact same organization information as the original good site. Therefore, I base the password logic on the organization information of the good-site.

I avoid DNS because DNS can be hijacked also. I have detected criminal domain hijacking through my insistence on using SSH host authentication. Domain attacks are reality. The SSL certificate organization information is not vulnerable to hijacking. Even those criminal organizations that do get valid SSL server certificates are unable to duplicate the organization information content.

This does mean educating both users and web sites to demand that password traffic be SSL protected. This is a growing practice by the better web sites, so I think that the time is ripe to start pressuring them by changing browsers to highlight all non-SSL password traffic as probably phishing attempts. I would only apply this to the password portion of the traffic. Use of SSL elsewhere depends on the other traffic's value.

This small step still leaves a major technical vulnerability:

b) penetrating the home computer

SSL protection only protects against a MIM outside the home computer. Once inside the browser, you can resume MIM attacks. Technologies like AJAX, browser helper objects (BHO) in IE, and extensions in Firefox, all enable penetration. The Web 2.0 enthusiasts rhapsodize over the potential wonders of AJAX and overlook the fact that they are encouraging you to allow some remote sociopath to replace your browsers user interface. None of these new technologies were designed to limit the damage that can be done when the source is a sociopath. They were designed to enable great things by good people, and thus allow great harm when used by sociopaths.

Technology is limited in what it can do about phishing. The core of phishing is the re-purposing of desirable intended functions for fraudulent use. It can do better, and I hope that the AJAX, etc. designers start considering restrictions to limit the harm that can be done by malicious code. But in the end, the technology will be unable to detect well implemented fraudulent uses, and the users are vulnerable to fraud.

This is why I look to independent path verifaction as the value of the transaction increases. I like the growing use of one-time credit card numbers because they limit the financial exposure unless the attacker has penetrated multiple sites at different times with a coordinated attack. The users need only a small increase in effort to take advantage of this, and it flows through the credit card protection system easily.

The enduring anti-fraud mechanisms of audit trails, detections, restitutions, and punishment of the defrauders also have to be part of the process. It is time to start thinking about how can this be done without destroying personal privacy. What extra steps can be integrated into mail, browsers, etc. to let investigators track back once the fraud has taken place so that the sociopaths can be caught and punished. The audit technology has not been thought about and is almost entirely missing from current systems. It's time to start thinking about it.

Reply

Please enter Brad's last name above. Case doesn't matter
Please make up a name if you do not wish to give your real one.
The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

More information about formatting options