PyOTP - Python One Time Passwords

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 [...]

Latest Author Notes

[18 July 2001 03:48 from Sydney, Australia]

[17 July 2001 15:08 from Sydney, Australia]

[25 June 2001 8:54am from Sydney, Australia]

Project Location

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-

RFC2289 Standards Adherence

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: 


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.


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: 


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.


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. 

Other Resources