Search blog.co.uk

About me

tibbar

tibbar

Calendar

<<  <  October 2008  >  >>
Mo Tu We Th Fr Sa Su
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

Last comments

Two way authentication to defeat Phishing

by tibbar @ 2006-02-14 - 03:11:12

Phishing is becoming an increasingly big problem on the net. For those of you who are not familiar with the term, Wikipedia defines it as:

In computing, phishing is a form of social engineering, characterized by attempts to fraudulently acquire sensitive information, such as passwords and credit card details, by masquerading as a trustworthy person or business in an apparently official electronic communication, such as an email or an instant message.

When the end user receives an email that for all purposes appears genuine and appears to originate from a trusted source, the psychological effect is to lower the levels of suspicion the user would normally have, when asked to provide sensitive information.

There really is very little we can do to stop Phishers from making carbon copies of websites, spoofing email addresses and even buying ssl certificates to make their site appear more genuine.

The underlying problem here is the way authentication is performed on the internet. When we are dealing with financial services such as internet banking, we currently have a one-way authentication process - the customer is required to prove to the internet site, that she is the legitimate owner of a bank account. This authentication is normally performed through providing a password and perhaps a date of birth.

However, this is really only half the story...

Let us consider an analogous situation in real life. The bank's customer decides she would like to withdraw some cash from her bank. So she visits the branch, identifies herself with a driving license, provides her account details and is successfully served by the branch.

She feels perfectly safe because she knows the bank's branch is genuine and the people working there are to be trusted.

The act of "phishing" does not exist when making physical financial transactions by visiting your bank's branch. Why? Because the economic cost of setting up a fake branch of a bank, employing fake staff is too high, and the risk of being arrested by the police is also very high.

The big problem is that on the internet, the economic cost and risk factors are very low. Any skilled web developer could setup a fake site in a matter of days.

We therefore need a mechanism by which the bank's customer can be assured that the website she is visiting is genuine, and is not being redirected to a phishing site.

This mechanism is very simple: two way authentication. As part of the login process to all internet banks, once the customer has provided part of their password (e.g. 1st, 3rd and last character), the bank's site will provide the customer with a "fact" about them (e.g. your cat is called Garfield). If this information is incorrect or is not provided, the customer knows that the internet site is not genuine and can immmediately terminate the login process, thus safeguarding their account information.

A detailed example of this login process could be formed using two passwords and a "fact" about the user:

1) Bank requests internet banking ID and first password;
2) If first password is correct, bank provide key "fact" to user (e.g. your cat is called garfield).
3) User checks if the "fact" is correct and either leaves the site if it is wrong / missing. If it is ok, then the user clicks proceed.
4) Bank asks for second password, if correct then authentication is complete.

If all financial institutions adopted this login procedure, phishing could be eliminated within the banking sector.


 
 

Trackback address for this post:

authimage

Comments, Trackbacks: Hide subcomments

Alex [Visitor]

14/02/06 @ 07:12

I think that the system will only weed out incompetant phishers, for the folloowing reason:

Lets say the user goes to the phishing site and provide their User ID and first password, the phishing page then opens up a socket to the official site, gives them the proper details, then gets the fact form the actual site, and provides it to the user, then the user provides their second password, and the phishing site wins.

I think that if your users are willing to give their data to anyone who looks official, you've got a serious problem, and education is still the key (though having pages signed with some private key to which the browser has the embeded public key, and so can do the check itself and can tell the user when they are on the real site, but thats another issue completely)

Essentially what I wanted to say is that the idea isn't going to do much more than raise the bar to get into phishing.....

tibbartibbar [Member]
14/02/06 @ 09:45

Alex, you have made a very good point.

The bank could reduce this risk by keeping a counter on the number of accounts accessed per ip address, and block and ip that tries to access say more than 3 accounts in a 5 day period.

Of course, the phisher could use a rotating proxy list to get around this...

Brad [Visitor]

18/02/06 @ 01:09

First and most importantly, the bank must provide a brief description of it's security mechanism to the customer. If the customer isn't aware, then no phishing scam can be avoided.

I like your idea, but here is a more complicated and perfected solution:

The phishing site is going to have to manipulate the bank's authentication to fool the customer, but this can be avoided from current scripts using a dynamic captcha and keywords. The customer would be aware of a few keywords and responses. The captcha would generate unrelated content, and then at a random interval display it's authentication keyword. From that point, the user would enter their response. As long as the phishing site can't manipulate the dynamic captcha, through the use of sessions and Java, then this would be nearly impossible to copy. The only way the phishing site could bypass this is by creating an identical dynamic captcha and targeting specific users, but using other tools the bank could control how many times a day the dynamic captcha could be displayed without a successful logon.

Yorn [Visitor]
http://yorn.wordpress.com
14/02/06 @ 23:44

Actually, you hit on a good point, Alex, but it's still one that is worthy of being tested because it provides yet another mechanism for protecting the end user and increases the cost of phishing for the phisher.

This could be expanded to transferring large image files with 4 sentences typed out and the user would be required to choose which one is true. If they didn't see a true statement, their bank could grill into them that they should leave the site. This could even be done before the user types in their password.

A modem user would have to wait an extra minute or two for the images to load, but the phisher themselves would be required to provide both download (from the bank) and upload (to the client) services. This drastically would affect their cost of business.

Alex [Visitor]

15/02/06 @ 07:20

Ok, sure, I can easily agree that something like this will definately make it harder for phishers, but not by much I think.

The idea about using a large image, where there are 4 sentances and getting a user to select one would be just another verification of the user and since we're want the bank ot authenticate itself I think that it would be pointless in this case.

The idea of using an image is an interesting one, but if they are getting bank account details I don't think bandwidth would be an issue. And the banmks would also have to fork out money for bandwidth themselves, and considering banks recieve much more traffic than phisher, and unless they want to keep using the same old image (which would provide very limited security, since if you can perform 4 guesses.....) they are going to have ot generate a new image every time, or if they use static (or even semi-static) images then they are going to use quite a bit of disk space, so with that many downsides for the bank, I don't think they'd like the idea.

I also think that while having something like that might help, I don't think it should be personal details, because you don't want people to have access to that, especially without a password as you suggested (sure 3 of 4 are wrong, but if you can do 3 attempts over a couple of days...).

I'll just say that while I think we need some kind of mechanism for sites to authenticate themselves, this isn't it.

tibbartibbar [Member]
15/02/06 @ 23:58

Ah well, it seemed like a good idea at the time.

I still feel that authentication to defeat phishers must be a two-way process - it's no longer the case that only the bank must be convinced you are who you say you are: the user needs to be convinced the bank site is genuine too.

But as you say Alex, if the phisher can act as a man in the middle and relay the bank's attempt to authenticate back to the user, then the situation becomes even worse than it currently is - the user will be even more convined the site in genuine!!!

Tibbar.

paradox [Visitor]

16/02/06 @ 03:04

I suggest a ssh type signature..
You sign onto the bank the first time you get a signature.. then if it requests another signature you know its a fraudulent host.. But social engineering can always trick those not security inclined.. and the fact that those who are security aware already know phishing techiques.. it is a matter of teaching

Leave a comment :

Your email address will not be displayed on this site.
Your URL will be displayed.
Allowed XHTML tags: <!, p, ul, ol, li, dl, dt, dd, address, blockquote, ins, del, a, span, bdo, br, em, strong, dfn, code, samp, kdb, var, cite, abbr, acronym, q, sub, sup, tt, i, b, big, small, img>
URLs, email, AIM and ICQs will be converted automatically.
Options:
 
(Line breaks become <br />)
(Set cookies for name, email & url)
All comments on this blog will be moderated by the author.
Validation code:
Please enter the above code here:
For protection from spambots (case-sensitive).

Recent Posts

  1. Reflecting on better times
    by tibbar on 2008-07-21
  2. CodeCrypter 1 Year On
    by tibbar on 2006-12-26
  3. Hooking drivers
    by tibbar on 2006-12-22
  4. linux server framework
    by tibbar on 2006-10-19
  5. ReactOS
    by tibbar on 2006-07-15
  6. update
    by tibbar on 2006-06-18
  7. What comes next?
    by tibbar on 2006-04-11
  8. Kernel Mode Ircbot
    by tibbar on 2006-04-06
  9. codeCrypter next release plans
    by tibbar on 2006-03-31
  10. jotti scan
    by tibbar on 2006-03-23

Footer

The content of this website belongs to a private person, blog.co.uk is not responsible for the content of this website.