3

I have a login system created in PHP. It currently doesn't have the "forgot password" feature and I would like to implement the feature.

For this I'm planning to do the following:

  1. When user submits the form with email on "forgot password" page, an email with a unique token of 50 characters is sent.
  2. The unique key generated is stored in the session cookie using
    $_SESSION['forgotPassToken'] = "tokenof50chars";
  3. The page asks to type the unique token sent to the user's email inbox.
  4. When the token is entered, code checks if the token on session and the one entered is the same.
  5. If same, a new session variable name forgotPassVerified is generated and is redirected to a page where user can enter the new password and submit.
  6. Password is changed and the session is destroyed. Pages asks user to login with new password.

My question: Is it safe to store the randomly generated token in the PHP session or should I use database?

I don't like to do this in database. That's why I'm approaching this session way.

Here are the reasons why I'm not using database for storing tokens:

  1. Some users (crackers) just submits the form with an email. They don't check the inbox.
  2. Save database space
  3. Reduce usage of executing SQL queries.
  • How long does the PHP session stay active? If the email takes a few hours to be delivered (not impossible), the session could expire. Another issue would be if the user closes the browser and the session id stored in a browser cookie is cleared, you would have no way of pulling the data from the session. – mikeazo Mar 18 '14 at 15:37
  • This is one of the questions in which I'll just say this: You're doing it wrong. Use the standard: A securely randomly generated token stored in the database, sent to the user's email, the verified and invalidated upon usage. – Adi Mar 18 '14 at 15:41
  • @mikeazo The PHP Session expires when the browser closes. @ Adnan Updated question with reasons. – Subin Mar 18 '14 at 16:12
  • What do you mean by update #2? You don't store each person's unique tokens. Don't pre-generate the tokens. I'm also doubting reasons 2/3. with 100 characters for token and 10000 users forgetting the password each day it's still only around 1MB. – domen Mar 18 '14 at 16:52
  • @domen Ok. Reason removed. So, Is it safe to store the uniquely generated reset password token in session ? – Subin Mar 18 '14 at 16:54
5

Is it safe to store the randomly generated token in the PHP Session or should I use database?

It can be if done properly. How is access controlled to the files that store the session information? This is especially a concern on a shared system.

There are drawbacks to this approach though. Sessions expire and email can be slow. If the user doesn't get the email immediately, they may close the browser, in which case the session id stored in the browser would be cleared. Then when they get the email and type in the secret, you can't validate the request.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.