Hardware Authenticator

Anthony R. Gold ("Anthony R. Gold" ) gurgled happily, sounding much like they were saying:

They're calculated from a timestamp, so - yes - you do need to have it with you.

Two factor authentication - something I have and something I know.

yes

no

The way they are supposed to work is that you logon to the machine and give it the number on the token along with a password or PIN that you set up.

As you say the number changes every minute so the machine authenticating with the token and the token itself need to have the correct time-stamps.

So it's a litlle more clever than the theory. If you put in the token and there has been a drift in clocks the server does something along the following lines. "ok I think I know who you are, but you need to prove it".

It then asks for you to wait until your token changes and give it the next number in the sequence if that checks then it adjusts the time for your token. I don't mean it changes your token it flags your token as being 3 minute in advance to its own clock (or whatever)

I'm probably getting too detailed now. They're good and I wish my bank would use then for home users to log on. Until they do I'm not going to use home banking.

As Adrian said it's 2 factor authentication

What you are What you know What you have

In this case you have the token and you know your PIN

Equally if could be I am my fingerprint and I know my password

a username and password is single factor authentication - what you know

We had them at BT. You have to use the number 'now', the passcode is generated by a chip in the card based on the time and it's matched against a passcode generated by the 'server' end using the same algorithm at the same time.

Are these devices that some banks were introducing for online account use ...am I correct in thinking that ? Stuart

In message , Anthony R. Gold writes

I use one myself to log on to my work VPN from my home office. It generates a new code constantly (every minute or so) and you must have the latest code whenever you wish to log on. Once logged on, you can stay on as long as you like but in order to log in again after disconnection, you must use the fob again. I wear it on my keying so that I can access my VPN from any location which gives me an Internet connection and no, you cannot write them down and use them later.

Thanks to all for the unanimous advice.

Tony

I just got one from Nationwide. Seems secure in theory. will have to wait and see.

The nationwide thing is a bit different. They give you some numbers and you type these into a "calculator" device that you have put "your" card into. it then give you an answer that allows you to continue.

I put "your" in inverted commas as their Internet Banking has the wrong number for my card. Awaiting a response from them in due course.

So where do you store it for safe keeping?

Down your pants

We've had one at work for about five years; we use it to access one of our client's websites.

SecurID has been around for a LONG time. I first qualified on it in 1997, and it had been around about 10 years then.

Its time based one time usage two factor authentication.

If you want codes that you can "bank" then the system such as SecurEnvoy (ex RSA chaps!) which sends information to your cell phone is about as good as it gets

HTH

Si

Hopefully they won't catch on with all the banks.

I quite like being able to login from anywhere without having to carry an extra piece of chuff around with me.

I use one for accessing a site at work, I put a password in and then the number.

I have implemented such a system before in a previous workplace. The way it works is that the hardware token has a built in secret that is combined with the current time (usually a 60 second floor) in an algorithm that produces the number. The authentication server has a copy of the token's built-in secret ("secure seed") and performs the same calculation. If the two numbers match then the authentication is successful. The system can be tuned to allow entry within a specified period of time around which the code was generated to allow for clock inaccuracies (for example 5 minutes), but you will not be able to use "banked" numbers in the manner you describe. When prompted to authenticate you will need to enter the number currently being displayed. The server will also attempt to perform a synchronisation to account for the drift in the token's internal clock.

I've implemented a few of these, I use them to access my home network from outside in fact.

I couldn't find anything on the RSA page given about "banking" a few.

Chris Hills' description was spot on.

They generate a pseudo random number every minute and the authentication server has a matching set of keys and can verify the given 6 digit number along with your PIN.

Two factor authentication

- what you know (username+PIN)

- what you have (RSA token)

Some banks use a system where you get a gizmo, you type in the PIN on a small keyboard and it generates a token based on the seed in the device+ the time + your PIN (maybe that is the banking link - corrupted a little)

"martin" wrote

Hmmm. Doesn't it reduce to ONE-factor authentication if a fraudster also manages to obtain the "secret" + "algorithm"?

I don't think these use the time. They just keep hashing a seed.

I've read (but not yet tried) that if you write down a few numbers from one of these then you can use them later.

Another test would be to write down four numbers. The next day try the first one - should be ok. Then try the fourth one - should be ok. Then try the 2nd or 3rd - both should then fail.

Using the time would be a weakness - I could have a device that tells the card the wrong time and then with just temporary access to your card I can then get a value to use in the future and there's nothing you can do to disable that future value. With the current scheme, if you think I might have had access to your card to generate one of these numbers, you can just use your card to logon to your bank and then my number will have expired because it's older than the most recent number the bank has seen.

The SecurID doesn't have this problem because it has an internal power source and it knows the current time so there's no ability to spoof the time.

Tim.

There is no reason the algorithm shouldn't be published, the security of modern crypto systems lies in the keys, in fact if the algorithm isn't published it should make people look twice at what is being claimed. How is the third party going to retrieve the key? That's the problem with all crypto systems, once the keys are compromised then you no longer have security.

It's a good question though. There is a requirement for the end user to notify the security manager should a token go missing so the keys can be revoked, the only place keys could be compromised is at RSA themselves, in transit, or the end user site. Anyone implementing two factor authentication knows they have to take measures to look after their keys and keep them locked up.