> Yeah, SHA256 and SHA512 have the downsides of being rather long for > the type of application the signatures are going to be used for, > e.g. one-time URLs.
That's fair. SHA1 is moving towards broken, but HMAC currently covers that gap. Shorter is certainly a feature we want here. > If I read the draft spec correctly it's basically the same algorithm > as used in the current patch but SHA256 instead of SHA1. [1] Yeah. Unfortunately JWS packages a fair bit of data which is not strictly necessary (encryption protocol, etc.). In the interest of letting users put as much data as possible in cookies, we probably want to avoid that. Baseconv is a clever bit of work. It should probably be using our full base64 charset. We could also shave some digits in the time-limited output there by subtracting from a more recent fixed value than the unix epoch, the way the password reset token code does. I'm not entirely happy with the way the salting works (or perhaps I've misunderstood it). It seems more appropriate to generate the salt (let the user specify the length) and store it with the string, the same way you do salted passwords. The way the interface is currently written, nobody will ever use a salt, or they'll try to use a static string as a salt (the existing docs get it wrong in exactly this way), which largely defeats the purpose. It would make more sense to be able to say "I want salt" the way you say "I want a timestamp". -Paul -- 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.
