Amir Herzberg's
Phishing and Spoofing FAQ
Questions with answers…
Stealing of passwords and subsequent unauthorized access and abuse of accounts is possibly the most common fraud on the Net, and is causing substantial losses to individuals and corporations. The easiest and most common method for stealing passwords, is by creating a `spoofed` web site, i.e. a site which looks like the real login site, but collects the passwords for the attacker. The easiest and most common method to lead the user to the spoofed site is by sending him fake, misleading e-mail; this is called `phishing`. See more details in http://antiphishing.org. All browsers support the SSL and/or TLS protocols, which allows the browser to authenticate the identity of the web site before you enter your password to it, and then encrypt the password (and other sensitive information) in transit, to prevent disclosure to eavesdroppers.
Encrypting the password prevents exposure by an eavesdropper, which is good. However, some web sites deploy encryption using a script in the login page, and do not invoke SSL/TLS before that, to authenticate the login page itself. Therefore, if the user received a spoofed login page, this will not be visible; of course, the spoofed page will send the password to the attacker.
Unfortunately, several sites – including some major bank sites, e.g. Chase – present a padlock and/or otherwise claim to use SSL and cryptography to protect the login process, while actually only encrypting the password in transit using a script in the login page. This is misleading and insecure, as explained above.
On June 2005, the FDIC published 'Putting an End
to Account-Hijacking Identity Theft Study Supplement'. I think it is well
written and worth reading. In particular, in p. 22, under the heading `mutual
authentication, they say: Financial institutions can aid consumers in differentiating
legitimate sites from spoofed sites by authenticating their Web site to the
client. More specifically, banking Web pages which collect sensitive
information on form pages, or otherwise, should authenticate the page using
digital certificates signed by a trusted authority prior to collecting the
sensitive information. Certificates should be registered to easily identifiable
business names rather than third party service providers to aid the consumer's
understanding of the certificate's authenticity. This is exactly the
point I'm trying to make with the Hall Of Shame, although maybe stated a bit
more delicately – and therefore, may require careful reading. I've sent e-mail
to the FDIC to confirm my understanding and their response further supported my
position, in fact they said I
also understand the point you are making with regard to our discussion of
mutual authentication. I agree that we could have been a bit clearer.
(My main reservation was that their text may be interpreted as if using SSL
requires high costs, where they actually referred only to the use of SSL client
authentication)
There are several good, secure one-time-password
login mechanisms and devices. However, these devices (usually) only identify
the user during the login process. It is possible to launch a spoofed web site
that will pass the one-time-password to the correct bank site, and thereby
obtain access to the account for the particular session. This attack is not so
easy, mainly since it requires the attacker to exploit the login immediately,
rather than providing her with a password which she can use later at her
convenience. Still, proper identification of the site, using SSL/TLS
protection, provides additional security also when using one-time-passwords.
A personalized greeting can allow users to detect a spoofed site, which is unaware of the greeting. However, the security of such solutions depends on implementations details, as follows. [To be completed]
The risk is indeed reduced. However, an attacker who is able to intercept your messages, e.g. if you are using a wireless internet connection such as WiFi or if they control a switch or router that your information passes through, can still redirect you to a spoofed page. There are many ways to intercept communication on the Internet, and the SSL/TLS protocols are specifically designed to withstand such (strong) attackers.
This depends. In particular, many banks, e.g. in the
This is a legal question, and while I have been reading about it and discussing it with lawyers, I cannot give legal advice. However, I think it is fair and reasonable to say that liability may exist in some cases. In particular, the claim for liability may be stronger if the injured party can prove a failure to maintain `duty of care`, and in particular negligence in spite of warnings. For example, I am warning all sites before adding them to the `hall of shame`, and add them only if they do not fix (i.e. protect) the login page.
Ask them J … Seriously, there are some reasons. One is ignorance and negligence; the security indicators existing in most browsers are so hard to notice, that webmasters, as well as users and designers, sometimes do not notice the lack of protection. But, there are some other reasons. Performance and the cost of obtaining a certificate are often mentioned, but in reality, both of these are not significant obstacles and can be overcome easily (but some designers are not aware of this). One `real` problem is that many sites, especially the larger, use third-party hosting of their sites, possibly to reduce latency by providing the contents from a nearby server. In this case, there may be a dilemma: should the site use a certificate (and identify) of the third-party hosting it? Or should the site give its private key to the third-party?
Of course, there are simple, technical solutions to all these problems, with reasonable costs and overhead. A proof of that are the many sites that do provide secure login properly.
One interesting argument we heard was that there are most users will not notice if they receive an unprotected site instead of the protected site. This may be true using the weak security indicators in most current browsers. This can be addressed by installing improved security indicators (e.g. TrustBar) or using a browser with improved indicators (e.g. Netscape version 8).
Fortunately no! Most of the (serious) login pages are well protected. Just check – we have a lot of sites in the `Hall of Shame`, but still only a tiny fraction of the login pages… Try to find another one. It may not be too difficult, but you are likely to encounter a lot of protected login pages.
To be completed: using existing browser UI, using TrustBar (http://AmirHerzberg.com/TrustBar), using other toolbars…
To be completed: using new versions (0.4.1 or later) of TrustBar (http://AmirHerzberg.com/TrustBar) [add details!!]…
Few bars access a centralized server upon entering any new web page; this has significant overhead, and may be a privacy concern to many users. However, other bars, such as TrustBar, do not expose privacy in any way, and have no noticeable overhead.
We recommend you immediately contact the site owners to warn them and ask them to protect the site. You are also encouraged to inform us, so we can add the site to the Hall of Shame. You can inform us by email or by clicking the Hey! button, if you have installed TrustBar.
Browser security indicators can use a list of unprotected login pages to warn the users of such pages. This may be a future feature of browsers and/or of extensions such as TrustBar. We are working on such a feature for TrustBar (in fact it is almost done).
Yes, we try to warn them before adding the site to the Hall of Shame. We had few sites which were fixed after our warnings, completely or at least partially. Unfortunately, most sites ignore the warning, argue about it, etc.; one site even sent us coupons for free use of their services…
Yes, there are... (to be completed)
See information at http://AmirHerzberg.com/TrustBar.