> The parent comment doesn't suggest using a PBKDF2-type construction to verify packets, but instead only to generate the secret key used by HMAC-SHA1. That's a one-time operation.
I am officially an idiot now. I see where the original comment is going with. Namely the "salt" part of the library, not the verification of the signature. You can just use a different secret key or derive one yourself.
I sincerely apologize for missing that and the comments that resulted from that.
That said: the secret key is the important part there, not the salt. The salt is just used to alter the secret key that the use of the serializer in two different places for different purposes does not create the same signature. The intended usage of the whole thing is to not use the salt at all but to provide different secret keys. The "salt" part was taken from the original django implementation with the idea to stay mostly compatible with their format.
Could that be improved by switching to PBKDF2? Probably, but breaking a lengthy secret key is an impossible operation currently, even with SHA1.
> Also, PBKDF2 has nothing whatsoever to do with rate limiting login attempts.
That's not what I meant. I meant that PBKDF2 on a server is feasible because you can rate limit the endpoint. I don't want my servers to be on 100% CPU because someone spams the login form.
The salt in PBKDF2 used as a KDF does almost exactly the same thing as the salt in a password hash: it prevents attackers from precomputing a huge dictionary of candidate password-key mappings and employing it on every PBKDF-keyed system the attacker finds. All secure password-handling schemes are randomized.
I don't know what you mean by "lengthy secret key", but if you're talking about a string that a human would recognize as language, that's not a strong key. Strong keys come from /dev/keygeneration --- er, I mean, /dev/random and from schemes like PBKDF2.
The attack on a human-intelligible crypto key occurs offline, and HMAC verifying keys are usually long-lived, so the attacker has both a lot of time and a lot of incentive to go after that key. Do not use human-intelligible strings as HMAC keys.
I've heard a lot of smart people worry about adaptive password hashes becoming a DOS vector for their application, and while stipulating that they are indeed smart people, they haven't thought this problem through very well. Every application can be DOS'd, usually in much more effective ways than by forcing the server to hash lots of passwords. Availability attack vectors in web apps are so common that they aren't even objectives on penetration tests; what would be the point?
Also, HMAC "authenticates" and "verifies" messages; it doesn't "sign" them. "Signature" has a subtly different meaning in crypto.
> I don't know what you mean by "lengthy secret key"
`os.urandom(120)` for instance. That's what Flask and Django document. I can see how this is not obvious from the documentation which puts a human readable string in there and I will update it appropriately.
> Also, HMAC "authenticates" and "verifies" messages; it doesn't "sign" them. "Signature" has a subtly different meaning in crypto.
I agree. The use of the word signing for this however is quite widespread and I adopted the same meaning (and implementation) as with the original Django one for compatibility.
Sure. Just know that developers sticking "c0mp4ny_n4m3" in their source file as an AES or HMAC key is a very common problem. os.urandom is a fine solution for the problem.
I am officially an idiot now. I see where the original comment is going with. Namely the "salt" part of the library, not the verification of the signature. You can just use a different secret key or derive one yourself.
I sincerely apologize for missing that and the comments that resulted from that.
That said: the secret key is the important part there, not the salt. The salt is just used to alter the secret key that the use of the serializer in two different places for different purposes does not create the same signature. The intended usage of the whole thing is to not use the salt at all but to provide different secret keys. The "salt" part was taken from the original django implementation with the idea to stay mostly compatible with their format.
Could that be improved by switching to PBKDF2? Probably, but breaking a lengthy secret key is an impossible operation currently, even with SHA1.
> Also, PBKDF2 has nothing whatsoever to do with rate limiting login attempts.
That's not what I meant. I meant that PBKDF2 on a server is feasible because you can rate limit the endpoint. I don't want my servers to be on 100% CPU because someone spams the login form.