3 ms·
Firstly, does your approach still invalidate the original password? If not that's really counter-intuitive. If I click a reset password button I want my passwor
by eterm 8y ago
Firstly, does your approach still invalidate the original password? If not that's really counter-intuitive. If I click a reset password button I want my password reset.
Secondly, it sounds like you just give auth based on this token so you can re-use your password change screen, but if your password reset screen doesn't ask for the current password it really ought to do so to prevent the risk of left over sessions being used to hijack accounts (e.g. not logged out public machines, stolen cookies, etc).
- eknkc 8y agoWell the idea is that you do not click a reset password button. You click on a forgot password button so this gives you a temporary one to use. Your second point is spot on and I do ask for the current password. The temp password also works there. This is counter intuitive but not a security issue as you mentioned. I guess I can just skip asking the old password in case this particular session uses a temp password. I like reusing the password change form. But there is something more to this. Our logs show that if a user needs a password reset, they tend to need it more than once. So, there is a pattern that some of our users simply keep forgetting their password. It might be the nature of what we work on though, most of our users log in a once or twice a month. That pattern gave me the idea that if they are gonna keep forgetting it, maybe I should not force them to reset. Let them use a temp password every single time. It’s like what Slack does with “magic login link” stuff where you can elect to receive a login link via email instead of using your password during login. I guess branding it like Slack does might be better though.