Twisted: learning about Cred and Basic/Digest Authentication

One of Twisted’s best features is it’s credentials plug-in architecture.  Twisted abstracts the notion of username/password across many different protocols and password-protection schemes.  By abstracting the idea of “credentials” it is possible to implement one password checking facility and use it to protect both FTP and HTTP logins.  Twisted has a deep class hierarchy and a fairly significant learning curve however, so it’s difficult to get your head around some of the concepts until you dive in.

Twisted Matrix Labs

This article will share a little bit of what I’ve learned recently using Twisted.  I’ll show how to implement simple password protection of a static web resource using Basic and Digest auth schemes, and I’ll show an example that doesn’t quite work!  Then I’ll explain what is wrong with that example and fix it. The code snippets shown are complete programs that may be a good starting point for experimenting further.

Password Dictionary

The first example implements a password dictionary checker for a simple web site protected with Basic Auth.  The PasswordDictChecker class implements the interface “ICredentialsChecker.”  Checking a credential is performed by the method requestAvatarId: if the password given matches the password sent, then the username is returned, otherwise, the lookup fails.

Our HTTP Realm (class HttpPasswordRealm) maps authenticated users to resources. In our case, there is only one resource and it is fixed: self.myresource. Any authenticated user receives the same fixed resource regardless of their username.

Our web resource is a simple static example. We render the last part of the path as part of the page.

Our main program stitches all of the pieces together. We mount our resource at http://localhost:8081/example/foo, and it is protected by the passwords in the dictionary. Run this program and try it out. Any of the three passwords will get you to the same resource.

Incorrectly extending our First example to Digest Authentication

In the next example, we substitute a DigestCredentialFactory using md5 encryption for our BasicCredentialFactory of the first example.  This seems to be a straightforward substitution: instead of using the Basic auth scheme, I want Twisted to use the Digest auth scheme with the same password dictionary.  Unfortunately, this program does not allow access to the resource. It was not entirely obvious to me why not. If you run this, you will see that no matter what passwords you type, you are not granted access.  Twisted doesn’t complain, but it does deny you access to the resource.

For a while I believed that there was a problem with Twisted.  There was not: there was a problem with my understanding of the cred system. Our class PasswordDictChecker implements the interface for checkers.ICredentialsChecker – a credentials checker.  What I didn’t get my head around at first was the sub-interface specification.  Our first PasswordDict says that the “credentialsInterfaces” that it implements are only for credentials.IUsernamePassword. What I observed was that the code for requestAvatarId wasn’t even called in this case.  It turned out that the interface specification resulted in the credentials being rejected even before password comparison was being performed.

Upon further research I understood that the Digest authentication method did not supply credentials of the type IUsernamePassword. Instead, it supplies credentials of the type IUsernameHashedPassword. Because this “type” is not in the list of credentialInterfaces, the authentication machinery cannot find a checker for our Digest authentication scheme, and all logins fail.

Digest Authentication

Extending our example to Digest auth involves – adding credentials.IUsernameHashedPassword to the list of credentialInterfaces – abstracting password checking from the equals operator to using the checkPassword method In the example below, we’ve abstracted our simple password dictionary checker to one that abstracts to two types of credentials interfaces and uses the method call “checkPassword” to verify password validity.  This password checker is versatile enough to be used with both Basic and Digest authentication.  (It is also flexible enough to use with other protocols, such as FTP.) As a matter of fact, this password checker is essentially the same as one bundled with Twisted that is appropriately called: twisted.cred.InMemoryUsernamePasswordDatabaseDontUse.
(Do not use it because in-memory passwords can be a security hole.)


This article shows a straightforward implementation of password checker that authenticates against an in-memory dictionary. It used this checker with HTTP Basic auth, and then attempted to use the same checker with HTTP Digest auth. Using the abstraction facilities of the Twisted Cred system, we finally implemented a dictionary password checker that was compatible with either Basic or Digest auth.

5 thoughts on “Twisted: learning about Cred and Basic/Digest Authentication”

  1. Brilliant! Thanks for your effort.

    But the last scheme you demonstrated requires(?) the passwords be stored plainly without hashing, which is poison.. What is the twisted.web way of using digest auth and passwords stored after hashing. Is it possible to get what user entered than we expose what is in the DB?

  2. I think you’re on the right track and that is a good question. I believe that there is a way to avoid storing passwords in plain text with other checkers in the Cred system. Unfortunately, I’m not the one to ask.

    Perhaps someone else can help explain that here? Or provide a link.
    Best – T

  3. Hi,
    The server is running and I couldn’t test the login. Kindly tell how to test login using curl/telnet.

Leave a Reply

Your email address will not be published. Required fields are marked *