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

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



Click the link in his comment.




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

Search: