Auto login security with PHP, how and why [closed]

Question

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!

Answer 1

There are two parts to this:

1. Making sure your sessions are secure. Read this for a primer on session security, with configuration examples. Spoiler: HTTPS is mandatory, make sure you're using a CSPRNG for session identifiers, and you're regenerating session IDs during privilege escalation (and/or regularly).
2. Safely implementing a cookie-based authentication token that will transparently re-authenticate the user when they access your website with a valid cookie but without an active session. I've previously written extensively abut side-channel-resistant persistent user authentication.

The second part is more interesting, because many people stop at the "generate a random token, store in a cookie, and then look it up in the database" step.

You're safe to assume that your heavily-optimized database query isn't comparing strings in constant-time, like you need to be in order to prevent timing attacks.

The solution is to break your token into two pieces: One for the database lookup (timing-leaky), and the other for comparing in constant-time.

• The first piece (called the selector) is stored/indexed in your database table.
• The second (called the verifier) piece is stored in plaintext in your user's cookie, but is hashed (e.g. SHA256) in the database.

After retrieving the token based on the selector, you compare the hash of the verifier provided by the user with the stored hash, using hash_equals().

Each long-term authentication token should only be used once. Afterwards, a replacement should be issued to the end user. Logging out should clear the cookie, while the session should expire when the browser is closed.

This is only secure if you're using HTTPS with HSTS, and your cookies are set to HTTPS-only! (This means secure and httpOnly are both set to true.)

You can see an example of this system in action here and here.

Answer 2

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.