Gone Phishing...

[kayal cox]

I am not quite sure if this would fit under Programming Diversion.. so, you can transfer this to a different forum if need be

Anyways, phishing is causing millions of dollors worth of damages today.. and till now, apart from steps taken to increasing awareness among customers, there does not seem to be any other major idea to safeguard people against these scams.

And that led me to thinking, while earlier the concern was that a customer who approaches any service needs to identify himself(Userid/password proved to be a good solution to that problem), now are the days when the service renderer also need to confirm they are who they say they are. What kind of a mechanism do you all think can be implemented with any amount of practical ease to handle this?

[Eric Pascarello]

Moving to general computing....

[M Beck]

well, there's Kerberos, but it's kindof hard to implement on the scale you're talking about. there's also SSL/TLS personal certificates, which might be doable, although there's still a scaling and implementation issue. also, i'm unsure of how well end-user software supports them; i wouldn't know how to tell my browser about a newly-acquired personal certificate of mine, and i'm fairly savvy.

[Helen Thomas]

The new Opera browser.

[kayal cox]

Well, having the Opera browser and secure certificates are good... but lets take a financial institution like a bank. They would have customers who are completely non-technical... who have old browsers, and may not know anything about upgrading browsers etc.. We would have 80 year old people, visually impaired people etc, who use the computer (that their techie son/daughter got them ) only to check their online accounts...
And like Beck mentioned, even fairly computer savvy people might find these difficult...!
[ April 09, 2005: Message edited by: kayal cox ]

[Jeroen Wenting]

and of course phishing attacks are browser independent...

[Joe Sondow]

Phishing is a form of the trickery performed by con-men. Con-men do everything they can to convince unwary people of a falsehood. The bank has no control at all over what email its customers receive from phishers, nor can it have any control over con-men temporarily publishing web sites that look identical to the bank's web site.

It seems to me that the only option a bank has for reducing the effectiveness of phishing attacks is to educate its customers so that the customers become more savvy about the particular issues involved in phishing. It's not a technology-based solution, because I don't really think a technology-based solution that the bank produced would be effective.

Where would a bank-produced technology-based solution be installed? On the bank's web site? That wouldn't help, since the actual web site doesn't usually get visited during a phishing attack. On the customer's computer? That wouldn't work without educating the customer first so they would install the solution.

If anyone does think of an effective technical solution that could be implemented by the bank without the education of the customer, I'd be very interested to hear it. It seems logically impossible to me.

[Jeroen Wenting]

The only way to prevent phishing attacks is to use custom software for every service provider separately which is delivered physically to each customer individually.
In other words, back to the old days...

And even then people might still fall to phishing attacks in which reverse engineered versions of such software are dumped on floppies or CDs down mailboxes as "upgrades", but the risk would be far less as the distribution would be far slower, riskier (fingerprints anyone?) and more expensive.

[M Beck]

custom client software is not the only way, but it might well be the only practical way. what you want to do is authenticate the client on the server end, to make sure that a request isn't coming from someone not authorized to send it, and things like personal SSL certificates could do that. as you mention, though, we'd still be vulnerable to trojans and social engineering attacks, and probably the only way to deploy certificates widely would amount to custom client software in any event.
[ May 10, 2005: Message edited by: M Beck ]

[Jeroen Wenting]

That doesn't work I'm afraid.

The phishing scam creates a fake client connected to a server which is not the server it claims to be, therefore the client never connects to the proper server at all.

Your approach might work against a man in the middle attack but that's not what we're talking about.

[M Beck]

how does it not work? client certificates identify the originator of a request uniquely; so long as the server end has a way of verifying SSL certificates that have been granted to their individual customers, this should be as secure as SSL in general is. you'd still have to worry about the general security of the clients' computers, trojans, and social engineering, but at least you could be sure that any hypothetical bad guys had had to break into the victim's home computer first.

a phisher using a fake server could still get the username and password, of course, you're quite correct about that. but if the genuine server relied on seeing the correct username and password transmitted over an SSL-encrypted session created with the client's SSL certificate, then the phisher would have to convince the victim to give up their certificate and any password(s) protecting it first — a considerably harder target. if i were that phisher, i'd go to a trojan worm attack vector instead — and i have this sinking feeling it'd probably make the attacks that much more efficient.