3 ms·
I would say, store the hash of the token in the database, but that's my personal preference to add a bit of defense against timing attacks, insider stealing the
by zaroth 9y ago
I would say, store the hash of the token in the database, but that's my personal preference to add a bit of defense against timing attacks, insider stealing the token, or token database breach.
- tptacek 9y agoI don't think this buys you anything. Keep things simple.
- MichaelGG 9y agoI feel like picking a fight. What's the downside? It's super simple to hash them, and it prevents a read-only exploit from turning into a major catastrophe. Example from something I built. If our db was used by an attacker, with all client API keys, they could go liquidate those accounts (place phone calls). Huge loss, and not far-fetched (this kind of attack happens daily and is profitable). With hashed API keys, nothing is possible. We don't even need to tell people to rotate keys. With plain keys, we'd need to freeze usage for people without e.g. IP address restrictions in place. Read-only leaks happen all the time. Why not make sure they don't impact your clients API usage? I'm not just trying to fight. It's a handful of trivially-validated lines of code that significantly mitigate the impact of a data leak. Seems like a super easy tradeoff.
- pvg 9y agoClick the link in his comment.