In this bank site I read the following lines

Item #2 - You will also need to create a "Security Word". This allows you to verify that you have reached our Internet Banking site, and not some other site. Every time you attempt to log in to your accounts, we will send you a graphical representation of the Security Word that you created. If you do not see that Security Word or it is not the one you created then you know that you are NOT at OUR site. If this happens, please contact us immediately.

It says that bank displays the security word so that user can know that if he/she has reached the correct site, but I don't understand how it prevents man-in-middle attack.

The attacker can ask victim to enter the credentials, which then it can use to send REST back-end request to original bank site, which will return an html containing the security word of the victim, which can easily be parsed and can be shown on phishing site. So how does this security word actually help?

4 Answers 4


Long answer: This type of security mechanism is not meant to protect against MitM: it's meant to protect against URL mimicry/spoofing/phishing. Example:

  • Users receive a spam message which looks like it's from "Legit Bank"
  • Spam message contains a link to "Update your information", hosted on a criminally-controlled server
  • Users enter their information, fooled by the convincing website

This security mechanism is meant to help end users verify that the site they're visiting is legitimate, without having to teach them the logic mechanisms behind how to identify phishing emails or spoofed/mimic URLs.

Additionally, the sophistication required for this kind of MitM would exceed the return from ordinary bank fraud. Simply put, if you're that good, it's not worth your time or risk to go after end-users.

Short answer: No, it doesn't protect against MitM.

Edited for brevity.

  • How does it prevent URL mimicry/spoofing/phishing? because attacker can again send request from backend after getting userid/credit card info and retrieve the security word. Also this attack needs just a simple REST request with cookie support. And as this is banking so it has big money involved so it will attract many attackers.
    – Ankur
    Nov 12, 2013 at 2:39
  • Ankur, it protects againts spoofing only if the user notices the absence of the correct security word before providing his password or other important info.
    – mgkrebbs
    Nov 12, 2013 at 6:06
  • but attacker can easily pull secret word by sending a post request from his/her back-end. can't he/she?
    – Ankur
    Nov 12, 2013 at 7:38
  • It relies heavily on the user noticing differences, a little bit like the 'You were last logged in' message - advanced and mindful users will pay attention to these little things and act if they see something wrong. Unfortunately, it's generally the less attentive users who need protecting, so IMO, it's probably not massively effective against attack.
    – Owen
    Nov 12, 2013 at 12:36

As explained in previous answers, such kind of protection do not fight against MITM attacks, but against spoofing site designed to steal credential information.

A well-documented example is Yahoo's sign-in seal: Yahoo displays an image of your choice right on the login page (before any login attempt). Yahoo is able to display the right image because they recognize you thanks to a cookie stored in your browser.

So, your browser will send the cookie only to a website matching the real hostname. For instance it will send the cookie to login.yahoo.com, but there be no cookie sent to a domain like login.yahoo.com.my-phishing-site.com since, even it may trick a user, the domain does not actually match.

Therefore, a phishing site does not receive the cookie, so they cannot even present it to Yahoo login page to fetch the image. So, if a user sees the image on his login page, he can reasonably assume he is on the legitimate Yahoo login page and can trustfully provide his login and password.

If he does not see the image (ie. the login page does look as usual, which is much more noticeable than a pure text information message), he will be alerted that something unusual is ongoing and check more through-fully before providing any credential information.


MITM vulnerability depends on the details of how they've implemented this feature.

Some implementations are trivially vulnerable, as other answers explain.

Some implementations have MITM protection. These are generally focused on the case where a user has previously logged in from the same machine. The browser will have a long-lived cookie installed, and before login the server will take the cookie and display the security word. The phishing site will not have that cookie, and so won't be able to get the security word.

The problem with this approach is dealing with the case where a user if logging in for the first time off a particular computer. You have a catch-22 situation where the server can't reveal the security word until the user has authenticated, and the user doesn't want to enter their password until they see the security word. Commercial systems have particular ways of dealing with this, which are generally flawed.

The bottom line is this is a pretty dodgy security mechanism. We already have a strong way to authenticate the server - the SSL certificate. Sure there are problems with SSL certs, but these kind of "memorable word" systems are worse.


(oop... paste from duplicate on SO)

I don't understand how it prevents man-in-middle attack.

Indeed, it does not.

It does mean that the lazy kind of static phishing site that makes up the majority of attacks would fail: a phishing attacker would have to set up some means of querying the real service for the user's security word/image/etc (which, if not routed through a botnet, would result in an unusual access pattern than in theory a bank's SOC could detect).

You could consider this as having some value for the bank in terms of making them not the ‘lowest hanging fruit’ for phishing attacks. But it does nothing against MitM attacks, and research suggests that so few users even take any notice of site-to-user authentication that it's not worth bothering with.

It may have some value for the bank as “perception of security” theatre.

You must log in to answer this question.

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