You make a good point. An obvious fix would seem to be to add the username to the cache key. This way users cannot "use" another user's cache entry.
Cheers, Erik On Friday, 15 November 2013 11:41:43 UTC-8, Javier Guerra wrote: > > On Fri, Nov 15, 2013 at 2:27 PM, Marc Tamlyn > <marc....@gmail.com<javascript:>> > wrote: > > That said, sounds an interesting solution and would make a good library. > > However I'm not knowledgeable enough to say if it is a good idea from a > > security perspective. > > > imagine this scenario: > > an attacker gets the user database and _a_single_one of these cache > entries. > the paswords are bcrypt, but the salts are cleartext. the attacker > chooses _any_ user and calculates a password such that when > concatenated with that user's salt produces a collision [1] with the > single SHA1 cache key stolen. > > in short, this library reduces the security from bcrypt to salted > SHA1, and the data needed for any and all the users to any single > cache entry. > > hum.... i don't like it > > [1]https://www.schneier.com/blog/archives/2005/02/sha1_broken.html > > > -- > Javier > -- 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/9098753c-1077-4acf-8d0e-9ae424495d49%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
