In light of the LinkedIn password leak, I wonder how do you store our passwords?
2 Likes
I like salt in my soup. Also in my passwords. (+1 to spend half an hour thinking about login best practices)
Can’t speak for Samuel, but it looks like NewsBlur runs on Django and uses the built-in (django.contrib.auth) authentication mechanisms.
Not sure what version of Django runs NewsBlur, but versions through 1.3 use a salt+hash (sha1 by default, md5 fallback for backward-compatibility with old versions of Django; doc, source) and Django 1.4+ has pluggable mechanisms (and uses PBKDF2+SHA256 by default; doc).
Django also uses a “constant_time_compare”. If you’re really security conscious, this prevents against timing attacks (things that take advantage of the fact that "abaaaaaaaaaaaa"=="aaaaaaaaaaaaaa" is faster than "aaaaaaaaaaaaab"=="aaaaaaaaaaaaaa" because programming languages optimize these for fast comparisons).
Provided I’m not totally off-base in making these assumptions (“NewsBlur uses Django and django.contrib.auth”), passwords here should be relatively secure (against rainbow tables) even if that auth_users table ends up in the wrong hands.
(Naturally this doesn’t preclude brute forcing a password once you have the salt and hash representation, but that process will be significantly slower, especially if the hash was generated with PBKDF2. The Django 1.4 PBKDF2 loop currently uses 10,000 iterations – and Django devs claim that it takes about 100ms per password checked on a 2.2GHz Core 2 Duo. AND, this value will be automatically upgraded in future versions of Django as better CPUs become more prevalent.)
2 Likes
Of course, to make it really secure against attacks, you can chose not to use a password at all 
Mike Tigas is absolutely right. I’m using off-the-shelf components in Django to perform password encryption. Additionally, I’m using salts (as is the default), so rainbow tables aren’t useful.
1 Like