3 ms·
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 r
by 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 agoOne 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 agoYou 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.