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. 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. 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. -- 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/58914BE0-6F01-42EA-B994-ED0D2870AD66%40omnigroup.com. For more options, visit https://groups.google.com/groups/opt_out.
