Well then fork it and make it use HMAC with SHA256/512... Additionally, "Do not use this module" is bad advice if it leads to someone making their own MAC implementation, because that's almost always a bad idea. HMAC-SHA1 still is good security for this purpose.

I bet that as soon as standards bodies (like NIST) actively encourage you to use better hash functions (which they will probably do soon) the developer of this module will decide on what is safe enough for this purpose.

You advise to "fork it", but immediately after that you add the notorious "do not write your own" meme. Can you see the inconsistency of the messages?

Part of security is being up-to-date in regards to things like hashes. If authors don't update their own libraries and you need to tweak them manually, how is it different from "writing your own"?

I agree I'm a bit inconsistent, but the library is well written, and exchanging the hashing function is a trivial task. That's not really quite "writing your own". I just mean to discourage people who aren't 100% sure they know what they're doing.

I strongly agree with Armin: HMAC-SHA1 (note, the combo, it's not just the latter) is still good security for most applications you'd consider this library for.

I always thought the advice against "writing your own" spoke of the algorithm itself, not a library around the algorithm.

Nope. Google Keyczar: standard algorithms; still screwed up. You should always use the highest level interface available.

It shouldn't be more than changing those two lines:

https://github.com/mitsuhiko/itsdangerous/blob/59f3bf7877e21...

And the tests, of course.

My point exactly! Armin (the maker/maintainer of the module) will probably consider doing this somewhere in the future.

I just pushed out a release that makes it possible to override the digest in a subclass easier.

While overrideability is good, wouldn't it be better to also be 'secure by default'? I'd imagine that SHA-2 would be more sensible default for most users.

> I repeat: do not use SHA-1 in new applications.

Probably, but not necessarily. It's not like the other sha versions are fixing the overall problem however.

> Do not use this module.

Even before the 0.13 release I just pushed out where you can override the module easier you could still easily change the hash method with a two line change. Also it's not like maintainers can't change things easily if modules are well defined.

And even if the module would not allow changing the hash method easily SHA1 with HMAC is still incredibly hard to exploit.

SHA-1 and SHA-2 (SHA256, SHA512) are not the same algorithm. The problem with SHA-2 isn't that it's insecure; it's that it's slow for its current predicted level of security, and that it's MD-strengthened and so requires an HMAC construction to use in applications like MACs. The sentence "It's not like the other sha versions are fixing the overall problem" is wrong.

You would indeed be better off using SHA256.

But not much. It's worth pointing out though that dogmatism around not using SHA-1 is misplaced. There are still no practical attacks on HMAC-MD5, for instance, even though MD5 itself is effectively broken and its use in (for instance) X.509 certificates is insecure.

> SHA256

As it is, the size of that digest is also 14 bytes more and I don't feel happy truncating the hash. The bigger SHA2 versions are even longer. Considering that thing should go into cookies and URLs I did not feel very happy with that.

> You would indeed be better off using SHA256.

Probably. I was indeed under the impression that SHA2 is based on the same building blocks as SHA1 but I assume that is not the case. That being said: upgrading is not hard if it even comes to the point where it would be necessary.

Do you really want to be the guy promoting a message verification library who won't use SHA-2 because of the extra 14 bytes of digest length? You made a design mistake here. Just fix it.

Neils Ferguson, et. al of Cryptography Engineering (p. 95) suggest that truncating a HMAC-SHA-256 to 128 bits should be safe, given current knowledge in the field.

This is code that's mostly going to be used in Python web apps (if at all). I thought about arguing in favor of truncating the hash, but then figured this guy would just say "well, I'm not so sure, so to be on the safe side... [I'll use an inferior hash]"... a better argument is, just eat the extra bytes and stick them on your message.

To clarify very slightly, use SHA-256, SHA-384 or SHA-512 instead.

Sometime soon I believe SHA-3 will be chosen and we'll all be able to move onto that.

For those interested, NIST (National Institue of Standards and Technoology) announced a competition to find candidates for the SHA-3 algorithm back in November 2007:

"NIST also plans to host a final SHA-3 Candidate Conference in the spring of 2012 to discuss the public feedback on these candidates, and select the SHA-3 winner later in 2012." [http://csrc.nist.gov/groups/ST/hash/sha-3/Round3/index.html]

The final SHA-3 Candidate Conference was held March 22-23, so they should be picking the winner any day now.

I forked the project and updated the hashing algorithm: https://github.com/andrewconner/itsdangerous

> I forked the project and updated the hashing algorithm: https://github.com/andrewconner/itsdangerous

That is not necessary, I adjusted the API so that you can easily subclass it and change the digestmod.

It should default to a SHA-2 hash and you should deprecate the branch that defaulted to SHA-1.