San Diego Python Users Group / DjangoSD Meetup
I’ll be giving a talk next month on Securing Your Django Site. See you there!
RPC4Django updates November 2011 edition
I released v0.1.10 of RPC4Django. I fixed an issue so that setup.py has no requirements on anything outside of the standard library and I set the project up such that python setup.py test runs the unit tests.
The bigger change is that I moved the project from Launchpad to Github. I’ve already been using Github quite a bit and I thought that I’d bite the bullet and do the move. While I liked Launchpad, I think it is better suited to larger projects that will use the features like Blueprints and Translations. For a small project like RPC4Django, Github’s code-centric approach works better.
Djangocon 2011 Day Three
I know Djangocon has been over for a week, but I didn’t get a chance to talk about day three and specifically Paul McMillan’s excellent security talk. I also think it’s interesting that Djangocon seems to correlate with security releases (2011, 2010).
Timing attacks
Paul demonstrated a timing attack against password reset: a method that mails a user a one-time link to use to reset their password. This timing attack could guess that link with fewer requests than would be needed to guess that link via brute force — that is, fewer than having to guess all possible combinations. It did so by measuring the difference in the times requests took between requests with more vs. fewer correct characters in the URL. I spoke with Paul and he said that this attack works best locally and would be hard to execute remotely because variability in network latency would be significant enough to make measuring the differences in timing difficult. While this attack is not completely practical, a lot of people use shared or cloud hosting which allow attackers to somewhat mitigate this by setting up attack servers in the same network.
Paul also demonstrated a timing attack which leaked some information about whether a username was valid in the system.
Securing Django in production
Even if Django is completely secure (which nothing truly is), mistakes can be made in deployment. Paul recommended an app called django-secure which checks for common misconfigurations. In addition, he said that the login URL should always be throttled to prevent password guessing. The Django security docs which your humble blogger helped write also recommend that among a number of other things. They are worth a read.
Password issues
I posted a primer about Django passwords last month. Paul had some more things to say about it. Firstly, database dumps/backups and initial data which contain hashed passwords should not be public (for example, on github). As I mentioned in the primer, eight character passwords using Django’s current hashing algorithm (sha1) can be brute forced in a matter of hours in the worst case. So if you accidentally leaked a backup — and a number of high profile sites have done things like this — then consider those passwords broken.
The fix for the password problem is to use a “slower” hashing algorithm designed for hashing passwords. I spoke with Paul after the talk and one of the road blocks to using something like bcrypt is its reliance on C extensions and the Django core team is reluctant to introduce them. However, they are really trying to get something better into the Django core for 1.4.
Miscellaneous
There were a number of other recommendations including:
- Be careful where you store pickled data (cache, /tmp, etc.). Pickled objects can contain executable code.
- Use the proper cryptographic functions available in Django and Python including: random.SystemRandom, django.utils.crypto.constant_time_compare, and django.utils.crypto.salted_hmac
- Be careful when deploying HTTPS to make sure it is done properly
It’s good to hear that security people are going over Django with a fine-toothed comb.
Djangocon 2011 Day Two
I enjoyed some brief time traveling when Jacob showed what Django looked like in 2005 or so. It has come a long way.
OMG APIs
I attended two talks on APIs today: Isaac Kelly’s talk on Tastypie and Tareque Hossain’s talk on the Promises & Lies in REST. Tareque’s talk involved PBS’ use of Piston and the changes that they had to make (presumably because the core has not been updated). It seems like a number of new projects in the Django/REST space have cropped up (on top of Tastypie) such as Django REST framework and dj-webmachine. At last year’s Djangocon, Eric Holscher (I think) mentioned that it seemed like there was agreement on Piston for Django REST interfaces and now the REST community is fragmenting a little and using a variety of different tools and methodologies.
Tareque recommended a number of methodologies in his talk that I would say are not very RESTful such as including the status code in the data (as opposed to just using the HTTP status code), putting the API version in the URL (a good idea but maybe that should be in the header) or putting the desired output format in the URL (.xml, .json, etc) as opposed to in the HTTP header. Perhaps thinking about “not very RESTful” though is not the right way to think about it. In his talk, Isaac said that “Restish is enough” and maybe that is the answer. If you’re doing most of the RESTful things, you’re Doing Things Right. On the other hand, once you say “Restish is enough” you’re basically admitting that everybody does REST differently and that divergence in REST interfaces is going to continue for at least the foreseeable future.
Djangocon 2011 Day One
Real-time Django
I really enjoyed Ben Slavin’s talk on Real-time Django. He shed some good insight on what to cache and when. Essentially, I would summarize it as to cache many things at every level that makes sense. On top of perhaps view level caching, you should cache partial results or really anything that prevents you from hitting your database more than you need. I have been playing with an approach that uses this to cache data from multiple databases in one fast cache. I liked the concept of “continuous caching” where essentially some out-of-band process is caching views or data so that actual requests for views don’t hit the DB.
Choices
I chose to attend Alex Gaynor’s talk on Pypy at Quora rather than Frank Wiles talk on Postgres performance tuning but it was a tough choice. Alex thinks one big strength for Django (from his time at Quora not using it) was that picking up a foreign Django codebase is easy because of all the conventions that virtually all Django apps follow. If you know Django, you can easily tell all the URLs for any Django app (urls.py) or all the forms (forms.py). Unfortunately, the Django admin doesn’t use these conventions. In passing, he also mentioned a project called Johnny Cache which I have to try. I followed some live-blogging on Frank’s talk and it looked like there were some good tidbits.
I was interested by Eric Holscher’s talk on setting up Read the Docs and I really need to spend some time looking at their Chef recipes and learning Chef in general.
If you’re at Djangocon, say hi!