The timestamp is necessary to limit replay attacks, and so it should probably be more than optional - always issued, and checked by default. The danger is that users might think "signing" is a bulletproof guarantee that the cookie as received is exactly the latest cookie issued to that unique user and use them where a replay attack would be unacceptable for security. There is still a max_age window for replay attacks, which I don't know of any way to close.
Encrypting the cookies as well would make replay attacks a little trickier, forcing the attacker to use trial-and-error rather than identifying targets by inspection. Security through obscurity only, though cookies being opaque to the user can be useful in its own right. The API could accept a user-supplied "check" string so that if the user can supply some other details - maybe an IP - and have the API verify this for them (thus preventing replay attacks for different IPs). > unsigned_value = signer.unsign(signed_value) On an API level, 'unsign' isn't an obvious choice. The operation you are doing is verifying and stripping a signature, so I'd expect 'verify' in the name. You also might want access to the signature data. So for example, something like this: >>> s = SignedString(signed_value) >>> s 'Hello world' >>> s.timestamp 1262612904 >>> s.is_key_current() True >>> s = SignedString(old_signed_value, max_age=3600) ... SignatureExpired: signature older than max_age Dan -- 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.
