4 ms·

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 sal

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.

JoachimSchipper 14y ago
> - 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.)
- deleted 14y ago
  [deleted]
- ibotty 14y ago
  ... when will they ever learn...
  - the_mitsuhiko 14y ago
    > ... when will they ever learn... When will some people on hackernews ever learn to start using their brain. PBKDF2 is not what you use to verify signatures. I think the name should already give that away. //EDIT: and when will I ever learn to read properly. I just realized that the comment was referring to the "salt" part, not the signature.
- the_mitsuhiko 14y ago
  > 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 itsdangerous for is an easy way to have other people DDOS your app. PBKDF2/bcrypt etc. is not the solution for this problem.
  - JoachimSchipper 14y ago
    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.)
    - the_mitsuhiko 14y ago
      > 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.
      - Luit 14y ago
        One way to get a good strong secret key for this purpose: $ python >>> import os >>> os.urandom(64)
        amalcon 14y ago
        /dev/random is better than urandom for this sort of thing. On linux: dd if=/dev/random bs=64 count=1 2>/dev/null | hexdump
        tcas 14y ago
        You shouldn't use urandom for crypto purposes. /dev/random is generated (on most platforms) as cryptographic strength numbers (usually from hardware), but can block if it runs out of data. /dev/urandom was created with the guarantee to never block and will use /dev/random's pool of numbers initially but can start outputting lower entropy numbers if /dev/random blocks.
  - JshWright 14y ago
    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.
- Locke1689 14y ago
  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.
  - tptacek 14y ago
    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.
    - Locke1689 14y ago
      I took that from cperciva when he did his crypto talk. Edit: Found quote: Website security: Use OpenSSL. OpenSSL has a horrible track record for security; but it has the saving grace that because it is so widely used, vendors tend to be very good at making sure that OpenSSL vulnerabilities get fixed promptly. I wish there was a better alternative, but for now at least OpenSSL is the best option available. UPDATE: For added security, terminate SSL connections in restricted environment and pass the raw HTTP over a loopback connection to your web server. And yes, I'd always recommend using the highest-level possible API. If you have SHA in your code you are probably working at too low a level. Do you have any recommendations for a better toolkit? Tarsnap uses Colin's own implementations so it's not a very good resource. There are other problems I've found with cryptlib, etc., (e.g., cryptlib is commercial).
      - tptacek 14y ago
        I agree that one thing that is actually worse than directly pulling AES or SHA-2 out of OpenSSL and fucking with it in your code is actually implementing AES or SHA-2 yourself. :)
        Locke1689 14y ago

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.

JoachimSchipper 14y ago

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

deleted 14y ago
[deleted]
ibotty 14y ago
... when will they ever learn...
- the_mitsuhiko 14y ago
  > ... when will they ever learn... When will some people on hackernews ever learn to start using their brain. PBKDF2 is not what you use to verify signatures. I think the name should already give that away. //EDIT: and when will I ever learn to read properly. I just realized that the comment was referring to the "salt" part, not the signature.
the_mitsuhiko 14y ago
> 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 itsdangerous for is an easy way to have other people DDOS your app. PBKDF2/bcrypt etc. is not the solution for this problem.
- JoachimSchipper 14y ago
  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.)
  - the_mitsuhiko 14y ago
    > 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.
    - Luit 14y ago
      One way to get a good strong secret key for this purpose: $ python >>> import os >>> os.urandom(64)
      - amalcon 14y ago
        /dev/random is better than urandom for this sort of thing. On linux: dd if=/dev/random bs=64 count=1 2>/dev/null | hexdump
      - tcas 14y ago
        You shouldn't use urandom for crypto purposes. /dev/random is generated (on most platforms) as cryptographic strength numbers (usually from hardware), but can block if it runs out of data. /dev/urandom was created with the guarantee to never block and will use /dev/random's pool of numbers initially but can start outputting lower entropy numbers if /dev/random blocks.
- JshWright 14y ago
  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.
Locke1689 14y ago
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.
- tptacek 14y ago
  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.
  - Locke1689 14y ago
    I took that from cperciva when he did his crypto talk. Edit: Found quote: Website security: Use OpenSSL. OpenSSL has a horrible track record for security; but it has the saving grace that because it is so widely used, vendors tend to be very good at making sure that OpenSSL vulnerabilities get fixed promptly. I wish there was a better alternative, but for now at least OpenSSL is the best option available. UPDATE: For added security, terminate SSL connections in restricted environment and pass the raw HTTP over a loopback connection to your web server. And yes, I'd always recommend using the highest-level possible API. If you have SHA in your code you are probably working at too low a level. Do you have any recommendations for a better toolkit? Tarsnap uses Colin's own implementations so it's not a very good resource. There are other problems I've found with cryptlib, etc., (e.g., cryptlib is commercial).
    - tptacek 14y ago
      I agree that one thing that is actually worse than directly pulling AES or SHA-2 out of OpenSSL and fucking with it in your code is actually implementing AES or SHA-2 yourself. :)
      - Locke1689 14y ago