开发者

My forgotten password strategy - Any showstoppers here?

开发者 https://www.devze.com 2023-02-17 14:36 出处:网络
There\'s a lot of similar questions, but I didn\'t see this: I\'m using users eMails for username - since they are unique yet memorable (not shown).

There's a lot of similar questions, but I didn't see this:

I'm using users eMails for username - since they are unique yet memorable (not shown).

And the send_a_new_random_password for the "retrieval".

BUT, that would allow a disgruntled ex to change a users password again and again : (开发者_StackOverflow社区

To get around this (here it comes) I want to have 2 "correct" passwords in the user-record

- PASSWORD and newPASSWORD (both hashed with PHPass 0.3)

At the next successful login (checking both), I save the used one as PASSWORD, and dump newPASSWORD - Thus rendering the click_this_obscure_URL_to_enable process unnessecary : )

Am I overlooking something ?


The idea is to not actually reset the password on the account but send a confirmation email containing a reset link. This way only the person with access to the email account could actually perform the reset. (Unless the disgruntled ex can also access the email :P)


It's standard practice to only active the new password if the user clicks a link in the password change email. Your mechanism looks very similar to that. Your mechanism looks largely fine to me.

If you don't want to send out a password in the email(it's unencrypted after all) you need to use the reset link mechanism or use a temporary password the user must change at the next login. But I think for most websites sending out the password in an email is the least of your security worries.

0

精彩评论

暂无评论...
验证码 换一张
取 消