Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's Dangerous, a Python cryptographic signing module

packages.python.org

Post reply on HN
Print view View original

31–40 of 60 posts

Re: It's Dangerous, a Python cryptographic signing module

#31

Post by amalcon »

JshWright wrote: post #30
the_mitsuhiko wrote: post #27

Earlier quoted context omitted.

> If rate limiting login attempts was all it took to protect passwords, then it wouldn't matter what hashing function you used, since the rate limiting would be independent of that. It does not matter what hashing function you use for the login. It matters in case your database leaks. > The use cases you described (session keys, activation links) are the perfect example of such environments. They are not. Because you…

>It does not matter what hashing function you use for the login. It matters in case your database leaks. That was my point... I suppose I'm not sure I understood why you brought up login entry point rate limiting?

Rate limiting makes it harder for people to DOS you using the password hash on your login form.

Re: It's Dangerous, a Python cryptographic signing module

#32

Post by tptacek »

the_mitsuhiko wrote: post #19
JoachimSchipper wrote: post #4

Earlier quoted context omitted.

> - HMAC key derivation: SHA1 of a secret key and a salt. Note to non-cryptographers: do not use low-entropy (password-ish) secretswith this, they can be bruteforced. (Using bcrypt/scrypt/PBKDF2 instead would fix this.)

> Note to non-cryptographers: do not use low-entropy (password-ish) secretswith this, they can be bruteforced. (Using bcrypt/scrypt/PBKDF2 instead would fix this.) PBKDF2 for this would be possible, but a terrible idea. The reason why PBKDF2 works for password verification purposes on web apps is because you can rate limit the login entry point. Doing that for sessions or activation links like what you would use itsd…

Deriving secret keys for signing and encryption systems is the entire reason PBKDF2 was designed. 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.

Also, PBKDF2 has nothing whatsoever to do with rate limiting login attempts. The attack PBKDF2 tries to blunt is offline, not online. PBKDF2 and bcrypt remain effective even when the imposed expense of a single hash compare is less than the network overhead of making a login request.

Re: It's Dangerous, a Python cryptographic signing module

#33

Post by tptacek »

This facility is "built in" to Rails, with MessageEncryptor and MessageVerifier. Before you consider writing your own "apply an HMAC-SHA1 hash to a string" library in Ruby, just take those classes from ActiveSupport instead. They've been reasonably well tested.

Re: It's Dangerous, a Python cryptographic signing module

#34

Post by the_mitsuhiko »

tptacek wrote: post #32
the_mitsuhiko wrote: post #19

Earlier quoted context omitted.

> Note to non-cryptographers: do not use low-entropy (password-ish) secretswith this, they can be bruteforced. (Using bcrypt/scrypt/PBKDF2 instead would fix this.) PBKDF2 for this would be possible, but a terrible idea. The reason why PBKDF2 works for password verification purposes on web apps is because you can rate limit the login entry point. Doing that for sessions or activation links like what you would use itsd…

Deriving secret keys for signing and encryption systems is the entire reason PBKDF2 was designed. 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. Also, PBKDF2 has nothing whatsoever to do with rate limiting login attempts. The attack PBKDF2 tries to blunt is offline, not online. PBKDF2 an…

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

Re: It's Dangerous, a Python cryptographic signing module

#35

Post by tptacek »

the_mitsuhiko wrote: post #34
tptacek wrote: post #32

Earlier quoted context omitted.

Deriving secret keys for signing and encryption systems is the entire reason PBKDF2 was designed. 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. Also, PBKDF2 has nothing whatsoever to do with rate limiting login attempts. The attack PBKDF2 tries to blunt is offline, not online. PBKDF2 an…

> 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 apologi…

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.

Re: It's Dangerous, a Python cryptographic signing module

#36

Post by the_mitsuhiko »

tptacek wrote: post #35
the_mitsuhiko wrote: post #34

Earlier quoted context omitted.

> 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 apologi…

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 r…

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

Re: It's Dangerous, a Python cryptographic signing module

#37

Post by tptacek »

the_mitsuhiko wrote: post #36
tptacek wrote: post #35

Earlier quoted context omitted.

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 r…

> 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 wor…

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.

Re: It's Dangerous, a Python cryptographic signing module

#38

Post by zokier »

the_mitsuhiko wrote: post #17
Luit wrote: post #8

Earlier quoted context omitted.

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.

Re: It's Dangerous, a Python cryptographic signing module

#39

Post by tptacek »

Locke1689 wrote: post #25
JoachimSchipper wrote: post #4

Earlier quoted context omitted.

> - HMAC key derivation: SHA1 of a secret key and a salt. Note to non-cryptographers: do not use low-entropy (password-ish) secretswith this, they can be bruteforced. (Using bcrypt/scrypt/PBKDF2 instead would fix this.)

There should be no password at all involved. You're doing key signing, not password authentication. You should have a tool, like OpenSSL or GPG, generating your key pair for you. And people, STOP USING CRYPTOGRAPHIC PRIMITIVES FROM THINGS THAT ARE NOT OPENSSL.

Aroo? OpenSSL is usually a terrible place to pull crypto primitives from; the string "OpenSSL" in a Python or Ruby file is a decent predictor of crypto bugs. Also, OpenSSL has a relatively poor track record of algorithm-level bugs.

I'd like your sentence more if it read "STOP USING CRYPTOGRAPHIC PRIMITIVES" and then ended with a period.

Re: It's Dangerous, a Python cryptographic signing module

#40

Post by tptacek »

the_mitsuhiko wrote: post #18
ctz wrote: post #3

Use of SHA-1 for this signature/MAC purposes in new applications is deprecated and will be disallowed from next year (source: NIST). I repeat: do not use SHA-1 in new applications. Do not use this module.

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

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.

Post reply on HN