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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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.
