On Fri, Sep 25, 2009 at 7:02 AM, Luke Plant <l.plant...@cantab.net> wrote:
> Suppose one part of an app signs an e-mail address for the purpose of
> an account confirmation link sent in an e-mail. The user won't be
> able to forge the link unless they know HMAC(SECRET_KEY, email).
>
> However, suppose another part of the website allows a user to set
> their e-mail address (merely for convenience), and stores it in a
> signed cookie. That means an attacker can now easily get hold of
> HMAC(SECRET_KEY, email), and forge the link.
This was something I was concerned with when I put together my app, so
I just added the name of the cookie to the signature as well, rather
than requiring some other explicit prefix. Since the two parts of the
application would need to use different names anyway to avoid other
problems, I figured the cookie name alone would be sufficient. If we
end up with something like response.set_signed_cookie() or
response.set_cookie(..., signed=True), the cookie name would be
available to the signing code internally, without any need to add in
some other key.
Of course, it'd still be worth documenting for the case of using the
signing stuff outside of cookies, because similar problems could creep
in elsewhere. I just think if we already have a name available, we
should be able to use it without any trouble at all. I wish there was
a way to sign the expiration as well, so people couldn't artificially
extend the life of the cookie, but since that doesn't come back in the
request, there'd be no way to validate it.
> So I propose:
>
> - we add unique prefixes to the SECRET_KEY for every different
> place it is used. So for the e-mail confirmation link, we use
> HMAC("email-confirmation" + SECRET_KEY, message)
I think this is good for everywhere the raw signing API is accessed,
perhaps to the point where that API can't even be used without a key
(a namespace, really - honking great idea!). Helpers on top of that
API could do without asking for that separately, if they can retrieve
a reasonable key from other forms of input, such as a cookie name or a
query-string argument name.
-Gul
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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
-~----------~----~----~----~------~----~------~--~---
