Commit d707fc524 (Clean up auth form handling) removed securid.c and the tokencode+PIN prompts, but the docs and headers still refer to these features. Signed-off-by: Kevin Cernekee <cernekee at gmail.com> --- README.SecurID | 38 -------------------------------------- openconnect-internal.h | 4 ---- 2 files changed, 0 insertions(+), 42 deletions(-) delete mode 100644 README.SecurID diff --git a/README.SecurID b/README.SecurID deleted file mode 100644 index 3f5d115..0000000 --- a/README.SecurID +++ /dev/null @@ -1,38 +0,0 @@ - -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). - diff --git a/openconnect-internal.h b/openconnect-internal.h index be95828..eaf05a7 100644 --- a/openconnect-internal.h +++ b/openconnect-internal.h @@ -398,10 +398,6 @@ int internal_parse_url(char *url, char **res_proto, char **res_host, /* ssl_ui.c */ int set_openssl_ui(void); -/* securid.c */ -int generate_securid_tokencodes(struct openconnect_info *vpninfo); -int add_securid_pin(char *token, char *pin); - /* version.c */ extern const char *openconnect_version_str; -- 1.7.4.1
