On Jan 4, 4:47 am, Simon Willison <[email protected]> wrote:
> As you can see, the separator between the signature and the value
> defaults to being a ':'. I plan to move it from being an argument on
> the sign and unsign methods to being an argument to the Signer class
> constructor.

Here's my $.02 based on a cursory review.  I like the idea of putting
this logic into django.  I find myself implementing something similar
often.

This all looks ok from a security perspective, but it seems there are
a couple of things that could be simplified:

1) sep.  Why use a delimiter at all?  The fields you are encoding
(hash or hash+date) are of a determinate length.  Put those fields
first, and expect them to have the correct length when unsigning.

2) salt + 'signer'.  I don't see the security advantage to this.  If
the django secret key is compromised, you are dead.  If not, then
everything should be good.  If someone can brute-force the key from a
large sample of signatures, and I agree that is a small but real risk
(at least I thought so with MD5), then they will much more easily
reverse the salt+'signer'+secret from that.

Unless you picture the salt changing frequently.  In which case, how
does the unsigner know the salt?

I suspect there may even be a security risk to letting people use
salt.  They may use something that is known to the attacker, and it
seems like this might carry some risk in itself.

One other thought - I know you expect this to be used for texty
protocols like http cookies, but should the signer class be producing
already-encoded data?  It seems like the protocol using the signed
cookie should be in charge of encoding it.  i.e. produce an 8-bit
chunk of data.  Let the set-cookie logic decide what encoding it is
passed that binary chunk.  This would make the base signer class more
useful for applications where encoding is not necessary.  And set-
cookie should be robust enough to know when the data passed to it
needs encoding.

-=Julian=-

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


Reply via email to