keithmj keithmj - 5 months ago 10x
PHP Question

Auto login security with PHP, how and why

I know this question has been asked many times, but I have a little different spin to it. It's a two part question.

First, I am implementing an auto login and I'd like to know where any holes are in my workflow.

Second, I'm unclear as to how a hacker would use the information they stole to compromise a system.

The first part, here is my workflow, what parts are vulnerable. Here are a few things that may, or may not, be helpful to know, I'm using PHP 5.6.21. I will be using their new hash API that uses the latest hashing technology and automatically salts it. I'm using the MVC architecture, so pretty much everything, other than my front controller and personal assets, are outside the root of the web server.

  1. A member logs in and selects the auto login checkbox

  2. A cookie with a hash value, that matches a hash value in the members table, is written to their browser. The cookie is only accessible from the members directory on the server, which is outside the root directory. Also, the httpOnly attribute is set.

  3. The next time the member logs in, there is a check to see if that cookie exists, if so use the hash value as a key to lookup the member in the member table.

  4. If they are found, log them in. If the cookie was set, but no matching record was found, then it's possible the cookie was tampered with. In that case, create a new auto login hash in the database and delete the cookie in the members browser. Then, force them to log in manually. If they choose auto login again, it goes back to step 1, this time using the new hash.

So, its pretty straight forward and no user data is stored in the cookie, just a meaningless hash.

The second part of my question is more general. Let's say a hacker somehow compromises the auto login cookie and gets the has code. What can they do with it? How can they use that to compromise my system?

In the case of SQL Injection, I understand that a data dump may be possible and a hacker could get a read only view of your database. In which case having hashed and salted passwords is a must! They can run those hashes through their evil machines and possible get your login credentials.

I was reading some security paper on why it is important to take all these measures. It kept saying that if a hacker get access to your database... But, if a hacker gets access to your database (with write privileges), none of this matters because you're screwed no matter how strong your hashes are.

Thanks for your time!


When a user is required to enter a username and password every time he wishes to login, the only information stored client side is a cookie containing the session id. Now this is prone to session hijacking, which works on the principle that being client side, a user has full control of the session id sent to the server and in a non-secure environment, this is transmitted via HTTP (w/o any encryption). If a malicious user managed to get a hold of another user's session id, he could "hijack" that user's session.

There are ways to prevent or discourage session hijacking. One method is to whitelist the IP Address and/or browser information in the session. If the session conflicts with the "whitelisted" information, the session has been compromised.

Using your "auto-login" logic, your server only requires a single hashed string to gain access to a user's account. Since this hash is stored client-side, a user can "submit" any string they want in place of the hash. If the connection is not secured (HTTPS), and the network the user on is not necessarily trusted, a malicious user can intercept the hash string. They could theoretically use that single hash string to login as the user.

At this point, your hash string, no matter how strong the algorithm was to generate it, is simply the new "username/password".

Most of the holes in the security depend on an insecure connection. If the connection is well-secured with a modern cypher-suite, I don't believe you'd be prone to the same issues.