2

I find it very strange that bank use service like SiteKey without user-agent identification. This still makes them very vulnerable to MitM attack which is exactly what they are trying to protect against with this technique.

How a man in the middle attack works against an online bank. The user communicates with the the phisher, while believing that she is speaking to the bank. The phisher can use deceit to query the user for more information than the bank would normally ask for. Using this additional information, the phisher can communicate with the bank, while pretending to be the user.

I was wondering if using user-agent identification would help against MitM attack.

The idea behind user-agent identification is that it's a secret that is known to the user-agent, like the browser, but it not known to the user. This makes a difference because the user-agent will only send his secret to the real website, while a user might write down his secret to any phishing site.

Example

An example would be to set a cookie to identify the browser via a link sent in an email to that user. When the user access the link, it sets a cookie for the site it wants to log in.

Then, when the user want to log in to that site, the site check if the browser the user is using have that specific cookie.

If he does, then the site show the SiteKey phrase and picture. If he doesn't, then the site ask the user to identify it's browser.

Glossary

  • User : The person trying to access a website. Example : you
  • User-agent : It's the tool that the user use to access a website. Example : a browser
  • User-agent secret : Something that is known by the user-agent, but not necessarily by the user. Example : a cookie
  • User-agent identification : The process by which the website the user is trying to access validate that a specific user-agent is authorized to access this website under that specific username. Example : by validating that a cookie containing a secret code associated to the username is set on that browser

Additional notes

SSL/TLS : Of course you need that since there is no security without it...

Why do we need to set the cookie by an email link?

If you read about SiteKey, you will find out that they are indeed trying to do user-agent identification using a cookie! But they are failing...

Why does BoA allow users to get access to their SiteKey image after answering her security questions? The reason is simple. Normally, BoA knows to present the right SiteKey image to a user because it recognizes the computer that user logs in from as belonging to the user in question. This is done using secure cookies. But what happens if there are no cookies? Say that the user wants to log in to her BoA account from a computer that she has not successfully used to connect to BoA's website with before. Before sending the SiteKey image to the user, BoA will require the user to provide some evidence of her identity - the answers to the security questions. Once BoA receives these, and has verified that they are correct, then it will send the user's SiteKey image to the user. That allows the user to verify that it is really communicating with BoA, and not an impostor, which in turn, provides the user with the security to enter her password.

The problem is that the way to prove the user identity is by asking him a question... The phishing site can then directly ask this question to the user and it's game over.

It's different if the cookie is set by a link in an email. If the website doesn't recognized the broswer, it will send an email to the user. This means that unless the attacker, the phishing site, has access to the user email, he cannot set the cookie hence he cannot impersonate the user.

It's also important that the cookie is set by visiting a link and not by writing a secret code that you receive by email. If you can't trust the user to enter his password on the right site, can you trust him to enter the code on the right site?

Other interesting links

What is this authentication method/approach called?

Is SiteKey a valid defense against Phishing?

Community
  • 1
Gudradain
  • 6,921
  • 2
  • 26
  • 43
  • I don't see how a user-agent string helps in this authentication. It's not secret at all. The problem with SiteKey isn't the client identification it's that attackers can get a hold of the user's legitimate phrase and picture and display it. Tricking the user to input their password. – RoraΖ Aug 19 '14 at 15:04
  • @raz That's exactly the problem that this is trying to fix. Like you said, the problem with SiteKey is that the only requirement to show the picture/phrase is to have the username (and maybe answer a "weak" secret). A user might send his username to a phishing site and then the phishing site can get the picture/phrase from the real site and show it to the user. But, if to show the picture/phrase, you need to have a cookie set in the browser, the phishing site can no longer impersonate you to get the picture/phrase. – Gudradain Aug 19 '14 at 15:19
  • @raz Don't confuse user-agent string with a cookie in the browser. One is public, the user-agent string and the other is private to a specific site. When I said, user-agent secret, I was referring to a cookie. – Gudradain Aug 19 '14 at 15:26

1 Answers1

1

While I'm not 100% sure I follow your question, SiteKeys are designed to prevent phishing as the phishing site will not know the users custom image or the users word/phrase that they have associated with that image.

While user-agent identification does provide some security in certain situations, it really can't provide much security in this instance.

User-Agent verification would be useful, for example, if you're running an application which sends an HTTP request to your server. To confirm that it's your app, you authenticate it with a user-agent that's unique to the application.

Now, based off your comment, I see that you were referring to a cookie when you said user-agent.

What do you do if the bank-customer wants to switch browsers? Or what if they clear their cookies? Now suddenly they can't use the website at all and they don't understand why.

On top of this, why wouldn't the MiTM know the cookie? The cookie is sent within the TCP stream that he's monitoring. So why wouldn't he see the cookie?

Your best protection against a man in the middle attack is to use SSL. SSL will protect you from MiTM if you confirm that there is no SSL stripping occurring. It's impossible to fully prevent someone else from intercepting and reading the transmissions, but SSL will make what they read complete gibberish. Of course you'll still want cookies and cookie verification, but you can consider cookies to be public as well because they're sent with each request.

If you couple SiteKeys with SSL, you've theoretically solved MiTM and phishing.

Spencer D
  • 770
  • 1
  • 5
  • 13
  • To use another browser or if the user reset his cookie, the user will have to get a new email and click on the link to generate a cookie in the new browser. Some applications are already doing that this way. – Gudradain Aug 19 '14 at 16:10
  • He won't know the cookie because if he uses another address for the MitM attack, the browser will not send the cookie as it's bound to another address. If he tries to reuse the same address by creating a false certificate, you need SSL of course, then the browser will warn the user it's an invalid certificate. – Gudradain Aug 19 '14 at 16:12
  • I think two factor authentication is a better solution to the problem than forcing to click a link for unique cookies. – RoraΖ Aug 19 '14 at 16:15
  • MiTM does not necessarily imply the attacker is on a different IP address. An attacker could set up a public wifi-network in a populated area and proxy all requests to record them. In such a case, the cookie is indeed being sent because it's a proxy, not a different website. I agree with @raz, two factor authentication is a much better solution. – Spencer D Aug 19 '14 at 16:17
  • @raz Two factor authentication does NOT protect you against phishing attack. If you enter your password on a phishing site, you will then get asked to enter your code sent by SMS, for example, and when you enter it on the phishing site again the attacker has everything it needs to impersonate you. – Gudradain Aug 19 '14 at 17:21
  • @SpencerGrantDoak Of course you need SSL, there is no web security without SSL/TLS. About 2 factors authentication, read the comment above... – Gudradain Aug 19 '14 at 17:22
  • @Gudradain Good point. But a MitM attack does not imply a different IP address. What's to stop someone from spoofing an IP address? What about NATing? – RoraΖ Aug 19 '14 at 18:14
  • @raz SSL/TLS. The cookies need to be associated to an https address. Sure the attack can try to spoof an https address, but the problem is that he needs to send the right certificate or the browser will raise a warning. If he sends the right certificate then the MitM will not be able to decrypt anything. – Gudradain Aug 19 '14 at 18:19
  • 1
    @Gudradain Interesting proposal overall. Now that I understand the terminology you were using. Only thing you have to watch out for are spoofed emails with illegitimate cookies. I think the clicking a link in an email and writing data to my computer is a bit phishy myself. – RoraΖ Aug 19 '14 at 18:32
  • @raz Sure an attacker might be able to send a fake email, but this email won't be able to create a valid cookie for the website you are trying to log to. The url in the email needs to contain a unique random token. When you visit the link, the website verify the token and give you a cookie if it's a valid token. It's similar to the link that they send you to validate your email address when you create a new account. – Gudradain Aug 19 '14 at 19:23