Re: Pluggable encryption for django auth (design proposal)

[Jeff Balogh]

On Mon, Feb 21, 2011 at 9:26 AM, Jacob Kaplan-Moss  wrote:
> On Mon, Feb 21, 2011 at 3:23 PM, poswald  wrote:
>> Russ, Carl, thanks for your feedback. Russ, I understand what you say
>> about not wanting to adopt crypto code because of the additional
>> responsibility. Unfortunately, there aren't very good options. Django
>> contrib.auth already makes the recommendation of SHA1 which we all
>> agree is less than ideal. There is simply no acceptable choice in the
>> python standard library. I also agree with Carl that PBKDF2 is
>> probably the most conservative option that qualifies as sufficient.
>
> I've been desperately trying to get up to speed on this stuff over the
> past few weeks. Crypto's very far from my strong suit, but I think I
> know enough now to agree. It seems to me we need two things:
>
> 1. A new, updated default for Django's password hashing. PBKDF2,
> perhaps, but whatever as long as it meets some basic requirements.
> 2. A mechanism to make swapping this hashing algorithm out easy(-ier).
> Again, details don't matter, requirements do.
>
> #1's a blocker for 1.4, I think, but if for some reason #2 can't be
> figured out I think it's ok to punt there for a bit longer. Ideally
> though they'd both go in at once.
>
> Now, I want to make very explicit my requirements here since we've
> gone 'round on this one a few times, so I'll lay out exactly what I'm
> going to want to see to get on board with any proposal. So:
>
> Requirements for a new password hash:
> * As little crypto code in Django as possible. We're not security
> experts, and we shouldn't try to be. Ideally would be something that
> leaves all of the dangerous parts to the stdlib. Perhaps we relax our
> dependency policy (we need to some day, I think, but that's a bigger
> argument maybe we shouldn't have now).
> * Any code we distribute gets audited by people who know what they're
> talking about.
> * Those people have reputations sufficient to convince me (or other
> core devs) that they know what they're doing. This is sorta a "who
> watches the watchers" moment, but we can't just trust someone who says
> they're a crypto expert; we have to believe them, too.

At Mozilla we've been trying to work out our ideal password storage
scheme for a little while. Spoiler alert: it doesn't involve bcrypt.

There's no code yet, but we have a little bit of documentation here:
https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Password_Storage.
This is the outline:

1. sha512 hashing
2. Per-user salt stored with the hashed password
3. Private system salt stored outside the database
4. The system salt can be deprecated if it gets leaked
5. Required minimum password length
6. Common passwords are blocked
7. Migrations towards more security are possible as long as you have
code to unwrap the migration

I've cc'd Michael Coates (our security guy) since he can provide more
background on why we're moving towards this strategy. Basically, if
people are using weak passwords, switching hashing schemes is not
going to provide much more protection. If it takes 0.3 seconds to
encrypt "pa$$word" then it took 0.3 seconds, but I still have your
user's password. We're trying to structure a system that provides more
entropy and prevents weak passwords altogether.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

[Jeff Balogh]

On Thu, Aug 26, 2010 at 10:23 AM, Mat Clayton  wrote:
> About to file this as a Bug in Trac but after some opinions first.
> We are running django 1.2, and can't personally reproduce this bug, but some
> of our users can do. We are using SSL and CSRF to protect our login pages, (
> https://www.mixcloud.com/accounts/login/ ) in 99% of cases it works fine.
> However since Firefox 3.6.8 was released some users can no longer log in.
> After further inspection it appears though the browser is no longer sending
> HTTP_REFERER which is causing django/middleware/csrf.py L146 (on trunk) to
> reject the login. We have not been able to reproduce this locally, but have
> a handful of users who can consistently repeat this. From chatting to them
> they dont have anything running (personal firewalls/debug tools) which would
> strip out the referers and the best of their knowledge it appears to be a
> browser based issues. We cannot reproduce the but in OSX/linux/Windows XP
> with FF 3.6.8 however they all appear to be on Vista, which we do not have
> easy access to.
> I'm still trying and hunt down the right setup to reproduce this, is anyone
> seeing issues on this setup?
> Mat

We're seeing this recently as well
(https://bugzilla.mozilla.org/show_bug.cgi?id=590579).  It's caused by
an add-on turning off Firefox's network.http.sendRefererHeader
preference.  We haven't found which one yet.

In our case the pref was accidentally disabled when testing add-ons,
but people do intentionally turn off Referer for privacy reasons.  I
don't know if requiring Referer under https is a good idea.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Deprecating cmemcache, adding pylibmc

[Jeff Balogh]

On Sun, Feb 21, 2010 at 8:46 PM, Rajiv Makhijani  wrote:
> I recently implemented a custom caching backend to add support for pylibmc
> on a large site due to issues with cmemcache.
>
> For the most part the 'pylibmc' APIs are the same as 'python-memcached' and
> 'cmemcache'.
>
> One changed behavior I ran into with 'pylibmc' that I did not experience
> with other caching libraries is that when calling get_multi() with an empty
> list of keys, an exception was thrown. I do not believe this was the case
> with 'cmemcache' so legacy code may not be designed to handle this. To make
> my custom backend compatible, I had to change it to be:
>
> def get_many(self, keys):
>        if keys == []:
>                return {}
>        return self._cache.get_multi(map(smart_str,keys))

I filed a bug on this last night, and it's fixed already:
http://github.com/lericson/pylibmc/issues/issue/7

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Call for comment: #12624 Class based test runners

[Jeff Balogh]

On Sat, Jan 16, 2010 at 6:26 AM, Russell Keith-Magee
 wrote:
> Hi all,
>
> This is a quick call for comment on ticket #12624.
>
> This ticket proposes to make Django's test runner a class-based,
> rather than function based operation.

One thing: 
http://docs.djangoproject.com/en/dev/releases/1.2/#test-runner-exit-status-code
says that run_tests should return 0 for success or 1 for failure, but
your patch still returns the old `len(errors) + len(failures)`.

Other than that, this looks great.  I think it'll be easy to update
django-nose to the new system.  Thanks Russell!

Cheers,
jeff
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Is a partial translation acceptable?

[Jeff Balogh]

How do you guys feel about getting an incomplete translation for some
locales?  We might want to support some locales that Django doesn't
have yet, but I'm trying not to overload our localizers with all the
strings in Django (they're already sick of us).

I thought that something like http://gist.github.com/272594 looked
like a good start for them, with the technical strings and form
validation parts.

I'm inquiring so I can figure out what to do with translations when
(if) I get them.

Cheers,
jeff
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Adding an option to re-test only failed tests

[Jeff Balogh]

On Tue, Sep 29, 2009 at 8:56 PM, Rob Madole  wrote:
>
> I'll see if I can talk Jeff into adding what he's got as a start to
> this.  It looks solid to me.
>
> Ticket and patches forthcoming...

The nose test-runner that I'm currently using is at
http://gist.github.com/197593.  (The code I point to in the blog has
gotten more convoluted than I'd like; it turns out that can be a
problem if you're pointing at a vcs repo.)

For the most part, switching test runners is simple since Django
exposes all the setup and teardown functions.  The hacky part is
passing extra arguments to nose:  Django doesn't recognize nose
arguments so it complains and dies if you try something like
`./manage.py test --pdb-fail`.  Since I just wanted to get something
working, I pass all arguments after a '--' on the command line to nose
and Django happily ignores them.  If something like nose_runner is
shipped with Django it should run normally and be able to show the
same help screen that `nose --help` shows.

It was one of those "I'll come back and fix it later" sort of things. ;)

Cheers,
jeff

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---