When it detects that the server is asking for a SecurID token, the
OpenConnect client will now ask for both tokencode _and_ PIN.

You can still just enter your tokencode with the PIN already
incorporated as before, and leave the PIN entry box blank.


Adding the PIN to a generated tokencode is a simple operation -- we
just add each digit modulo 10. So a code of 12345678 + PIN 246801
would give a result of 12581479, for example.

By entering your PIN into the 'Token View' in the Windows SoftID
client, you are giving your PIN away to anyone who can see the nice
big readout of digits both before and after. As so-called "two-factor"
authentication, it's a complete fig leaf. That's why we now give you
the option of entering your PIN into the OpenConnect client instead.

It would be even better if we could script the SecurID token somehow
so that you don't need to copy and paste that part at all. The Windows
tool should be scriptable, or the Java one might be a better option.

The generate_securid_tokencodes() function in securid.c is waiting for
someone to implement something along those lines.

Even better would be to just implement SecurID natively -- it
shouldn't be particularly hard. We already know how the 64-bit tokens
work: http://seclists.org/bugtraq/2000/Dec/0459.html

For the 128-bit tokens, they just use a standard AES algorithm instead
of their own 'speshul' hash. A basic description of it can be found at
http://www.velocityreviews.com/forums/t367596-aes-securid-token.html

If we just work out how the input bits are fed into the hash, and work
out how the token is stored in the file system, then we should be able
to do that part transparently within the OpenConnect client (or, more
usefully, in a generic library).