[cookiecaper]

Right, it doesn't verify the entity with 100% certainty, but it's still probably a good thing to have, because it should be a relatively simple change in the bank's code and it creates a lot of extra work for an attacker.

It's just another safeguard, and I think it does a fine job being that. It's not meant as an iron-clad, utterly impenetrable phishing prevention mechanism. If OP believed that, perhaps he is the gullible one.

[duaneb]

I mean, I just think it makes the banks look bad/like they don't actually know how to secure a site.

[cookiecaper]

I think it's a reasonably cheap and fast method to increase security somewhat. It doesn't really mean they don't know how to secure a site otherwise.

[duaneb]

> I think it's a reasonably cheap and fast method to increase security somewhat. It doesn't really mean they don't know how to secure a site otherwise.

I really don't think this is a good argument. First of all, it's laughably easy (5 minutes work) to adapt, and sites need to be customized for phishing anyway. Second of all, phishing is the only thing it slows down, and there are many better ways they could ACTUALLY increase security (e.g. actually training people to look for SSL with a trusted certificate). For instance, why on earth don't they have a chrome/firefox/ie/whatever plugin that detects phishing sites? It would not be that hard to look for sites that look similar to Bank of America (for instance) that aren't at the url they're supposed to be at.

Hell, I would even be ok with a (heavily vetted and open sourced) plugin that made sure you never typed in your bank password anywhere but with SSL sites signed by that bank's certificate.

[cookiecaper]

> First of all, it's laughably easy (5 minutes work) to adapt

I feel like we're rehashing the whole thread here. This has been addressed elsewhere. It's more than five minutes, and adds significant expense to the operation because you need an adequate dedicated machine that can run your scrapers, whether you use Selenium, mechanize, phantomjs, or whatever. You also then make your IP a single point of failure and either must operate a network of your own proxies or hope that a public network like Tor isn't (and doesn't become) banned if you're to continue getting responses from the server. A serious phisher who makes a lot of profit from this would still have incentive to do it, but it definitely complicates the operation.

> (e.g. actually training people to look for SSL with a trusted certificate)

SSL isn't fool-proof, and the right approach to SSL verification is both much more complicated to explain and much less prominent than a server-side security image. If the explanation is "look for the solid green bar before the URL", well, nothing's stopping the phisher from getting an SSL certificate that displays that way, and the only thing that prevents self-signed certs is the "wow this thing looks bad" message the browser gives, which most users happily ignore anyway.

"Never type your password if you don't see that cute gorilla" is much simpler and not really much weaker than "Never type your password if you don't see the solid green bar prefixing the URL" (especially since you'll have to explain to many people what the "address bar" is).

> For instance, why on earth don't they have a chrome/firefox/ie/whatever plugin that detects phishing sites?

Because Chrome and Firefox (and probably IE and the others) already have this built in.

>Hell, I would even be ok with a (heavily vetted and open sourced) plugin that made sure you never typed in your bank password anywhere but with SSL sites signed by that bank's certificate.

Are you seriously saying that it would be a net positive for security if banks expected users to download and install any software they gave a link to as a prerequisite to using their site? This is an extremely suspicious tactic and a person vulnerable to phishing is surely not going to vet or confirm the validity of the downloaded code in the first place, so it would just create a precedent expectation of "Oh, I just need to execute this arbitrary code on my OS..." before a user could use their bank.

Though, it'd be interesting to think about extending browsers' built-in phishing detection with verification against SSL certs. It sounds good in theory but I'm not really sure if it would work in practice, unless you think it's OK to have false positives every time the SSL cert changes (which may happen more frequently than you think).