mike-burns
commented
2 years ago Like @dorianmariefr said elsewhere, if you put an index on that column then that changes the timing of the lookup.
I guess this could be a timing attack otherwise but fixing it seems academic. How would you get the DB lookup to be so slow but the rest of the entirety of your Rails stack to be so consistent that you'd be able to notice?
After creating a PR to prevent a potential timing attacks with the remember token #917, I realized that at least one similar attack vector exists with clearance.
For example here's how devise sets the confirmation token, and finds the user. The confirmation token is not directly queried in the database, but rather its digest is. This makes it safe against timing attack.
In contrast, clearance queries the database from a user-supplied token. It also exposes the user_id, which seems unnecessary / leaks some info.
If I'm not mistaken, Clearance doesn't offer a confirmation flow out of the box, but users who might want to implement it, might build it based on the examples in Clearance. So there's a secondary effect here as well to take into account. (Devise seems to handle it similarly to password reset as far as I can tell).