Re: BCrypt and PBKDF2 Password Hash Caching

[Erik van Zijst]

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 
> > 
> 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.

Re: BCrypt and PBKDF2 Password Hash Caching

[Javier Guerra Giraldez]

On Tue, Nov 19, 2013 at 8:48 PM, Erik van Zijst
 wrote:
> 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.


right, that would fix it.  (i guess, i'm no security expert)

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.

of course, that's easy for me to say; i don't manage a big site like
yours, so the switch to PBKDF2 doesn't cost me a cent.

i wonder if siphash is strong enough for paswords...

-- 
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/CAFkDaoSRRWFq6zNmYMtSOzPeTuoRQFN7ZbF72f5xeLda%3DQSG%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: BCrypt and PBKDF2 Password Hash Caching

[Donald Stufft]

Password hashing schemes are slow on purpose to prevent brute force.
Siphash wouldn't make sense because if you're switching for speed you
can just use any secure hash function.

crypt by default is much slower than PBKDF2 FWIW. You should tune the
work factor/iterations until it's fast enough that it doesn't negatively
impact your site but as slow as possible otherwise. The higher the work
factor/iterations the harder it is to brute force, but the more negative
impact each login has.

I would tune bcrypt or PBKDF2 down before I implemented this custom
scheme.

-- 
  Donald Stufft
  don...@stufft.io

On Tue, Nov 19, 2013, at 09:10 PM, Javier Guerra Giraldez wrote:
> On Tue, Nov 19, 2013 at 8:48 PM, Erik van Zijst
>  wrote:
> > 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.
> 
> 
> right, that would fix it.  (i guess, i'm no security expert)
> 
> 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.
> 
> of course, that's easy for me to say; i don't manage a big site like
> yours, so the switch to PBKDF2 doesn't cost me a cent.
> 
> i wonder if siphash is strong enough for paswords...
> 
> -- 
> 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/CAFkDaoSRRWFq6zNmYMtSOzPeTuoRQFN7ZbF72f5xeLda%3DQSG%3Dw%40mail.gmail.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/1384914021.7999.49670181.1381CCF1%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/groups/opt_out.

Why not use @classmethod decorator consitently in django/utils/functional.py?

[Adam Smith]

Hi, I'm quite new to Python and Django, as I read through the 
django/utils/functional.py,
 I 
was wondering why not use `classmethod` as a class method decorator 
consistently, as line 
334?
 
Any specific reasons?

Like I said, I'm quite new to Python and this community, I'm not sure 
whether this is the right place to ask this kind of question.

Thanks.

-- 
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/0cca027d-8af5-4590-983f-85e3400fdcf9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: BCrypt and PBKDF2 Password Hash Caching

[Wim Lewis]

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.

Re: Why not use @classmethod decorator consitently in django/utils/functional.py?

[Shai Berger]

Hi Adam,

(reordering quoted parts a little)

On Tuesday 19 November 2013 18:33:01 Adam Smith wrote:
> Hi, I'm quite new to Python and Django

Welcome aboard!

> Like I said, I'm quite new to Python and this community, I'm not sure
> whether this is the right place to ask this kind of question.
> 

This list is intended for discussing the development of Django, so questions 
about its implementation are exactly on topic.

> as I read through the django/utils/functional.py, I was wondering why not
> use `classmethod` as a class method decorator consistently, as line
> 334? Any specific reasons?
> 

I assume you're referring to the places like line 122 (which you linked to) 
and line 140, where instead of

@classmethod
def x(cls,...):
...

you see

def x(cls,...):
...
x = classmethod(x)

The reason for this is historic: Decorators were only introduced into Python 
at version 2.4, and Django<1.2 still supported Python 2.3. Some code hasn't 
changed since then. Now that you pointed it out, these specific lines are 
likely to change soon :)

Thanks,
Shai.

-- 
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/173119684.RxPl0gn4eY%40deblack.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Why not use @classmethod decorator consitently in django/utils/functional.py?

[Adam Smith]

>
> I see. Thanks a lot Shai, for both your welcome and detailed explanation!


 

-- 
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/207aa658-4ba1-4cad-969f-37bb091b679f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: BCrypt and PBKDF2 Password Hash Caching

[Erik van Zijst]

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 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/3a3e20e2-1040-4067-9657-21d5b95d9174%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.