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