On 24 May 2014 20:39, Charles Mills <[email protected]> wrote: > A former employer required a device of slightly better design. It was a > response to a challenge generated by the server (I think; it may have used a > counter in the device, incremented at each login attempt). How is a clock > any better? Or, the protocol could have started by synchronizing the clock. > Within a time bracket, did it generate the same password for all users?
The typical challenge-response token from around 1999 looked like a small pocket calculator (and in many cases could run as one), and had a (single) DES engine in it. It could be programmed with a 32 or 64-bit key. The mainframe-based software would issue a challenge in some fairly convenient numeric or hex format, the user would enter it into the token on the calculator keyboard, the token would display a response on the screen that was the DES encryption of the challenge, also suitably formatted, the user would enter that into the logon screen, the mainframe software would do the same DES encryption, and if the result was the same you were in. Because the algorithms were published, anyone could support these tokens, and indeed we do in our software to this day, and have customers still using them 15 years later. These were unpopular with end-users because of the fiddle of entering arbitrary strings on two very different keyboards, but probably failed more because the business model made money for the token vendors only from the sale price of the token, and the tokens had replaceable batteries and never really wore out. Newer time-based or event-based tokens have a vendor business model that charges for their proprietary validation module, by user or even validation count, as well as for the tokens themselves, and in some cases (RSA) the tokens have a fixed life that is much shorter than the battery life. There are now "open" time and event based tokens (see HOTP etc.) where the vendors again make money only from token sales, and of course "soft" tokens that are just software that runs on the phone everyone now has with them anyway. And any number of vendors have tokens that plug in via USB so you don't have to actually copy response codes from the token to the logon screen. Of course if you trust USB devices in the first place... As in all cases, a threat model is critical, but often not done. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
