Hardware Authenticator

Barclays have just issued me with one to do online banking. You have to insert your debit card into the device, and type in its PIN in order to get a token to log onto Barclays website. So the "what you have" is your debit card, and the "what you know" is its PIN.

In addition, you have to generate a different authentication code using yor card+PIN but pressing a different button on the device - presumably using a different algorithm and/or key - whenever you wish to transfer funds to an account you have never transferred to before. The last 4 digits of the account number you want to transfer to is also entered and used to generate the authorisation token.

That prevents fraudsters from spoofing Barclays login screen and passing your login details to the real Barclays site in real time. If they do so, they would get access to your bank statements etc., but would not be able to transfer funds out of your account without the second token.

On Jun 10, 11:15 am, Ronald Raygun

The basic idea is that you shouldn't be able to lose both of them in the same failure.

Something you know plus something you have.

You drop your house keys and don't notice. A random person who finds them cannot use them because they don't know what door they fit.

You drop your wallet that contains something with your address and a receipt showing that you've bought something valuable recently. A random person who finds your wallet can't rob your house because they don't have your key.

Of course, if you keep your address on your keyring or keep your key in your wallet then this breaks down.

Same thing goes for card+pin and why banks are so anti people writing down their pin.

The key/address system is stronger in one way - very few people need to write down their address (although it's probably not that uncommon for people, especially women, to have their keys and something with their address in the same place) but at the same time the card/pin is stronger in another - even if I know you've got lots of money in your account it's going to be difficult for me to steal it without both the card and the pin.

(I typically don't have my address in my wallet. There's enough stuff in there that can enable an honest person to return it too me anyway and I'd rather a dishonest person just took whatever cash was in there and didn't bother me again)

Tim.

Basic ideas are sometimes too simple and thus potentially impracticable. In theory you can't "lose" what you know, although there are two kinds of losing, one being to let it fall into the wrong hands (by divulging, be it deliberately or by accident), which is a security risk, the other being to lose it altogether (by forgetting), which whilst not being a security risk directly, makes the system unusable to anyone with a poor memory, unless they write it down, so it indirectly becomes a security risk.

Quite so, and it's the same with the older problem of keeping your cheque book and cheque card in the same place. For those people who don't use pockets and keep everything in their handbags, keeping them together is the *only* option whenever going out shopping in the expectation of paying by cheque. This being a lot less common now, one would tend to leave the cheque book at home while keeping the card in the handbag.

For those with difficulty remembering several PINs, one option is to make them all the same so that you only need to remember one. I doubt the banks would be too happy about that.

Of course another option might be simply to memorise a number which you need to add to -say- the last four digits of your card to give the PIN. That way you don't need to remember umpteen PINs, here you are combining something you have (the card number which is written on the card) with something you know (the addend) which you can combine by means of a simple algorithm (adding in your head) to give the PIN you need when you want to use the card. :-) The banks would presumably be OK with that.

There is a SecurID client application for Palm computers that can be used in place of a dedicated SecurID token. It requires special setup (loading the key onto the user's Palm) and isn't as secure as the dedicated tokens (Palm can, in principle, be cloned) but it's handy for those who don't want to carry an additional device around.

Note that loading a key into a Palm for use with this application is not a trivial operation, and extracting a key from a dedicated SecurID token would be extremely difficult (and probably not possible without destroying the token) so the existence of the Palm application doesn't weaken the system for those who use dedicated tokens.

Yes and no. The token and password have different risks associated with them, and using both means that an attacker has to obtain both (in different ways) to compromise the account.

Cheers, Daniel.

Let's try to keep the nomenclature clear, shall we? A token is a physical device -- in the case of Barclays's online banking it is the debit card you use (with the PinSentry 'gizmo') to generate an authorization /code/.

Again, it's not a second token, it's a second [level of] authorization code.

SSL protects the connection between your PC and the bank's servers -- that /should/ be enough to prevent a man-in-the-middle attack (and weaknesses in SSL is a topic for a different thread).

Logging into the bank's site with an ID identifies you to the bank, and using some authorization code (whether a password or a one-time value generated by PinSentry) is supposed to prove that you are who you say you are. Using a PinSentry value is more secure than a password because it is one-time, and so can't be copied. There are several reasons for preferring the PinSentry code to a static password -- it prevents "shoulder surfing" (someone looking over your shoulder and seeing what you type), it prevents any successful man-in-the-middle attack from obtaining any password that can be used again, and most importantly of all, it prevents any key-logging malware from picking up a useful password. The benefit here comes from the fact that the PinSentry code is valid for one use only.

Entering the destination account number and the value of the transaction into the PinSentry device when making an online payment also ensures that the authorization code generated is tied to the account and value, so neither can be changed by an attacker without invalidating the code. Because this code is generated in the PinSentry from values entered manually by the user it cannot be compromised by malware on the PC, which seems to be the threat that the banks are responding to by introducing devices like PinSentry.

Cheers, Daniel.

It is indeed a good idea to keep the nomenclature clear, but a bad idea to choose a nomenclature which has confusion built-in. If those who specialise in the narrow field of online banking computer security have decided to use the word "token" to describe the physical device, then this is most unfortunate, since in a wider computing context it has a long-established meaning much more like what you call "code".

It's probably better (less likely to cause confusion) to avoid the word "token" altogether, and instead use either "device" or "code", as the case may be, so that everyone knows what is meant.

Incidentally, the word "key" carries a similar ambiguity, as it can mean both a physical item you use to open a lock, and a piece of information you can use to achieve a similar effect.

Not necessarily in different ways. Much can be achieved with the threat of violence. :-(

Hmmm - you mean you want to *define* the nomeclature. That's fine with me, and maybe online banking has a standard set of definitions all of its own, but be aware that the meaning you are giving the words are completely different to the meanings given them in other contexts

- including cryptography.

SSL is of no use whatsoever against the most commom MITM attack - the phishing site. A user is persuaded to log on to a server masquerading as Barclays bank server. It generates its own SSL session, so the user is none the wiser. Or it may not be encrypted at all - the average user would not notice.

That bogus server connects to the *real* Barclays bank server at the same time the user connects to it, using the normal SSL web connection to Barclays that is available to anyone logging in. It then echos whatever the user enters into the bogus site to the real Barclays site and vice versa. Thus the login will be successful even using a hardware token - but no information can be collected that will allow a login at any time in the future. And because of the second authorisation step needed when transferring funds, the bogus site will not be able to take money from you (but it will be able to examine all your online bank statements and transfer money between your different accounts).

Besides trying to entice people to log in to a bogus server by the usual "Click on this link to verify your account" phishing emails, there is also the method of gaining access to a user's PC via a trojan, and inserting an entry into the "hosts" file containing the URL of Barclays bank and associating it with the bogus server's IP address. The user's PC will then not do the normal DNS lookup when the user types the URL into his browser, but will instead use the IP address from the hosts file with no outward indication that it has done so.

If the user checks the SSL certificate or sees there is none then that should be enough to warn them that the session is not secure.

Checking the SSL certificate again should be sufficient to detect such an attack.

I'm trying not to *define* any nomenclature ... just to keep to the established terminology in this little corner of the industry, in which a 'token' means a "security token".

That's only possible if the phisher has managed to obtain a certificate with a plausible ID from a CA known to the user's browser. It can happens (as it did with the Mountain America thing, a year or two ago) I agree.

That's not really a failing of SSL, it's a failing of the way PKI is used and administered on PCs. Browsers should display the subject ID of a site's certificate when establishing an SSL connection and banks should publicize the subject IDs of the certificates they use to make it easier to check that the site is genuine.

If you're sufficiently knowledgeable and/or paranoid you will inspect the certificate used to secure an SSL connection before you transmit any sensitive data over that connection ... but I agree that most people don't.

Exactly.

Agreed.

True ... but that's just a different vector for the same old MITM attack such as we have already seen can/could in principle be prevented by SSL (if the SSL certificate's subject ID were to be checked).

More worrying is that such a trojan as you describe might be able to insinuate a bogus CA certificate into the PC's certificate store so that the PC would then accept bogus SSL certificates signed by that CA.

Cheers, Daniel.

I would be surprised if as many as 1 person in 10 who use online banking notice whether the web page they are looking at is via an encrypted connection or not - or even what the difference is.

And I'd take a significant bet that no more than 1 person in a hundred who bank online know that there is even such a thing as an "SSL certificate", let alone being able to check them.

Daniel James wrote: ...

Probably because too many organizations tell users to look for the 'little padlock', and that if it's there, they're ok. A rather simplistic view.

Just to throw an extra ingredient into the mix, in the hypothetical case of someone gaining trojanned/hacked access to a victim's PC (following the 'compromised hosts file' leg) there is nothing to guarantee that

IIUIC, once a PC is compromised 'checking the SSL certificate' or for that matter checking *anything* via the display of the compromised machine, becomes a non-event.

Dave J.