Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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)


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.


/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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: