PyOTP implements the RFC2289 (previously RFC1938) standard for One-Time Passwords (OTP) in Python. From the abstract of the standard:
This document describes a one-time password authentication system (OTP). The system provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. OTP evolved from the S/KEY (S/KEY is a trademark of Bellcore) One-Time Password System that was released by Bellcore [...]
[18 July 2001 03:48 from Sydney, Australia]
Whoa. long teleconference. Ugh.
New branches! Rkludge is the original one. Rrefactor is where I'm doing the re-organisation work.
[17 July 2001 15:08 from Sydney, Australia]
No activity for almost a month. Sorry. My bad.
I've added Crispin Harris to the project. He's an old mate of mine and a professional security boffin.
I still haven't found any sample input or output for Appendix B dictionaries.
[25 June 2001 8:54am from Sydney, Australia]
I'm about to re-organise the module. If you need OTP in Python, grab the current tag from the CVS repository and go for it -- otp.generate works just fine. If you can wait a week or two, send me mail (gtk-at-sourceforge.net) to let me know you're there and I'll let you know when I finish mucking around.
Speaking of which, if anyone wants to comment or lend a hand, I'd much appreciate it.
I've played with Appendix B dictionary generation, and having based one on the German dictionary supplied with Crack 5.0a I'm afraid to report that when using the folded hash functions the smallest words in the dictionaries are... well, not that small. To compensate, I'm thinking of adding a non-compliant three word key format.
A three word key format won't be as strong as the six word format. On the other hand, the words in your dictionary are eight to ten characters long and you insist upon all six of them, users will become frustrated, and frustrated users tend to opt for less frustrating and weaker-still authentication mechanisms. Offering a three word key format (and making it optional) seems like a decent compromise.
Note to self: make it the last three words, so you get the checksum bits.
The PyOTP Project Page at SourceForge has as many details as you'll find. If you need to know more, send email to the author as gtk- at-sourceforge.net.
The otp module strictly adheres to all absolute requirements of RFC2289 as tagged by the word MUST in the document except those specifically excluded in Exceptions below, and adheres to most recommendations and options.
Specific details of the otp module's handling of RFC2289 recommendations (marked SHOULD) and optional parts of the standard (marked MAY) are provided below:
5.0 SECURE HASH FUNCTION
All conforming implementations of both server and generators MUST support MD5. They SHOULD support SHA and MAY also support MD4.
The otp module supports both MD5 and SHA as secure hash functions, as both are supplied as part of the Python 2.0 distribution. MD4 support might be added in future releases if sufficient demand exists.
6.0 GENERATION OF ONE-TIME PASSWORDS
To reduce the risk from techniques such as exhaustive search or dictionary attacks, character string pass-phrases MUST contain at least 10 characters (see Form of Inputs below). All implementations MUST support a pass-phrases of at least 63 characters.
Implementations MAY support a longer pass-phrase, but such implementations risk the loss of interchangeability with implementations supporting only the minimum.
The otp module supports pass-phrases of between 10 and 63 characters, inclusive.
The seed is a string of characters that MUST not contain any blanks and SHOULD consist of strictly alphanumeric characters from the ISO-646 Invariant Code Set.
The otp module generates seeds composed only from characters present in string.letters and string.digits. That said, I suspect that users are supposed to choose their own seed and that the otp module's role is limited only to making sure that the user specified a valid seed.
The one-time password therefore MAY be converted to, and all servers MUST be capable of accepting it as, a sequence of six short (1 to 4 letter) easily typed words that only use characters from ISO-646 IVCS.
The otp key generator can generate either hexadecimal or RFC2289 short-word key sequences.
In addition to accepting six-word and hexadecimal encodings of the 64 bit one-time password, servers SHOULD accept the alternate dictionary encoding described in Appendix B.
The otp module does not by itself provide authentication services, and so cannot by itself ensure adherence to the following parts of the standard:
8.0 PASS-PHRASE CHANGES
Installations SHOULD discourage any operation that sends the secret pass-phrase over a network in clear-text as such practice defeats the concept of a one-time password.
9.0 PROTECTION AGAINST RACE ATTACK
All conforming server implementations MUST protect against the race condition described in this section. A defense against this attack is outlined; implementations MAY use this approach or MAY select an alternative defense.
Adherence to these sections of the document is left to the implementer of the authentication services.