PHP Secure Session

Question

I'm creating an application similar to phpmyadmin (database management UI). The user needs to authenticate himself against the database and the application needs to store the credentials somehow. SSL is not an option for all installs.

• Idea 1: User sends credentials, application stores username and encrypts password using predefined blowfish secret key (config.ini.php) - This is what phpMyAdmin does.
• Idea 2: Login form creates random blowfish secret (javascript), user sends login credentials, application encrypts user/password and stores them server-side in the session, secret key is stored into cookie and sent for every request.

Idea 1: Problem if server security is breached. (Key is in config, session data in /tmp)
Idea 2: Problem with man-in-the-middle attack. (Key + credentials are sent)

Any other suggestions? Criticism?

Rattlebox

Without SSL it's vulnerable to man-in-the-middle anyway. So, just relax & enjoy. You can't help it. – Halette

Idea 1: If the server security is breached, I would think the secret key would be the least of your worries, no? – Simulator

SSL/TLS are complex beasts. It's extremely difficult (if not impossible) to reproduce their functionality using JS only on the client. – Lump

Col. Shrapnel: So? Just trolling? Capt Otis: That's right. But even a normal user with access to /tmp might have access to session data. Sabeen Malik: Then you're logged out because you get a new session? (No session cookie) NullUserException: I'm not trying to rebuild SSL/TLS. Just trying to get the best solution for my problem. – Rattlebox

@Rattlebox He has a point. You can't get around MITM without proper authentication, which can't be done without SSL. – Lump

Sabeen Malik: You get it wrong. I store user/password into a PHP session (encrypted with the key). So someone who gets access to the session data doesn't also own the key. If you switch browsers/pcs you simply loose the session and need to login again (new key gets generated). – Rattlebox

@Rattlebox .. ok my bad, thanks for clearing that up :) – Orji

Answer 1

The problems you stated are not solvable in the absolute sense. No server is 100% secure and every "man-in-the-middle" attack can be taken a step further.

I suggest being more specific in defining server security requirements. Otherwise every solution will appear lacking because in absolute terms they always are. For example, use session_save_path() and put the session data somewhere else if "/tmp" worries you.

When it comes to thwarting "man-in-the-middle" attacks, then the uber-approach would be to use a one time pad, pre-shared offline. That is what security agencies do - all other options leave your application more or less dependent on the benevolence of devices between your server and the useragent. So you need to decide about your level of tolerance.

One reasonably safe authentication method is zero knowledge proof. It requires your application only to know the public key of the user. No passwords, no secrets. The point is that when a user wants to log in, your application should respond with a random message encrypted with the public key of that user. If the other side sends back the correct random message, then it indicates the possession of a matching private key. Hence the user is authenticated. To prevent eavesdropping, make the useragent encrypt the correct answer with the public key of the application before sending the answer back. However, implementing the necessary functionality and a decent GUI for all this will not be a trivial task.

Woodbury

Answer 2

For idea 1, you said even a normal user as access to the session file, this maybe true, but you can always set where the session saves the data and make the accessible only by your domains user / group (given you create a new account per domain). This would ensure that someone would have to breech an exploit in your code to gain access that data. So it will ultimately boil down how secure you code your code (or the code is you use).

Commandeer