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

21–30 of 60 posts

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

#21

Post by the_mitsuhiko »

atto wrote: post #16
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 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.

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

#22

Post by JoachimSchipper »

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…

Let me expand a bit: use bcrypt etc to derive the key instead of using a salted hash, then use HMAC to sign the data. You're right that using bcrypt for every request would be really bad for performance, but it's a per-app password, so you can just do run bcrypt once, at startup.

(Alternative: drop the SHA1/bcrypt/whatever and just use a really strong secret key. 128 bits of randomness is impossible to brute-force.)

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

#23

Post by the_mitsuhiko »

JoachimSchipper wrote: post #22
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…

Let me expand a bit: use bcrypt etc to derive the key instead of using a salted hash, then use HMAC to sign the data. You're right that using bcrypt for every request would be really bad for performance, but it's a per-app password, so you can just do run bcrypt once, at startup. (Alternative: drop the SHA1/bcrypt/whatever and just use a really strong secret key. 128 bits of randomness is impossible to brute-force.)

> but it's a per-app password, so you can just do run bcrypt once, at startup.

itsdangerous has nothing to do with passwords. It's about signing small messages and these messages are obviously created at runtime.

> nonsense and just use a really strong secret key

That's how you should use itsdangerous: use a strong secret key.

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

#24

Post by JshWright »

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…

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.

The point of PBKDF2 and friends is to make it expensive to brute force acquired hashes. It effectively 'rate limits' hash-in-hand brute force attempts. It's designed to protect hashes once they are in hostile environments.

The use cases you described (session keys, activation links) are the perfect example of such environments.

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

#25

Post by Locke1689 »

JoachimSchipper wrote: post #4
obiterdictum wrote: post #2

Executive summary: - The signature: SHA1 HMAC of data and, optionally, a timestamp to expire signatures. - HMAC key derivation: SHA1 of a secret key and a salt.

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

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

#26

Post by Locke1689 »

ebiester wrote: post #12
gambler wrote: post #9

Earlier quoted context omitted.

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

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

#27

Post by the_mitsuhiko »

JshWright wrote: post #24
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…

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. The point of PBKDF2 and friends is to make it expensive to brute force acquired hashes. It effectively 'rate limits' hash-in-hand brute force attempts. It's designed to protect hashes once they are in hostile environments. The use cases you…

> 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 don't want to reverse engineer the contents of the message (the message is there in plain text). That's the reverse of what you want to do with passwords. In case of the password you want to brute force what the password is, in case of a signed message you want to forge a signature.

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

#28

Post by Luit »

gambler wrote: post #9
Luit wrote: post #6

Earlier quoted context omitted.

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

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.

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

#29

Post by Luit »

the_mitsuhiko wrote: post #23
JoachimSchipper wrote: post #22

Earlier quoted context omitted.

Let me expand a bit: use bcrypt etc to derive the key instead of using a salted hash, then use HMAC to sign the data. You're right that using bcrypt for every request would be really bad for performance, but it's a per-app password, so you can just do run bcrypt once, at startup. (Alternative: drop the SHA1/bcrypt/whatever and just use a really strong secret key. 128 bits of randomness is impossible to brute-force.)

> but it's a per-app password, so you can just do run bcrypt once, at startup. itsdangerous has nothing to do with passwords. It's about signing small messages and these messages are obviously created at runtime. > nonsense and just use a really strong secret key That's how you should use itsdangerous: use a strong secret key.

One way to get a good strong secret key for this purpose:

$ python

>>> import os

>>> os.urandom(64)

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

#30

Post by JshWright »

the_mitsuhiko wrote: post #27
JshWright wrote: post #24

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. The point of PBKDF2 and friends is to make it expensive to brute force acquired hashes. It effectively 'rate limits' hash-in-hand brute force attempts. It's designed to protect hashes once they are in hostile environments. The use cases you…

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

Post reply on HN