andieje
asked on
resetting passwords - how to prevent nefarious users guessing the reset url
Hi
Normally when i have a reset passsword function on my website I email the user a link to a page where they can reset theirpassword. I normally make this a random obscure name to stop people guessing the page but is there a safer way for a password reset page? All the solutions i have seen are more insecure than mine such as emailing the user a new plain text password.
Kind regards
Normally when i have a reset passsword function on my website I email the user a link to a page where they can reset theirpassword. I normally make this a random obscure name to stop people guessing the page but is there a safer way for a password reset page? All the solutions i have seen are more insecure than mine such as emailing the user a new plain text password.
Kind regards
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Click Reset Password link. Webserver makes a LONG random reset id, with 24 hours expiry, puts it in the database
Link is always the same, except the email address (or user id) with the reset id string posted. Webserver does a database lookup the data is correct (user id/reset id/expire date), and forward to the real reset page.
Have this page be hammer proof (block of page is requested multiple times with different id's)
Link is always the same, except the email address (or user id) with the reset id string posted. Webserver does a database lookup the data is correct (user id/reset id/expire date), and forward to the real reset page.
Have this page be hammer proof (block of page is requested multiple times with different id's)
hmm.. why not try TinyURL? It's super easy to implement, you can generate the URL with code, and your user will only see the TinyURL.
:)
:)
Because TinyURL always goes to the same page. No security there. All the password resets that I have seen work like Kimputer describes. The reset link/code is always sent to the email address of record.
I like Kimputer's solution, and I do it just a little bit differently It's still basically "security by obscurity" but it's very effective. To "guess" the way forward would require an attacker to guess the md5() string of information you probably do not know.
1. Client visits the "forgot my password" page
2. Page generates a $var == md5() of (the REMOTE_ADDR and the current timestamp)
3. Page sets a cookie with the var
4. Page form requests the client email address
5. Page responds by emailing to the client a URL that contains a link with the $var in the URL.
When client visits the URL, it checks to see if the cookie $var matches the link $var. If there is a match...
1. Page changes the client password to a random, unique string.
2. Page gives the client the random unique string and a link to the setPassword page.
On the setPassword page, the client has the opportunity to change the password.
There's some back-and-forth with HTTP requests involved in this design, but that's about it. If you want more, you have to get into two-factor authentication (but that's a whole separate issue).
The central dependency is the client email address. If I can get into your email I can change your password. That's true of most such applications.
1. Client visits the "forgot my password" page
2. Page generates a $var == md5() of (the REMOTE_ADDR and the current timestamp)
3. Page sets a cookie with the var
4. Page form requests the client email address
5. Page responds by emailing to the client a URL that contains a link with the $var in the URL.
When client visits the URL, it checks to see if the cookie $var matches the link $var. If there is a match...
1. Page changes the client password to a random, unique string.
2. Page gives the client the random unique string and a link to the setPassword page.
On the setPassword page, the client has the opportunity to change the password.
There's some back-and-forth with HTTP requests involved in this design, but that's about it. If you want more, you have to get into two-factor authentication (but that's a whole separate issue).
The central dependency is the client email address. If I can get into your email I can change your password. That's true of most such applications.
ASKER
thanks a lot
Deals with introducing steps.
The user who attacks would have to have a few examples of the reset URL you provide to try and predict/guess.