On Jan 6, 10:37 am, Luke Plant <l.plant...@cantab.net> wrote:
> On Wednesday 06 January 2010 04:24:15 Elias Torres wrote:
> > Thanks Luke for your explanation. I think I have learned something
> > here in terms of my own application security independent of
> > Django's multi-app environment. Basically, you're reminding me
> > that as an application, I must be careful to not sign any random
> > string for a user, because it can be re-used for another purpose.
> > Therefore, we include the 'purpose', salt, or namespace in the
> > process. One thing I would like to ask though, is whether the salt
> > needs to be part of the key or the value? If you look at
> > TimestampSigner, the timestamp goes as part of the value. I think
> > the same can be done with the name of the cookie. In other words
> > you can always use a method like _cookie_signature as in Tornado's
> > implementation [1] and always pass two parts: cookie name and
> > cookie value. Technically, as long as your SECRET_KEY is
> > protected, there should not be a need to creating multiple signing
> > keys, especially if the data is not secret.
>
> > def _cookie_signature(self, *parts):
> > hash = hmac.new(SECRET_KEY, digestmod=hashlib.sha1)
> > for part in parts: hash.update(part)
> > return hash.hexdigest()
>
> This is equivalent to:
>
> hmac.new(SECRET_KEY,
> digestmod=hashlib.sha1).update("".join(parts)).hexdigest()
>
> With this, one problem is that accidental collisions between different
> parts of code are easier. Consider two cookies:
>
> Cookie 1, name = "use", value = arbitrary string set by user
> Cookie 2, name = "user_id", value = server assigned once they've
> logged in correctly.
>
> By supplying "r_id123" as the value for cookie 1, I can forge a
> user_id=123 cookie. If some validation is imposed on cookie 1, it
> might still be possible to manipulate the system such that "r_id123"
> is a valid choice, and the exploit would still work.
Agreed.
>
> Actually, the implementation in Tornado does not include the cookie
> name in the signature at all, making it even more vulnerable to this
> kind of attack.
Absolutely. I mailed the Tornado mailing list last night as well on
the matter.
>
> So that would be my defence of why it's better to put the "purpose"
> namespace into the key, rather than the value, in the context of HMAC.
> I'm not an expert though.
Can a separator solve that issue?
>
> This is one of the tricky things with security - it's never just a
> case of "use this API" - what you feed into the API is always
> critical.
Absolutely. It can become a very powerful black box.
>
> > Any thoughts on Django's auth using HMAC besides md5 and sha1
> > hashing alone?
>
> It sounds like a good idea, I'm not aware of any particular problems
> with our current implementation that would make this a priority
> change.
>
I think you are right and the 'being able to sign other messages'
attack that HMAC protects us against is not the main issue with
passwords. However, one thing I see some folks moving towards are
slower hashing functions to better protect stolen databases against
dictionary attacks. My friend enlightened me that computing SHA1 HMACs
or hashes it's way too fast so even with a salt, you can still match
many passwords from a stolen database. bcrypt on the other hand is
much slower. But that's just an FYI, not really suggesting to use it.
Thanks for the answers. Every time the subject comes up, I learn
something else about security and passwords.
[1] http://www.mindrot.org/projects/py-bcrypt/
> Luke
>
> --
> "Mediocrity: It takes a lot less time, and most people don't
> realise until it's too late." (despair.com)
>
> Luke Plant ||http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
