Forum Moderators: coopster
I was wondering if the following code is a secure method of keeping out the unwanted users.
I have my entry page setup similar to:
<?
session_start();
header("Cache-control: private");
$name = $_POST['name'];
$password = $_POST['password'];
$_SESSION['name'] = $name;
// insert code to retrieve $databaseName and $databasePassword from database
if($name == "") { // insert form code to let user sign in and exit
if($name == $databaseName && $password == $databasePassword){ // Send user to main page
}else{ // tell user ERROR: Wrong Username or password
}
Then on each page therafter I have:
<?
session_start();
header("Cache-control: private");
$name = $_SESSION['name'];
// insert code to retrieve $databaseName and $databasePassword from database
if($name!= $databaseName) {
//access denied and exit
}
// continue with rest of page
Also, what would be wrong with having php read a username and password from an .htpasswd file? I have tried this and it works for me. I am just wondering what other implications I might encounter using an .htpasswd file in this manner.
Thanks in advance for any insights!
IamStang
If a malicious user manages to hijack a session in your scenario they can look and act like a valid user. I use a unique fingerprint (we'll sort of unique) to identify the session as a valid session:
When logging in I register a fingerprint based on the user's user agent, and a unique non-changing seed and I md5 hash the output (you could double hash it if you are paranoid).
$_SESSION['fingerprint'] = md5($seed . $_SERVER['HTTP_USER_AGENT']);
Before I allow other scripts on pages to access the other session data I match the fingerprint using the unique seed I have set for the user against one I generate from scratch on each page (much higher chance of making sure that you have a valid user ). This method is not the only method, but I find that it works quite well, and will at least make attempts at session hijacking much more difficult.
You can also change your PHP session handler to a database and encrypt your session data (for added, even more paranoid protection).
Your method is good, it goes part of the way there, you just need to take it a step further. I'd probably cut the need for the database call on every page, if someone hijacks your session, it isn't going to stop them from being able to access the site (since they are already using a valid $_SESSION['name'] variable stolen from one of your valid users). I've read not to wholey trust any data, even from your registered users. Their session/cookie might be compromised and they won't even know about it.
I don't see any reason why you can't use your htpasswd file to store your passwords either, as long as the system is relatively small, and the file cannot be read by visitors.
Thank you very much for your insights. I can see that I still have much to learn about PHP. However, your input gives me a direction to start.
I had a feeling that the method I have implemented wasn't quite as secure as I had read in other websites. But, I shall look into your suggestions as a way of further tightening the doors of my pages.
Oh! And before I forget, I have tried to access an .htpasswd file on my server from my pc at work and basically get "Access denied". I say basically because I cant remember exactly what the error was. LOL. (Was a long day at work). Thus, I will continue to use this method of username/password storage until I run into a problem with it.
Thanks again!
IamStang
Basically, when registering a session you generate this fingerprint as an extra piece of information to verify the user's identity:
A user's session should contain an id or name that you use to uniquely identify a user in the database, and the fingerprint. When the site is accessed and a session exists the page recreates the fingerprint using a unique `seed` (let's say its the user's id or username just as an example) and then matches that against the fingerprint that has been stored in the session. If they match, then the page assumes it is a valid session and allows the user to proceed.
The reason I don't use an IP address is that a user's IP address can change during a session, all depending on what the user's ISP is doing, or whether they are using some sort of proxy. Granted, it's probably not that great a percentage of users, but it's enough for me to want to use the http user agent instead.
The user agent isn't unique of course, but there are plenty of different ones around to make it difficult for hackers to use to break the fingerprinting method. If you wanted to strengthen it even more, then add more stuff into the fingerprint hash that is unique to the user.
I won't recommend this as your only protection against spoofing etc, but it'll make your site less of an easy target.