Tuesday, 30 March 2010

Anti-Phishing Sender Verification with GrIDsure

I have tried out GrIDsure with a set of users now to see how easy it was to use. I was using the Windows client 2-factor authentication solution I blogged about here. (If you don't know their product you must read either their website or my other blog post above before reading this post as it won't make a lot of sense otherwise.) It turns out that the users had no problem setting it up and using the login - no training required other than a simple explanation of how it works. Doing this trial reminded me of discussions I had with GrIDsure about their Enterprise version of their product, which is fairly new and has more features being added all the time. One feature that I thought was noteworthy is their anti-phishing verification.

Phishing, as you will know from here, is a big problem and is often spread by obscured links in emails, such as http://www.microsoft.com.phishers.org/, which has absolutely nothing to do with Microsoft, but is just a sub-domain of phishers.org. There are many ways to combat phishing, the best of which is user education and awareness. I have, for a while, thought that a solution similar to that of MasterCard's SecureCode could be applied to many emails and on-screen login pages to verify the sender. If you're not familiar with MasterCard's SecureCode, when you set up your credit card to have SecureCode, you enter a password and a phrase that is personal to you (any phrase so long as you recognise it and someone else wouldn't guess it). When you confirm payment for something you are presented with your phrase on screen and asked to enter three characters from your password. The point is that if you don't see your phrase then it isn't MasterCard, so don't enter your password characters. The problem would be spear-phishing, targeting individual users. In this case you could just copy the phrase and fool the user. However, you can't just attack a batch of users or all MasterCard users, for example.

GrIDsure have done something along the same lines to authenticate the sender of emails and other messages (with their SDK it could be made to do this for any number of situations). What their system does is send you a code which, along with your unique key, generates a particular grid. Only you can generate that grid, as only your devices have that key (devices plural, as this could be a desktop application and on your mobile phone). They then tell you what your PIN is on that grid. The verification is simple; enter the code on your device and read your PIN off the resulting grid, if it matches the one in the email it's valid, otherwise delete the email and ignore it.

This is just a very simple way to verify an email to make sure that it is not a phishing scam. Of course there is one issue - replay attacks. If an attacker copied the code and PIN from the email then they could verify any email to that user. However, this does limit it to spear-phishing individual users rather than a mass blanket phishing attack. This could be reduced if a timestamp were introduced as well, e.g. entering the date as part of the code to generate the grid, reducing the window of opportunity to the same day. I would like to see GrIDsure push this and eliminate replay attacks to help stop people falling for phishing scams. More people need to think about technologies like this to verify their emails - alternatively, they could just digitally sign them all as practically all email clients have the ability to verify a digital signature.

2 comments:

GrIDsure said...

For the mutual authentication tool that you mention, we do have it with a time stamp as part of the solution, which does stop the replay attacks, as you say.

There will always be a way around any security mechanism, they are designed to enable the users to gain access after all, but we are trying to raise our game without compromising the user experience.

GrIDsure said...

For the mutual authentication tool that you mention, we do have it with a time stamp as part of the solution, which does stop the replay attacks, as you say.

There will always be a way around any security mechanism, they are designed to enable the users to gain access after all, but we are trying to raise our game without compromising the user experience.

Post a Comment

Welcome to the RLR UK Blog

This blog is about network and information security issues primarily, but it does stray into other IT related fields, such as web development and anything else that we find interesting.

Tag Cloud

Twitter Updates

    follow me on Twitter

    Purewire Trust