Reset Password Ideas

I know fellow MVP Trevor Fayas just mentioned something about this like that last week. I'll push him to this ticket :)

So how the Password system works in Portal Engine is as soon as the "Reset Password" web part is hit, it clears the PasswordHash field in the UserInfo after it validates it. Which means after this (when the ACTUAL user visits) the field is empty.

So an actually very simple work around was to wrap the GetUserInfo call in a cache helper WITHOUT putting a dependency on it. This way it would get the UserInfo (with hash) the first call (the 'email software'), and then when the user visits it, it would get the cached UserInfo that would still have the hash.

Here's the V11/V12 zip you can download and install. Just replace the "Reset Password" with this webpart.

Hey Trevor, that is an interesting idea. I am just curious how safe is this? How do you know that the link was visited by some filtering software and not the attacker?

Very safe, you still need a valid hash and you set the minutes the link remains active (default 5), and once password is reset it clears that cached retrieval. So only way to break it is the same way you would anyway: for someone to find the reset link and use it before you.

Trevor....when I test this, the first time the page loads it is still removing the userpasswordrequesthash from the table. Is there a difference in what executes between email software clicking and user clicking?

The database table will still delete the field on first visit (email software), but it will "find" the user by that has for X minutes thanks to the cached call, which means when the user clicks the link they will still find the user and validate the hash and still be able to reset their password.

Once cancelled or reset, that cache clears and thus no one can use it again.

Hum...I am still getting an invalid link error. Thoughts?

Shoot me an email, tfayas@hbs.net or ping me on the slack channel kentico-community.slack.com

Thanks for this suggested solution: caching UserData from the hash lookup.

What about across a load balanced web farm ? The caching trick doesn't work for us as the 2nd request (from User Client browser) can hit a different web server than the 1st request from email link protection (Outlook SafeLinks).

The load balancer provides a client cookie to the user for sticky session, but that is irrelevant to the SafeLinks bot.

You may then have to mimic the cache using a SQL table, store that hash in a table with a timestamp, and look up to see if it exists within x minutes of now when they attempt to reset. Maybe put a scheduled task to delete old hashes frequently.