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.
Improve this question
8
  • 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, 2014 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, 2014 at 15:41
  • @mikeazo The PHP Session expires when the browser closes. @ Adnan Updated question with reasons.
    – Subin
    Mar 18, 2014 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, 2014 at 16:52
  • 1
    To add another drawback: this might not work for some use cases involving mobile phones. Many email clients will open links in email client context, and I'm not sure that session is shared with "default web browser". Another odd case might be with multiple devices (I know I've reset passwords this way before).
    – domen
    Jan 24, 2018 at 15:57

1 Answer 1

Reset to default
4

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .