3 ms·
I fail to see how point 1) applies. The advantage of the naive implementation of "look it up in the db and send a message in any case" is that the basic amount
by Xylakant 14y ago
I fail to see how point 1) applies. The advantage of the naive implementation of "look it up in the db and send a message in any case" is that the basic amount of work done is pretty much the same in any case. There might be some cases where the database query returns faster if the email is (not) in the database, depending on how the app is structured (index, query schema) but I'd bet that mounting a side-channel attack on that difference either requires a deep knowledge of the app or a long experimental phase. Adding some metrics that trigger an alarm if suspiciously many requests to the lost password page happen should be trivial.
- sltkr 14y agoI would think the bigger time difference would come from sending an e-mail message (or not), not the database look-up itself. But I'm still not convinced that's easily measurable in practice, considering most sendmail implementations dump messages into a queue rather than trying to deliver them immediately.
- Xylakant 14y agoBut that's the whole point: You send an email in any case to the given email address. If the address is registered, you send a "this is you password reset link" email and if not you send a "ok, somebody requested a password reset for this email-address and we don't know it" email. This sort of reduces pain point 3) as well since you can offer some explanation to the user [1] but I guess there's always someone who doesn't get it, so it's not a complete solution to that problem. [1] "If you're registered here, you might be registered with a different email address. If you're not, ignore this one. etc."