3

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.

inkd
  • 1,421
  • 1
  • 13
  • 16
  • You can use Salted Password Hashing. – Praveen D Jun 17 '15 at 13:47
  • 2
    @PraveenD - password_hash() generates a salted hash already.... what are you actually suggesting? – Mark Baker Jun 17 '15 at 13:49
  • Salt should be random with each hash. – Praveen D Jun 17 '15 at 13:49
  • @PraveenD - password_hash() generates a salted hash where the salt is random with each hash already..... OP is already aware of this, perhaps if you explained what you mean – Mark Baker Jun 17 '15 at 14:01
  • Even password_hash() will generate random hash code if we use 3rd arg. Like `$salts = [ 'salt' => 12, ];password_hash("password", PASSWORD_BCRYPT, $salts)` – Kirs Sudh Jun 17 '15 at 14:04
  • Well, the most secure thing I can think about is storing the user's password in a cookie (by encrypting it) using a STATIC salt, so that the output will always be the same and then use password_verify on the decrypted password. – briosheje Jun 17 '15 at 14:06
  • 1
    static salt completely nullifies the effect of using password_hash to begin with. if i was going to do that i might as well just stick with using md5(). – inkd Jun 17 '15 at 14:11
  • Well no, not really, as long as you use a long and complex salt you should be secure enough. You may want to use a secure key or something like that aswell, I don't think you have any other choice but that, because as long as every single hash is different everytime you literally have no other ways, if I'm not wrong. – briosheje Jun 17 '15 at 14:15
  • Your question seems to be less about the authorization than the 'remember me' functionality. Check out [this question](http://stackoverflow.com/q/244882/1146608) and its links. – Patrick M Jun 18 '15 at 15:35

2 Answers2

1

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!

zachal
  • 85
  • 1
  • 10
  • The token should be hashed before storing in the database, otherwise an attacker with read access to the db (SQL-injection) can read the token and impersonate the user. Because the token (20+ random characters) is a very strong "password", one can use a fast unsalted hash like SHA-256 which makes them comparable. – martinstoeckli Jun 18 '15 at 14:52
  • Not necessarily. If you select all rows from the table, not giving the end user access to the SQL Statements, creating an assoc and using a for/loop to let php search the assoc, instead of letting mysql search the table before returning the assoc, it leaves the table invulnerable to SQL Injection. After that, if your SQL gets hacked, you have bigger problems than the security of hashes. – zachal Jun 19 '15 at 20:59
  • It is not necessarily a query to the table with the tokens, which can reveal the hashes, every SQL-statement must be secured. Have a look at the example in my [tutorial](http://www.martinstoeckli.ch/hash/en/hash_sqlinjection.php). If you use a third party library, you would have to test this code too. And even then, there are other ways the tokens can be lost, a discarded server, a backup, ... – martinstoeckli Jun 20 '15 at 05:34
  • My apologies sir you are correct. The uniqids should be hashed for security as well as any other potentially sensitive information, but it would be prudent to also make sure to take precautions against sql injection, because any determined hacker can crack a hash given enough time. Also make sure your uniqids and cookies expire rather frequently to prevent somebody from bruteforcing your system by repeatedly creating fake cookies with different values. – zachal Jun 21 '15 at 06:24
0

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.

Kirs Sudh
  • 373
  • 2
  • 15