Skip to main content

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.

Comments

  1. 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.

    ReplyDelete
  2. 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.

    ReplyDelete

Post a Comment

Popular Posts

Coventry Building Society Grid Card

Coventry Building Society have recently introduced the Grid Card as a simple form of 2-factor authentication. It replaces memorable words in the login process. Now the idea is that you require something you know (i.e. your password) and something you have (i.e. the Grid Card) to log in - 2 things = 2 factors. For more about authentication see this post . How does it work? Very simply is the answer. During the log in process, you will be asked to enter the digits at 3 co-ordinates. For example: c3, d2 and j5 would mean that you enter 5, 6 and 3 (this is the example Coventry give). Is this better than a secret word? Yes, is the short answer. How many people will choose a memorable word that someone close to them could guess? Remember, that this isn't a password as such, it is expected to be a word and a word that means something to the user. The problem is that users cannot remember lots of passwords, so remembering two would be difficult. Also, having two passwords isn't real

Trusteer or no trust 'ere...

...that is the question. Well, I've had more of a look into Trusteer's Rapport, and it seems that my fears were justified. There are many security professionals out there who are claiming that this is 'snake oil' - marketing hype for something that isn't possible. Trusteer's Rapport gives security 'guaranteed' even if your machine is infected with malware according to their marketing department. Now any security professional worth his salt will tell you that this is rubbish and you should run a mile from claims like this. Anyway, I will try to address a few questions I raised in my last post about this. Firstly, I was correct in my assumption that Rapport requires a list of the servers that you wish to communicate with; it contacts a secure DNS server, which has a list already in it. This is how it switches from a phishing site to the legitimate site silently in the background. I have yet to fully investigate the security of this DNS, however, as most

Web Hosting Security Policy & Guidelines

I have seen so many websites hosted and developed insecurely that I have often thought I should write a guide of sorts for those wanting to commission a new website. Now I have have actually been asked to develop a web hosting security policy and a set of guidelines to give to project managers for dissemination to developers and hosting providers. So, I thought I would share some of my advice here. Before I do, though, I have to answer why we need this policy in the first place? There are many types of attack on websites, but these can be broadly categorised as follows: Denial of Service (DoS), Defacement and Data Breaches/Information Stealing. Data breaches and defacements hurt businesses' reputations and customer confidence as well as having direct financial impacts. But surely any hosting provider or solution developer will have these standards in place, yes? Well, in my experience the answer is no. It is true that they are mostly common sense and most providers will conform