Hacker News Reader

Comment by ratsbane | Hacker News Reader

These things can be useful fraud-detection signals. If you don't log password reset requests then you're missing a chance to catch suspicious behavior. Even if you're capturing that data but using it now, at least having it gives you that potential.

Also, unless you plan on making the valid window very short, you probably want to mark reset requests as used so someone's old email doesn't get used again.

It's not a completely crazy idea, but the minimal amount of trouble required for the extra tables doesn't seem like enough to give up the logging and expiration benefits.

View on HN

Logging things in a relational database for the purpose of catching suspicious behavior is a bad idea.

You also don't need to mark reset requests as used, if the generated token was composed of the user's old hashed password or email, as that token will be invalid as soon as the user does the reset.

It's worth noting the parent didn't say anything about relational databases. Even if they did, I don't see how that would be a problem.

How else can you keep track of whether there is a wave of reset abuse targeting an user / email, if not through saving it to some sort of data store?

eg - after 5 reset attempts in 15 or 30 minutes, prevent any further reset attempts for the next X amount of time; either outright, or based on a signature of the request

"Some sort of data store" does not imply the normal solution that people deploy to solve this problem.

There is a big difference between defining a table in your database that keeps track of resets, or using a queue of messages (event sourcing even?) with filters applied for detecting abnormal behavior.

The former is a dirty solution, dirty because you're storing junk that shouldn't be stored in a relational database and it doesn't take care of other much more important kinds of attacks on your system. Whereas the later is extensible.

So lets say that in addition to limiting the number of resets one does, you also want to limit the number of failed login attempts to 10 per hour. You may also want to limit users jumping between IP addresses, you don't want to be too strict about it, because mobile connections, but you do want to prevent multiple sessions active that use the same user credentials. You may also want your system to evolve based on taking averages out of user's past activity.

Now where does that data go? Of course it's in "some kind of data store", but that says nothing, because the log files stored on disk are also a data store.

Reply on news.ycombinator.com