-2

hi there I read a lot about secure 'remeber me' php login

I want use this algorithm:

1- create a database for coockei like this:

$sql = "CREATE TABLE IF NOT EXISTS Cookie 
        (
            id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY, 
            pid INT(10) UNSIGNED NOT NULL, #user id
            token VARCHAR(254) COLLATE utf8_persian_ci NOT NULL, 
            expires INT(11) NOT NULL,   
            UNIQUE (token),
            FOREIGN KEY (pid) REFERENCES Profile (id)
        )   DEFAULT COLLATE utf8_persian_ci";

2- when a user login successfully, the system create a cookie with a random token with md5(uniqid(rand(), true)) and date of last login and user id

3- also md5(uniqid(rand(), true)) and date of last login and user id will store in MYSQL DB.

4- for second time, when user login,The system read cookie info and check with Cookie table. If it was ok the user will be login! and regenerate new token.

Dose this method is secure?

Dose a hacker can steal that token (form an user computer) and login with a fake cookie?

partiz
  • 1,206
  • 2
  • 13
  • 34

2 Answers2

3

2- when a user login successfully, the system create a cookie with a random token with md5(uniqid(rand(), true)) and date of last login and user id

3- also md5(uniqid(rand(), true)) and date of last login and user id will store in MYSQL DB.

In addition to what ScottMcGready says, I want to emphasize this point:

uniqid(rand(), true) is not a cryptographically secure pseudo-random number generator.

Adding md5() doesn't make it so, either.

Also, if you want to learn more about secure "remember me" cookies in PHP, the linked blog post sums up the current best strategy for implementing them securely (2015).

Community
  • 1
  • 1
Scott Arciszewski
  • 33,610
  • 16
  • 89
  • 206
  • 1
    Ditto. If you find it, spam the hell out of it as it's a complete misunderstanding and should be squashed without remorse. – ScottMcGready Sep 02 '15 at 01:12
1

There's a few issues here, let me try and explain why this is a bad way of achieving what you want:

Database cookie

Table wise, that looks okay. Be aware though that without more access to your code, I'm unable to tell if your system prunes tokens periodically or if the original token is ever overwritten. With this in mind, it's worth noting that INT(10) for the records in the Cookie table will have a maximum value of 4,294,967,295. If each token generated is added as a new row to your database, this could cause problems very quickly. For example on the token generation script - if a loop were to occur...

That being said, not much wrong with the table structure.

Hashing

Personally I wouldn't use md5() to generate tokens as the possibility for collisions would be rather high. From another Stack Overflow answer, this is what I'd consider pretty decent:

bin2hex(openssl_random_pseudo_bytes(16));

It uses OpenSSL for good... random-ness.

Storing it in the database

Why not store the current date instead of the last date? The current date could be used to provide an expiry and prune old tokens from the db (i.e. >24 hours). Also consider storing the IP address or another piece of information for traceability if anything foul is going on.

Retrieving login

This is where you're most likely to be attacked. Whatever login script you have should check for a number of things such as brute force attacks and deal with it accordingly. There is a very high probability that you will not plug all the holes and allow people to accidentally or intentionally steal another person's cookie.

So, if you really, really, really, really want to, you can create your own login/authentication system - my advice would be not to but your question was specific about your own method so I've tailored my answer to reflect that.

Final thought: If you're asking people on the internet if something is secure, it probably isn't.

ScottMcGready
  • 1,612
  • 2
  • 24
  • 33