25

My bank recently changed their login process to show a preselected image which they label a "Confidence image" - ostensibly to allow a human website user to authenticate the bank's website as not being a spoof.

The old login process was:

  1. Visit BankName.com (entire site is secured with an EV certificate)
  2. Click Login link, a GET request to their login page
  3. Enter username and password, POST submit form
  4. Receive HTTP 303 redirection to account dashboard page

The new process is:

  1. Visit BankName.com (entire site is secured with an EV certificate)
  2. Click Login link, a GET request to their login page
  3. Enter username and password, POST submit form
  4. Receive HTTP 303 redirection to "Confidence image" page, which shows a picture I previously selected, it also prompts me to re-enter my password for a second time. After POSTing this form it redirects to my account dashboard page.

I don't see how this adds any actual security - any MITM, or any proxy for that matter (assuming the TLS security is compromised somehow) could forward the confidence image and I would recognize it. Similarly a spoof website need only forward my own credentials to the real bank login page, get a copy of the confidence image, and re-serve that - which would fool a less sophisticated user very easily.

Only a very basic spoof website (with a hard-coded confidence image page) would cause users to see the discrepancy, but the biggest problem is that it only shows the image after I have already entered my password - so the feature is useless because the spoof or attack website has already got a copy of my username and password.

I remember at one point Yahoo's OpenID login page did show a confidence-image, while that was after I entered my username,t crucially it was before I entered my password (so the login process was split between two forms) - I believe it was also based on a HTTP-only cookie, so logging in to Yahoo in a clean browser wouldn't trigger the confidence image.

Using human-intelligence to perform mutual-authentication seems like a bad idea - X.509 certificates already perform the role of server authentication, and EV certificates make this easier for less sophisticated users ("look for the green"). I fail to see the motivation... or success behind this move, and am frustrated by having to jump through another hoop to login to my bank.

UPDATE: A few weeks after my bank introduced these confidence-images they changed the login process so you enter your password after seeing the image:

  1. Visit BankName.com, click the Login link
  2. Enter username only.
  3. Response page has the confidence-image and a password input box
  4. Submit with the correct password to get to your account dashboard

An interesting comment by Joshua suggests that these images could help in MITM situations provided every image request is logged and could be used as evidence of a phish attack, like so:

  1. User clicks link in phishing email, opens TotallyNotFakeBank.com/login
  2. This login page only has a username prompt.
  3. After submitting the username, the MITM server makes a new request to the real bank website and gets the real confidence image. This request will be from the MITM's own IP address (Hypothetically the MITM site could use the client/victim to make an AJAX request for the image, but if CORS and other restrictions are set-up correctly this should be impossible)
  4. The MITM generates the fake confidence-image page and re-serves the image to the victim, and the victim passes their password.
  5. The victim subsequently loses money after the attackers use the credentials to get money from the account.
  6. The victim informs their bank and the bank checks the access-logs of the confidence image and sees that the original request for the confidence-image did not come from their usual web-browser, leading the bank to believe their customer's story instead of assuming it was a false report.
Improve this question
4
  • 2
    Agree. Even without MITM, a phishing site without sitekey still works : because most user don't care, they will just key in the password.
    – mootmoot
    Jul 29, 2016 at 11:21
  • I have also used a service that used this approach (correctly implemented as in the below answer) and thought it was pretty useless because they had me choose from one of (IIRC) 4 predefined images. This meant that there was a 25% chance a hard coded attacker would guess right, in the same way a broken clock is right twice a day.
    – Josh Rumbut
    Jul 29, 2016 at 18:10
  • @JoshRumbut, that doesn't necessarily mean that all users get the same 4 images to pick from. The site could have a large collection of images and just show a small selection to each user.
    – cjm
    Jul 29, 2016 at 18:43
  • @cjm anecdotally, of three other users whose image I had seen, they all had the same selected image. You're right that that would strike a nice balance between UX and security though.
    – Josh Rumbut
    Jul 29, 2016 at 19:10

1 Answer 1

Reset to default
40

You are describing a variation of SiteKey.

Your bank implements it incorrectly because it asks for both username and password before showing the image. If the page were an attacker's he couldn't show you the correct image, but that doesn't matter because he already has your username and password.

If correctly implemented, it is still greatly ineffective.

Improve this answer
7
  • 3
    For the correctly implemented -- but as you say ineffective -- method see also security.stackexchange.com/questions/19155/… security.stackexchange.com/questions/26347/… security.stackexchange.com/questions/26332/…
    – dave_thompson_085
    Jul 29, 2016 at 10:17
  • 4
    +1 for "your bank implements it incorrectly". The part of entering all of the credentials before getting to see the image really stood out to me, too, in a "WTF?" (or even TheDailyWTF) sense.
    – user
    Jul 29, 2016 at 20:28
  • 1
    SiteKey falls to a man-in-the-middle attack. It also falls to a back-end regeneration but this leaves a traceable log on the bank's server so it's detectable.
    – Joshua
    Jul 30, 2016 at 1:50
  • Ironically, SiteKey itself is solid design against phishing attempts, but sadly it isn't user-proof enough to be effective.
    – Jeremy Kato
    Aug 3, 2016 at 17:47
  • A critical thing to mention is that the site is supposed to check for cookies to see if you're on a known previous used browser. Otherwise it asks a security question. This is done before showing the image. Except, of course, a dedicated MITM attack could show this security question and then get the image. Users are unlikely to get suspicious of being asked a security question, anyway. So as far as I can tell, this isn't immune to phishing at all. It only makes it a bit harder. And that's ignoring the fact that users ignore the images.
    – Kat
    Aug 10, 2016 at 22:42

You must log in to answer this question.

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