authentication question (security code generation logic)

Question

I have a security number generator device, small enough to go on a key-ring, which has a six digit LCD display and a button. After I have entered my account name and password on an online form, I press the button on the security device and enter the security code number which is displayed.

I get a different number every time I press the button and the number generator has a serial number on the back which I had to input during the account set-up procedure.

I would like to incorporate similar functionality in my website. As far as I understand, these are the main components:

1. Generate a unique N digit aplha-numeric sequence during registration and assign to user (permanently)
2. Allow user to generate an N (or M?) digit aplha-numeric sequence remotely For now, I dont care about the hardware side, I am only interested in knowing how I may choose a suitable algorithm that will allow the user to generate an N (or M?) long aplha-numeric sequence - presumably, using his unique ID as a seed
3. Identify the user from the number generated in step 2 (which decryption method is the most robust to do this?)

I have the following questions:

• Have I identified all the steps required in such an authentication system?, if not please point out what I have missed and why it is important
• What are the most robust encryption/decryption algorithms I can use for steps 1 through 3 (preferably using 64bits)?

Answer 1

Your server has a table of client IDs and keys. Each client also knows its own key.

The server also maintains a counter for each client, initialised to zero. Each client maintains a counter, also initialised to zero.

When the button is pressed on the client, it generates a HMAC of the current counter value, using its key as the HMAC key. It generates an alphanumeric code from the HMAC output and displays that to the user (to send to the server). The client increments its counter value.

When an authentication request is recieved by the server, it repeats the same operations as the client, using the stored key and counter for that client. It compares the alphanumeric code it generated with the one recieved from the client - if they match, the client is authenticated. If they do not match, the server increments its counter for that client and repeats the process, for a small number of repetitions (say, ~10). This allows the server to "catch up" if the client counter has been incremented without contacting the server.

If the counter rolls over to zero, the server should not accept any more authentication requests for that client ID, until it is issued a new key.

There are extensions to this basic protocol: For example, instead of a counter, you can use synchronised clocks on the server and client (with the value changing every N seconds instead of every button press).