On Tuesday, 19 November 2013 18:38:33 UTC-8, Wim Lewis wrote: > > > On 19 Nov 2013, at 6:10 PM, Javier Guerra Giraldez wrote: > > but still you get only SHA1-level strength, when the whole idea was to > > switch to stronger crypto. if in your case SHA1 is enough, you can > > simply keep using it. if it's not enough, then you shouldn't be using > > it. > > Well, it seems to me it's still an improvement over plain SHA1 password > storage. If the attacker only has access to on-disk data (or backups, > etc.), then you have BCrypt-level strength. If the attacker has access to > memcached, then you only have SHA1-level strength, as you say. >
Exactly, that's the idea behind it. It's based on the assumption that persistent storage is more vulnerable than transient state. Memcached also only ever contains entries for active accounts and even those get purged after a while, so the "bounty" will only ever be a fraction of what's in the database. > I don't know what bitbucket's access pattern looks like, but how much less > effective would this mixin be if you didn't use memcached (and just had an > in-process, unshared password cache / memoized BCrypt)? If an attacker > gains access to *that* cache, then they presumably also have access to the > plaintext passwords coming from the users, so you haven't lost anything. > Absolutely. If we could make it work with an in-process cache, we would have. However, Bitbucket is distributed across many servers through stateless load balancing. This means that consecutive requests by a user typically end up on different servers. Worse still, we use fairly simple single-threaded, synchronous worker processes (gunicorn syncworker) and obtain parallelization through multi processing. Private, in-process caches would thus be very inefficient. > Another idea would be to store > PBKDF2-with-lower-work-factor(salt+user+password) entries in the cache > instead of using SHA1(...). This would let you tune the amount of security > you're giving up vs. performance. > I think that's a little bit of a red herring. PBKDF2 and BCrypt are roughly in the same category with regards to cost. In order to make that viable, we'd have to reduce the work factor substantially. I'm not saying there's no better alternative for the cache than SHA1, but through their very design PBKDF2 and BCrypt are unbelievably expensive and would have to be weakened dramatically. Cheers, Erik -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3a3e20e2-1040-4067-9657-21d5b95d9174%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
