Timing attack in Google Keyczar library. An issue I also need to fix in the proposed Django signing code. If you’re comparing two strings in crypto (e.g. seeing if the provided signature matches the expected signature) you need to use a timing independent string comparison function or you risk leaking information. This kind of thing is exactly why I want an audited signing module in Django rather than leaving developers to figure it out on their own.
Sign in with 
OpenID
Actually, this should be exactly why you want a nice Python library that can do this that is *not* part of Django.
Not sure if you noticed a recurring theme in the various replies you got on the Reddit post, but crypto is *very hard* and there will almost always be new vulnerabilities detected in the future. You really don't want that as part of a non-crypto library (Django), because:
1) The crypto lib will need bug and exploit fixes on a more regular basis than Django (and ppl will want *just* the crypto fix and *not* whatever else happened to have gotten into Django during that time.
2) If its not inside Django, it will have a larger audience (all of Python), which will increase the amount of people using it and able to help find/spot bugs in it.
Having it audited just means there's no known security holes *right now*. You can count on there being some not too far off, and are there crypto experts on the Django team that will continue to keep re-auditing the code in the future every single time a new hole is found?
The problem is we already have signing in Django in a couple of places - and we're doing it wrong. My current focus is on sorting that problem out.
I'm not yet convinced that the HMAC+SHA1 subset of crypto is hard enough that it shouldn't ship in Django. I am convinced that the more complex aspects (like key management and rotation) should be solved elsewhere - I'm currently leaning towards an optional dependency on Keyczar for solving those problems.
I'm going to keep on tipping at this windmill for a little longer - I'm not quite ready to give up just yet.
I'm a bit confused, I didn't think Simon was advocating creating a django-specific/brand-new crypto lib but rather to use existing crypto libs to improve Django's cookies using HMAC (Hash-based Message Authentication Code) to sign and authenticate them.
I thought Simon just wanted an audit of his approach to make sure he was using existing crypto properly.
huxley - 4th January 2010 23:07 - #
sigh ... I should refresh the page more often.
huxley - 4th January 2010 23:10 - #
In fact, what I'm trying to do for Django is significantly less complicated (and potentially error prone) than what you're doing in Beaker. I basically just want to ship the equivalent of Beaker's 15 line SignedCookie class, which depends only on the hmac and hashlib libraries shipped in the Python standard library. Beaker has significantly more crypto related code than that one class.
(Beaker's SignedCookie also currently suffers from the same timing attack that has been pointed out in the current Django audit).
At some point, someone has to provide an API to this stuff that regular developers are allowed to use. That, to me, is the whole point of frameworks. That's why I want to do it in Django, and why I think Django should be willing to take on the challenges it entails.
People started talking about this a few months ago and I still don't think it's a serious issue. The research that I've seen where this technique has been used successfully has been on local systems. For example, if you're trying to log in to a system on the command line and can accurately measure the amount of time it takes for you to be denied you may be able to notice the difference in one character of short-circuit string comparison (assuming your passwords aren't hashed).
But there are too many other variables that introduce variance into the response time of a network request, especially when it's going over the Internet.
Mike Malone - 5th January 2010 16:58 - #
Grade A stuff. I'm unqusetoinbaly in your debt.
Destrie - 8th September 2011 21:23 - #