CODEWITHSUNDEEP
phpsecurityauthenticationhash
inkd
inkd

Reputation: 1509

Is this user auth secure enough?

I am trying to move away from using md5() for storing and comparing passwords. So I want to start using password_hash().

Now, how I used to do it, was I would store the username and an md5 of their password in their session or cookies (if they chose "remember me"), and then check the database to see if any user existed with that username and md5'd password. I realize this is not very secure, which is why I want to stop this.

I can no longer do this because password_hash() always changes, so I cannot store a hash in their session and then check for it in the database, because I need to use password_verify on the unhashed password.

So my question is, if I store a hashed "session id" and "token" in the user table when a user successfully logs in, and then store that in the persons session/cookies along with the user id in order to check the database with, is this secure enough? When I say hashed "session id" and "token" I mean sha256'd or even md5'd hash of random large numbers...

Example:

User logs in -> hashed "session id" and "token" is store in the users cookies/session, and their row in the database is updated with the hashed "session id" and "token".

User visits site -> code checks to see if their "session id" and "token" exists in the database based on their browser session/cookie vars. If it does, it assumes that the row found represents the current user.

Any insight would be greatly appreciated.

Upvotes: 3

Views: 136

Answers (2)

Kirs Sudh
Kirs Sudh

Reputation: 298

For best password hashes and usage and yet simple to code is below example...

$salts= ['cost' => 12]; password_hash("Password", PASSWORD_BCRYPT, $options);

$salts is an array which combines miltiple times when password_hash() is used.

PASSWORD_BCRYPT is an algo which hashes the string with "$2y$" identifier and with blowfish encryption algo. This outputs 60 char of jumbled set.

Upvotes: 0

zachal
zachal

Reputation: 85

What I'd do is when the user logs in, generate a unique id for his login using uinqid() (http://php.net/uniqid) and then store this in a new table. Id then check this table to see if the cookie matches the uniqid stored in the table.

You'd have to make sure the table row is deleted when the user logs in again, but this would cause a problem if the user sets a remember me on multiple devices, so I'd set an expire date in the table for each id, and the login script would:

  1. SELECT * FROM 'UNIQIDS' WHERE $current_date_and_time > 'EXPIRE' and delete all results
  2. Check for the existence of a cookie. If there is one and it matches the uniqid, create a session on the computer, else show login page

Upon user login:

  1. Check if there is already a uniqid stored in the table
  2. If there is one stored, if the current date and time is past its expire date, delete the row
  3. If the one has expired generate a new one with a new expiry date matching the expiry date of the cookie you are generating. If the one hasn't expired, calculate the time between now and the time it expires and create a cookie containing its value and expiring in the time you calculated.

This is highly secure as it would be hard to fake this cookie, and it doesn't ever pass the users password information to the client machine.

For even more security, you can md5 the uniqid you generate but theres no real need, as it contains no important information.

This is rather complicated but if you take it one step at a time, it shouldnt be impossible.

Good luck!

Upvotes: 1

Related Questions