Home/ Questions/Q 3624222
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T23:28:51+00:00

So this is basically a reassurance that I’m doing the whole registration/login process right

  • 0

So this is basically a reassurance that I’m doing the whole registration/login process right as far as hashing/salting goes.

I have a users table with the fields password, salt, token (obviously there are others but this is the most important). Upon registration it generate a random salt, and a random token, and it puts in the password field this:

hash("sha256", $theirpostpassword.$randomgeneratedsalt);

That random generated salt and token are stored in their respective fields in that users row in the table.

So upon login I select the salt ONLY from the users row with the username they specified. I then do a count query of how many rows have their post password concatenated with their specific salt, and then I log them in. Pretty sure I have that part down.

Now I was thinking to validate their login on every page I would have a function ran every page that checks their cookie to see if the format of id-username-token matches the row in the database. Meaning that every login it sets their cookie with those credentials.

Now the only thing I can think of to make it better is change the token every valid login?

Thanks for the insight guys.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Yes, you should definitely be changing tokens with every login. Otherwise a token stolen once is an account stolen forever. Users expect that logging off secures their session from attack by invalidating their cookies or other data.

    Rather than the token being random, you can make it serve as a signature, by generating it from a hash of the user id, session expiry time, and whatever else you want in the cookie, plus a salt (just like the login system). This salt doesn’t have to come from the database, but it can. It could be a hardcoded string (sometimes called a “pepper” I think). Remember to treat the cookie as invalid if it’s past the expiry time. That’s why the token should be a signature, to make sure they didn’t spoof that data.

    • 0