We all know how banks identify themselves to users. No, not through TLS certificates. The users pay no attention to those. No, I'm talking about branding-- all those fancy logos and stock photos that give you the impression it's your actual banking site.

The trouble is that anyone can copy those images for themselves and make a convincing fake of a bank's site, and trick users into entering their banking password, even though the site they're on is the wrong domain. This is why phishing works.

So since users don't check the domain name or TLS certificate chain, how else can we prove, before they enter their password, that they're on a site they should trust? (e.g., showing an image the user could recognize, but a third party would have trouble forging, like a reverse captcha)

(P.S. The obvious alternative solution is not to require a password at all, like in Google Authentication, but I'm retrofitting a set of websites and I'm looking for alternatives.)

  • 3
    That is why the Green Address Bar in web browser was invented for. So users can immediately know they are in the correct place. EV Certificates are not cheap and the verification is much detailed, so if someone wants to forge a bank, they have to prove themselves to be a bank (with official documentation).
    – lepe
    Aug 19, 2015 at 0:34
  • The obvious solution is to look at the domain name.
    – schroeder
    Aug 19, 2015 at 0:36
  • @schroeder: If a DNS server is hacked, that won't be of great help. Actually most phishing cases use similar addresses to trick users, like: security.facebook.com.t1000.be , some minds will pick "facebook" first and naive users may be tricked (which are the perfect target). Even worst, I have seen in some mobiles, the url is trimmed to the first N characters, so they will see "security.facebook.com...".
    – lepe
    Aug 19, 2015 at 0:48
  • @lepe I agree with all your points, but instead of trying to devise a new method that will also require training, just using what's there is a much better solution.
    – schroeder
    Aug 19, 2015 at 3:53

3 Answers 3


Security measures strengthen in inverse proportion to convenience... so I probably wouldn't do this... and I don't know a single site that does this... but... you did ask.

How about a workflow like this:

  1. User accesses web site and enters user name
  2. Site looks up user's phone number and sends one time code or a random word as SMS.
  3. Site displays one time code and instructs user to verify it against the code/word sent to the phone

Phishers won't know the user's phone number. They could in theory trigger the one time code (via MITM) but the attacker would not know the code. So if a user sees a code on the page and on the phone, (s)he knows that the site is good.

  • This seems to be another vote for "no password." There's a lot of appeal to this approach for me: it's easier to explain to the users, and it should raise a lot of alarm bells if a site asks for one. If I don't see a better solution, I'll mark yours as the answer. Aug 19, 2015 at 1:52
  • @fluggo it's not about "no password" because a password could also be used in this scenario. It's simply about adding another factor in addition to a password.
    – schroeder
    Aug 19, 2015 at 3:55
  • the phisher see the one time code when he trigger it so it isn't better than simply send the code and it a simple 2FA. and the only difference against fishing it grant only one access by attack. Aug 19, 2015 at 6:38
  • robin, you're right... oops. MITM is pretty hard to defend against.
    – John Wu
    Aug 19, 2015 at 19:07

I know of one that let's users upload a picture of their own choosing when the account is set up. (They can change it later.) The picture is shown on the password screen, after the user ID is entered. Wrong or no picture == fake web site.

You would want to use a back-end program to make the pics a standard size and to strip out meta data before storing them.

  • You're referring to a variant of SiteKey, which is "Security Theatre" - security.stackexchange.com/a/26380/396 Aug 19, 2015 at 0:03
  • I hadn't heard of SiteKey. I read the answer to which you linked. Yes, a gullible user could potentially be flim-flammed into supplying a password anyway. I disagree that the technique is (entirely) security theatre because it gives the cautious user something the user can actually check, as opposed to a bank's branding images, etc. which are trivially forged.
    – Bob Brown
    Aug 19, 2015 at 0:10
  • 1
    SSLStrip and other hacks can trick even the sophisticated user. When using a mobile device, no SSL icon is visible, further worsening the security position. Aug 19, 2015 at 0:22
  • This may work only if the users are clearly informed and trained about it. Otherwise, a forger could use a generic image like: "We are sorry, the system is under maintenance", which may trick them. Take as example the Gmail's profile icon. If instead your avatar, the generic "G" or "Gmail" icon were displayed, would you suspect something? the chances are that you would ignore that assuming that for some technical reason it was not loaded, and proceed to login.
    – lepe
    Aug 19, 2015 at 0:40

The problem you are trying to solve is that the client needs to be identified by the server (to know which user this is) but the server needs also be reliably identified by the client to detect phishing. I agree that simply using HTTPS for identification of the server is not enough, since an attacker might simply own a similar looking domain (e.g. paipal.com vs. paypal.com) and get a certificate for it and thus can also do HTTPS.

The usual process of identifying the client by the server involves some kind of shared secret, where the client sends this secret to the server and the server verifies it (i.e. logging in with password). This process is obviously vulnerable to phishing.

The existing answers on this questions thus offer ways to make the user at least detect the phishing by having a second shared secret which is then presented by the server and verified by the user, i.e. use the customers phone number or some user chosen image as the second secret. But this second secret is not enough too because once the attacker successfully phished the user to get the initial secret (the password) (s)he might be able to determine the second secret after logging in.

Thus the proposed user chosen image alone is not enough because the attacker can find out the secret and reuse it. Only the SMS based proposal solves this problem by not showing the second secret to the client (and thus to the logged in attacker). Instead it only uses the secret indirectly to generate yet another (third) secret (a token) and make this secret known to the user in a way which is hopefully not accessible by the attacker. The client must present this secret token to the server and thus prove knowledge of the secret. Of course you could also use a different channel like e-mail or chat or an actual (automated) phone call to transmit the third secret, as long as the channel itself is not accessible by the attacker.

But while the proposal with the second channel sounds nice it has the problem, that it depends on this second channel for security. If this channel gets compromised by the attacker (i.e. trojan at the smart phone intercepting SMS) the security is broken. And if this channel gets unavailable (like with a lost or stolen phone) no login is possible and thus also no change of the secure channel. Historically this is a weak point and often attackers got access to the site by calling the support and tricking the support person into changing the phone number or e-mail to an attacker-controlled one, of course after answering some security questions where the answers could often be easily found out.

Apart from that none of these solutions deal with the problem when the attacker makes its own phishing site (e.g. paipal.com) and simply initially relays all data to the original site (e.g. paypal.com) and after successful authorization then cuts off the original clients and uses the established session for the attackers purpose. Simple HTTPS will not help here too because the attacker might get a certificate for its phishing site too.

An alternative way to secure the communication is to use HTTPS together with client certificates. Using the underlying public key cryptography the client can be identified by the server and the server by the client. The attacker might still create a phishing site but cannot capture the secret (i.e. the private key of the clients certificate) needed for later reuse. Because it is often not that obvious for the client that a client certificate is involved so some kind of phishing detection is still needed, but in this case the presentation of the user-chosen image could be enough. And since the attacker is not able to use the real client certificate to identify itself against the original site it can neither determine the user-chosen image nor is the relaying attack described above possible. Unfortunately the process of using client certificates is mostly not that user-friendly and also the certificate must be included in every browser the client uses. Also the certificate is shared between all users of the browser profile which might be a problem too if multiple users use the same computer.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .