~ubuntu-branches/ubuntu/quantal/openconnect/quantal

« back to all changes in this revision

Viewing changes to README.SecurID

  • Committer: Bazaar Package Importer
  • Author(s): Ross Burton
  • Date: 2009-01-15 13:26:25 UTC
  • Revision ID: james.westby@ubuntu.com-20090115132625-p7a4di5gbq9aevfw
Tags: upstream-0.99
ImportĀ upstreamĀ versionĀ 0.99

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
 
 
2
When it detects that the server is asking for a SecurID token, the
 
3
OpenConnect client will now ask for both tokencode _and_ PIN.
 
4
 
 
5
You can still just enter your tokencode with the PIN already
 
6
incorporated as before, and leave the PIN entry box blank.
 
7
 
 
8
 
 
9
Adding the PIN to a generated tokencode is a simple operation -- we
 
10
just add each digit modulo 10. So a code of 12345678 + PIN 246801
 
11
would give a result of 12581479, for example.
 
12
 
 
13
By entering your PIN into the 'Token View' in the Windows SoftID
 
14
client, you are giving your PIN away to anyone who can see the nice
 
15
big readout of digits both before and after. As so-called "two-factor"
 
16
authentication, it's a complete fig leaf. That's why we now give you
 
17
the option of entering your PIN into the OpenConnect client instead.
 
18
 
 
19
It would be even better if we could script the SecurID token somehow
 
20
so that you don't need to copy and paste that part at all. The Windows
 
21
tool should be scriptable, or the Java one might be a better option.
 
22
 
 
23
The generate_securid_tokencodes() function in securid.c is waiting for
 
24
someone to implement something along those lines.
 
25
 
 
26
Even better would be to just implement SecurID natively -- it
 
27
shouldn't be particularly hard. We already know how the 64-bit tokens
 
28
work: http://seclists.org/bugtraq/2000/Dec/0459.html
 
29
 
 
30
For the 128-bit tokens, they just use a standard AES algorithm instead
 
31
of their own 'speshul' hash. A basic description of it can be found at 
 
32
http://archives.free.net.ph/message/20040426.120338.65a88fc6.en.html
 
33
 
 
34
If we just work out how the input bits are fed into the hash, and work
 
35
out how the token is stored in the file system, then we should be able
 
36
to do that part transparently within the OpenConnect client (or, more
 
37
usefully, in a generic library).
 
38