3 ms·
Or don't bother with this and generate random tokens, which should cover about 99 percent of cases where a clueless developer would run into the problems here.
by revelation 12y ago
Or don't bother with this and generate random tokens, which should cover about 99 percent of cases where a clueless developer would run into the problems here. Leave the cryptography to those that actually know they need cryptography.
- jbaudanza 12y agoWhat do you do with the random tokens after you've generated them? The author's proposed solution of "Encrypt then authenticate" seems pretty reasonable.
- ambrop7 12y agoYou sound like a web developer who thinks that 99% of cryptographic problems have to do with a web application discriminating between sessions. (I'm just guessing about the context of your comment since you didn't provide any.)
- dsacco 12y agoGenerating random tokens is cryptography. It just happens to be done more by non-cryptographers, which doesn't necessarily mean they're better at it (hint: they aren't). You can perform cryptanalysis on random tokens and if the RNG (or PRNG) isn't seeded properly, you get a replay attack. This is not to mention: aside from attacks, you have further crypto to do aside from the generation: how do you verify the token? If you roll your own RNG/PRNG and token generation, it is probably just as broken as the block cipher you tried to roll yourself as well. Using standard libraries and well-audited tools brings ciphertext authentication into the same realm of usability for developers that token generation is in.