On Thursday 24 September 2009 18:18:56 Simon Willison wrote:

Can I add some other things I've been worrying about while we're on
the topic?

In other web apps (I think Wordpress?), there have been problems
associated with use of secret keys when the same key is used for
different purposes throughout the application.

Suppose one part of an app signs an e-mail address for the purpose of
an account confirmation link sent in an e-mail.  The user won't be
able to forge the link unless they know HMAC(SECRET_KEY, email).

However, suppose another part of the website allows a user to set
their e-mail address (merely for convenience), and stores it in a
signed cookie.  That means an attacker can now easily get hold of
HMAC(SECRET_KEY, email), and forge the link.

There are many places in Django that use SECRET_KEY.  I'm not
currently aware of any vulnerability, because in most cases the
attacker has only *limited* control over manipulating the message that
is being signed.  But I may have missed some, and without some
systematic method, it would be easy for one place to open up
vulnerabilities for all the others.

So I propose:

 - we review all the Django code involving md5/sha1
 - we switch to HMAC where appropriate
 - we add unique prefixes to the SECRET_KEY for every different
   place it is used.  So for the e-mail confirmation link, we use
   HMAC("email-confirmation" + SECRET_KEY, message)
 - also add the ability to do SECRET_KEY rotation, as Simon
   suggested.  This suggests we want a utility wrapper around hmac
   that looks like hmac(unique_key_prefix, key, message) and handles
   all the above details for us.

The main difficulty is the way this could break compatibility with
existing signed messages, especially persistent ones like those stored
in password files etc.

Luke

--
"Smoking cures weight problems...eventually..." (Steven Wright)

Luke Plant || http://lukeplant.me.uk/