Imagine the following scenario: an unsuspecting user received an e-mail from his bank, claiming that there is some kind of problem in his account, and that he can easily fix it online. A link is supplied for his convenience.
At first glance the e-mail seems OK - The language is very formal and phrased just as the user would expect from a real bank message. The sender's address seems right, and the supplied link also seems to match (more or less) the URL of the bank (as far as the user can tell). This must be a legitimate message from his bank - how else would they know what his e-mail address was? The message mentioned some problem in his account, and nobody wants problems in their account. But it seems that it can be easily solved without even getting up from his chair. "The Internet made everything so easy", he thinks to himself and follows the link.
The obedient browser opens the link, and the user looks for the small lock icon at the bottom, just as he was taught - this means that the connection is secure! The web page, which looks exactly like the real bank's login page prompts the user for his user-name and password. The user types them in without thinking twice, and solves his little 'problem'. Now the Phisher is in possession of his user-name and password.
The Saphe solution makes sure that this scenario won't happen. Since the impersonating server does not know the user's password, it would not be able to produce the Saphe data required to authenticate itself to the Saphe plugin, and the user's password will never be sent. The random client-challenge sent by the plugin makes sure that no replay attack is possible. The only thing the user needs to pay attention to is the (very visible) Saphe dialog box (or the lack of it), which presumably cannot be mimicked by web-code (HTML, JavaScript, etc). Any login attempt which does not involve this window should be considered as a Phishing attempt.
The Phisher is therefore faced with two options: give up, or use Active Phishing methods (which the Saphe solution also protect against).
Note that some of the current anti-Phishing methods also protect from passive Phishing attacks. However, using idiosyncratic characteristics to prove that the server on the other end of the line is indeed the real server does not protect against Active Phishing, as any active Phisher will be able to mediate between the user and the real server, which will allow him to obtain the password.
The Saphe solution prevents the would-be Phisher from passively masquerading as the real server. What will happen if after soliciting the user to connect to his server, the Phisher will connect to the real server on his behalf? The connection can even be secure (using SSL), assuming that the fallacious domain name is different from the real server's, and that some root Certificate Authority signed on it. Note, however, that the URLs the user requests must all be under the Phisher's domain, or else future traffic will not pass through his server.
What will happen?
- The user will send his user name and a random challenge to the Phisher, who will then pass them to the real server
- The server will derive a key with the user's password and challenge, create a Saphe data package containing the IP address from which the connection originated (6.6.6.6) and the requested URL (https://www.evilserver.com/...) and send the encrypted data to the Phisher
- The Phisher now has three choices:
- Pass the Saphe data - in which case the user will discover upon decryption that someone is meddling with the connection
- Withhold the Saphe data - in which case the login process will not continue and the password will not be sent (effectively causing denial of service)
- Change the Saphe data - in which case, since the Phisher does not possess the password, the user will discover any alteration when checking the HMAC signature
Phishing is not possible in this scenario. What will happen in the case of DNS poisoning?
In this case, let us assume that the Phisher somehow managed to divert all the traffic to the legitimate real server to his own server (usually using a DNS poisoning attack). In this case the user does not even need to be bamboozled - he is directed to the Phisher's server even when he attempts to connect to the real server of his own accord.
In this case the Phisher will not be able to use SSL connection to the user, since he does not have the legitimate certificate's private-key for the domain realserver.com. This by itself will prevent the login process to continue (as the Saphe plugin will only agree to send sensitive data through a secure connection), but even if in some way a connection between the user and the Phishing server is established, the Phishing attempt will be discovered as soon as the 'client IP' returned from the server (6.6.6.6) in the encrypted Saphe data is compared to the user's real IP address (1.2.3.4).
It is always possible for the Phisher to spoof the source IP address of his outgoing packets to the real server, but that means that he will not receive the responses, and therefore will no longer be in control of the session and any future data sent between the user and the real server.
However, there is a way for a Phisher to use the same IP address as the user - direct Man-in-the-Middle capability.
If a Phisher somehow managed to completely take control of a computer which is always in the direct route between the user and the real server (which is no small feat), he will be able to make his packets appear as if they originated from the user's machine. This means that the comparison between the IP address returned from the real server to the user's own IP address will not reveal this attempt (both will be 1.2.3.4 in this case).
However, there is still a big problem for the Phisher - he cannot establish a secure (SSL) connection with the user if he chooses to use the same domain as the real server (since he does not have the legitimate certificate's private key for the domain realserver.com).
There are only two alternatives for him:
- Use a different domain name, which will force him to direct the user to a different URL than the one returned by the real server, and therefore reveal the attempt
- Use the real domain name, in which case the connection will not be secure and the Saphe plugin will not agree to continue the login process
