Challenge/Response authentication

[Paul Rubin]

Dale Strickland-Clark <dale at riverhall.NOTHANKS.co.uk> writes:
> I've not done any research into this yet so I could have this
> completely about my ears.
> 
> We need to do some basic authentication to control access to some
> resources through HTTP.

If you mean HTTP Basic authentication, that works by sending the
password as plaintext.  There's also HTTP Digest authentication
which work sort of like the scheme you described, but most browsers
don't support it.

> Can anyone see any holes in this and does anyone have any experience
> of such a scheme? Is there anything we should look out for?

If you mean HTTP Digest auth, the trouble is that most browsers don't
support it, so if you want to control your app with a browser, you're
limited in browser choices.

If you mean a roll-your-own protocol, avoid those if you can.  It's
incredibly easy to make mistakes in protocol design.  For low-security
applications, HTTP Basic is ok.  For medium-to-high security
applications where you need protection against someone sniffing your
network, use HTTP Basic over SSL--that way the authentication headers
get sent over an encrypted channel.  For very high security
applications, use SSL with client certificates, preferably stored on
hardware tokens such as smart cards.

If you really have to code up your own protocol, replace 

> 4. client produces SHA/MD5 digest of random string
> 5. client updates digest with password producing client digest

with: 

 4. client computes SHA/HMAC of random string (use the Python 2.2
    hmac module for that) using password as key

instead of just appending the password to the random string.  That
avoids certain attacks against the hash functions.

I don't see anything else wrong with your protocol, but I may have
missed something.  It's very easy to miss things.  It's almost always
better to use existing, standard, well-tested protocols.