Tuesday, 30 March 2010
Anti-Phishing Sender Verification with GrIDsure
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.
Wednesday, 17 February 2010
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 really any different from having a longer, stronger password, it's still single-factor.
The idea behind the Grid Card is that you have a set of random numbers shared between you and the bank that are very hard to guess. I only say very hard to guess because I don't know how they generate the cards in the first place and if this isn't truly random - which it almost certainly won't be - then you can predict parts of the grid given other parts of it. Randomness is a rare but essential commodity. There are 50 co-ordinates on the card and Coventry ask for 3 each time, giving 19,600 possible combinations, assuming they'll never ask for the same co-ordinate more than once per login (order doesn't matter as we're told which grid squares). Does this mean that someone would have to log all 19,600 combinations before they could regenerate the card? No. Each co-ordinate appears 1,176 times in the 19,600. Each pair of co-ordinates appears 48 times. There are only really 17 unique combinations of co-ordinates such that they aren't repeated (and that's a cheat, because one co-ordinate will appear twice if we have 17 as 17x3=51). However, it is unlikely that these 17 would get asked for in succession, so it would take significantly more observations before we have the whole grid, but we won't need the whole grid before we're very likely to be able to login. Indeed, there's a 17.3% chance that at least one co-ordinate will be repeated on the next login. Also, a shoulder surfer with camera phone (or CCTV cameras) could take a photo of the whole card in one go, so this is an authentication mechanism to be used only in the 'safety' of your own home.
This is, however, a step in the right direction, so they should be commended for it. What else do you need to login to Coventry? Well, a Web ID and date of birth, both of which are easily pharmed. So the security is based solely on the password and Grid Card, which is better than two passwords. They do also have an anti-phishing technique bundled in there as well. When you sign up you choose a picture that they will display during your login along with your last login date and time. If the picture or date is incorrect then this isn't Coventry (or your account has been compromised). It's good to add a picture here, because many people don't actually check the last login date and time even if it's put up on the screen. The picture is obvious and hard to miss though. These mechanisms don't really stop spear phishing (or targeted phishing), but they do stop blanket or mass phishing attacks.
It's about time more banks started issuing 2-factor authentication for login and Coventry should be congratulated on being amongst the first. However, we have to be careful about how it's implemented.
Wednesday, 28 October 2009
PhoneFactor Security
I was also told that the PSTN and GSM networks are secure, so this is a good solution. I'm not sure I agree that PSTN and GSM networks have good security. Analogue PSTN is easy to listen in to with proximity and GSM can theoretically be cracked, and probably will be within 6 to 12 months. So that PIN number isn't really secure. Plus there is the cloned SIM card problem as well.
http://www.mobileindustryreview.com/2009/08/gsm-encryption-can-be-cracked-for-500.html
Having said that, PhoneFactor looks quite good as you enter the PIN on the phone line, not the login dialogue. The problem that Bruce Schneier has referred to is that of a Man-in-the-Middle attack. Most 2-factor authentication methods are susceptible to a MITM attack, including RSA tokens and other hardware tokens. Basically, if I set up a website, for example, to mimic your corporate portal, then you will enter all your details into my page, including your one-time pass code. I will forward them on to the real portal and do whatever I like logged in as you.The one advantage is that I have to intercept every login attempt, and wait for you to login before I can gain access. Without a 2-factor system, once I've read your username/password combination I can login whenever I like. PhoneFactor would appear to mitigate some of this risk by doing the authentication out of band. However, there is still an attack vector for a MITM attack. In the same way as before, you login to my portal, I forward your credentials, PhoneFactor phone you and you put in your PIN, they enable my session! Obviously, there are other attack vectors as well.
Another potential issue is that you are charged for the phone calls made by PhoneFactor on your behalf. These can be significant costs. In the UK calls to landlines are free, but am I always at my desk when I want to log in? No, I'd want it on my mobile; that will cost me $0.23 per login (East Timor $3.25). So, I could rack up the bill for you company by getting them to call through to someone. If I do this enough times (especially if that person is on holiday in another country with higher charges) I can use up all your credit and none of your users can login.
There is a privacy issue as well. PhoneFactor will know every time you log in or access your bank, etc. How do they protect that data? Do you want them to know that information, even if you do trust they won't accidentally disclose it?
However, I am not against 2-factor authentication. Indeed I think it is a good thing, as users will choose poor passwords, reuse them everywhere and write them down. Similarly, they will give them away to phishing scams. 2-factor authentication removes all of those problems, but by no means is it absolutely secure. PhoneFactor seems OK, but it's not particularly cheap or phenomenally secure. There are some other good software solutions that are pretty cheap as well, and that can combat shoulder-surfing when entering PIN numbers, etc. There are a couple of examples on a blog post I did a couple of months ago: http://blog.rlr-uk.com/2009/06/user-friendly-multi-factor.html
The bottom line is that they are more secure than username/password, but none of them are absolutely secure against all attacks.
Wednesday, 3 June 2009
User-Friendly Multi-Factor Authentication with GrIDsure
A trawl round the InfoSecurity Europe show always helps, as you can get the latest state of play from all the major vendors. This year there were the obvious keyring tokens, SmartCards, USB tokens, SMS solutions and some innovative software solutions, including GrIDsure. Before making any decisions about the solution to go for, several things need to be decided, among which are: how much security is required? What is considered user-friendly to a normal, non-technical user? What metrics should we use for authentication?
To answer these we need to look at what authentication is first: Authentication is the binding of an identity to a subject. The subjects we're talking about in this case are users and we're trying to bind their digital identity, i.e. user ID, to them as an individual. There are four metrics we can use to query identity, namely:
- What they know - e.g. password, PIN, secret/personal information, etc.
- What they have - e.g. token, SmartCard, phone, etc.
- What they are - i.e. biometrics
- Where they are (in space and time) - e.g. particular terminal, logon hours, etc.
The most common form of authentication is username/password, but this is outdated, insecure and, usually, fairly easily cracked (but that's another post). The problem is that each of these on their own is not very secure (yes, even biometrics are not that secure used on their own in a large environment). If we use a combination then we can obtain secure, strong authentication (by strong authentication we mean that we are sure about the identity of this subject as it would be very hard to have all the required metrics otherwise). RSA-type tokens and SmartCards combined with a PIN or password are easy and obvious choices to deploy, but they have issues. They are expensive to deploy, as you have hardware costs as well as the authentication servers. From a user perspective, they have to carry round something else with them. That's not usually too much of a problem, as these are small devices or credit-cards, but you have to have a reader for a SmartCard. Lost or damaged hardware (or tokens that have run out of battery) have to be replaced at a cost.
OK, so we could use SMS, whereby a text message is received by the user containing a one-time password. This is often done by sending one on-demand to the user when they start the login process. What if the network is down? What if there are delays on the network? Well, we can deliver the password up front, i.e. when they log off we can send them the password to use next time they want to login, but then it's hanging around on their phone, which they might lose. So what's the solution? Well, I saw two products that are noteworthy: Swivel Authentication Solutions and GrIDsure.
Swivel's solution relies on either secure SMS or a Turing image (one that is human-readable but not computer-readable). The Turing image will show two rows of numbers, the first is 0 to 9 and the second is the numbers in a random order. The idea is that you have a PIN number that you remember and you read off a one-time PIN from the image. So, if your PIN was 2468 then your one-time PIN for this login attempt would be 7193 from the image below. If someone uses a keylogger, then it will be defeated by this, as that PIN won't be valid next time and it hasn't revealed the base PIN number that you remember. However, if someone uses keylogger and screen capture malware, then it could be read off and deduced - possibly a big ask. However, you could shoulder-surf the pattern as well. That being said, this is very easy to deploy and relatively cheap. Users find it fairly simple to use as well, and it has to be better than a static PIN.
However, there is another solution - GrIDsure. With GrIDsure, you choose a pattern on a grid to remember. The grid size and pattern length is configurable, but the standard is to have a four square pattern on a 5x5 grid. You remember this pattern and then, when you attempt to login, you will be presented with a 'random' grid of numbers. You then read off the numbers in your pattern. For example, if your pattern is the tick that GrIDsure use as their demo and you are presented with the grid shown below, then your one-time PIN number would be 0649. This would change every time you log in. This now defeats keyloggers and shoulder surfing, as each digit will appear more than once. So, even if you see or log the grid and someone typing 0649, there are 81 patterns that would result in this PIN on the grid shown below. It is important to remember that you do not type or click the grid. The grid is just an image; you type the PIN in on a standard keypad.
This can be made more secure by deploying the grid on your mobile phone as a Java applet rather than in the web page, thus defeating screen capture. The grids, in this instance, are seeded from the phone's unique ID, so someone else has to have your actual phone, not just the applet running on their phone. This is true multi-factor authentication, as it requires the physical phone and a pattern that the user knows, without both you cannot authenticate. Also, this is a cheap to deploy solution as most users will already have a mobile phone, and those that don't can drop back onto the single-factor one-time passcode by displaying the grid in a browser. Users also find this very simple to use, as many people already remember their PIN numbers as a pattern anyway. This also 'plays nicely' with other authentication, i.e. you can still use username and password for some users and GrIDsure for others as the desktop client accepts both. Similarly, the web portal is able to interface with virtually any web-based application as a single-sign-on solution. Of course existing users can still hit the services direct and use traditional authentication until this has been deployed to all.

