On Jan 5, 2:33 pm, Luke Plant <[email protected]> wrote:
> On Tuesday 05 January 2010 16:53:17 Elias Torres wrote:
>
> > Simon,
>
> > I'm not a security expert by any means, but I really the fact that
> > you're making use of HMACs in your design. I will ask a good friend
> > (Ben Adida) who's really an expert on the subject to see if your
> > paranoia on adding a salt and hashing the key helps you in any way.
> > My intuition says if the salt will be stored and made available to
> > anyone with access to the DB, I'm not sure it will make much of a
> > difference. HMAC takes care of the prefix/suffix attacks already.
>
> The point of the 'salt' is to make it easy to use unique keys.
> Otherwise, one use of HMAC with SECRET_KEY in a web app could be
> trivially used to compromise another usage.
>
> For example, suppose that, on a social network, the user can specify
> the username of someone that they nominate as a 'best friend' . This
> value might be stored in a signed cookie. If we use SECRET_KEY
> without salt as the HMAC key, the user then has access to the value
> HMAC(SECRET_KEY, some_username). But suppose another signed cookie is
> used to store the username when a user logs in (as opposed to using a
> session). The value will be HMAC(SECRET_KEY, users_username). Since
> an attacker can trivially get hold of HMAC(SECRET_KEY,
> somone_elses_username), they can log in as anyone they like.
>
> 'Salt' in the key is to protect against that. The signed cookie
> implementation, for example, uses the cookie *name* as part of the
> salt, so that all cookies have their own key. The salt is not a
> secret, so doesn't provide any additional protection against brute
> force attacks, but it isn't meant to.
>
> Luke
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()
Any thoughts on Django's auth using HMAC besides md5 and sha1 hashing
alone?
Thanks,
-Elias
[1] http://github.com/facebook/tornado/blob/master/tornado/web.py#L251
>
> --
> "Making it up? Why should I want to make anything up? Life's bad
> enough as it is without wanting to invent any more of it." (Marvin
> the paranoid android)
>
> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
