sslpassword-protectionweb-testingchange-password

Password Reset Links Logged -- multiple uses by different IP's


I'm testing a website for a small, fixed amount of users that will be required to login. I'm testing the password change functionality right now, and after a successful password change, the password reset link is used multiple times afterward (unsuccessfully) by multiple different IP addresses. Each link is sent by the system to a specific email account and consists of a GET request with two data fields. I log all password reset attempts with timestamps, to include the requests as well as the reset attempts.

The website and password reset links are SSL, passwords hashed, and I follow the "best practices guide" on StackOverflow published here.

The events happen as quick as 10 seconds after the original user clicks on a password link and it happens to multiple users from multiple email accounts. Thankfully, once the original user clicks the link with valid information, the reset token information is removed from the database. I haven't seen a link being used before the intended user used it, which leads me to believe that someone is listening to traffic coming into the website.

This is a little unnerving...can anyone provide some insight on what's happening here? How are the credentials being intercepted? What can I do to prevent this?


Solution

  • This comes probably from security solutions which attempt to check if the link is malicious, i.e. phishing attempt or malware delivery. There are multiple products and vendors for this.

    These checks might be triggered by the users click when there is some firewall, Secure Web Gateway or endpoint security system involved. But such checks might even be triggered during mail delivery, if some security solutions checks the link before the mail gets delivered to the user. If you rely on the user being the first to click the link you might run into problems if you don't detect these earlier link checkers.

    Sometimes these link checkers will visit the URL from different IP to verify that the result is the same. Because some malicious sites will try to detect such link checkers and serve only harmless content if they assume a link checker behind the access.