zathros

If you're viewing details of the certificate and you see that it was issued to the common name (CN) localhost.localdomain, that means someone didn't do a good job making the certificate (or maybe used a default). As you suspected, that should be the hostname of your server (serverXX.totalchoicehosting.com). Note that if your address bar says "******" and the server that the certificate is issued to is "serverXX.totalchoicehosting.com" you will get messages from the browser, and this is normal, correct behavior. If you're sure the certificate was issued to localhost.localdomain, I'd suggest you raise a support ticket. Everyone on your server would have this problem if the common name is incorrect. I run sites registered on servers 78 and 91, and both of those have certificates issued to the correct server names. Also, I would not recommend following the advice given above. By disabling the notification of invalid certificates in your browser, you would be completely losing much of the point of the authentication provided by SSL. Even though you know your site will bring up these messages and you accept that for your site, you don't want to one day go login to your bank's website and miss the message that their certificate is invalid. I know it sucks that messages come up, but that's the price you pay for security. If you disable the checking on the clients, you won't have a clue when something goes wrong with SSL on any site. The same goes for always blindly accepting those dialog boxes that come up telling you about SSL problems. If you're not concerned about a particular site too much, that's fine... but if you do it all the time and never check it out, then you'll click past something important.

You're right about that. If you're after protecting images and stuff like that, you should also stick a blank index.html in the directory or do some .htaccess magic to prevent directory listing. If you don't use super-obvious file names for your images and all the pages that display the images are protected with the above session system, I think it'd be practically impossible for someone to guess the direct link. If it's not possible to prevent giving the link away in your other pages, it's still probably "good enough" depending on how important it is to protect these things. :-)

Hey all. Thanks for the info about referrer tags, editor. Reading the thread, I thought that solution would probably work for you. However, you still probably shouldn't rely on it for super important stuff, since, like you mentioned, the referer tag can be altered with software working with the browser. Actually, for what it's worth, I really liked TCH-Lisa's idea. (Though, I might be biased because I've done stuff like that a lot in PHP) I think it'd be pretty easy, and the best part is that you could use the system for more complex stuff later if it turns out you need to. (For example, a full login system or displaying different content based on a user's level... etc) Here's what I'd do: First: If you aren't familiar with this, read a little about PHP sessions at php.net Next, try something like this in your mydomain/page.html ><?php session_start(); if (!isset($_SESSION['active'])) { $_SESSION['active'] = 1; } ?> CODE OF WEB PAGE HERE And try something like this in your mydomain/subdirectory/file.html ><?php session_start(); if(!isset($_SESSION['active']) || $_SESSION['active'] != 1) { echo "Direct page access is not allowed."; } else { ?> ENTIRE HTML OF WEB PAGE HERE <?php } ?> Oh, and unless you put in a .htaccess that you want .html files parsed with PHP, you'll have to change the extension of your files to .php. It's not fullproof, and perhaps someone else has comments on it, but I hope it helps.

Hey there. I'm new to TCH and all, but I have done a few things with MySQL and PHP. While I'm not an expert on all the PHP security issues, I think I have a decent understanding of what's going on, and I've done a couple authentication systems in PHP (with and without MySQL). I have a few questions/comments about the system you're designing, and I'll post them in response to your summary. So far, I haven't needed to use cookies in my systems, but it looks like you're not storing anything that could cause problems that are too big if it were compromised and used elsewhere. I guess the worst that could happen is maybe somehow the cookie gets "stolen" and someone is able to login as someone else. No? This whole thing seems like overkill to me. All PHP code gets parsed by the web server as it brings up a page. I think it would be difficult for PHP to fail in such a way that it displays the source of the PHP file without bringing down the rest of the web server. Is that incorrect? Includes are cool for modularity, but I don't see why it's necessary to bury stuff into includes for security. Maybe I misunderstand what you're doing. The establishHackCheckL#() and runCheckHackL#() functions sound like they would be useful to force someone to come through a specific entry-point to the site. However, I don't understand why you wish to do that. Are you only authenticating users at that one point? I would suggest that each page verify that a session has been established and react according to what kind of user is logged in. Would that not be good enough? From what I understand of what you're doing, it seems like you've got a pretty good system. It might be a little too much, though, and that could make it rather complex... which doesn't have to be a bad thing. Just as long as you've got it straight and know what's really happening. I don't know what specific tutorial you're referring to, and I'm not familiar with that site, so I don't know exactly what they did. However, I would suspect that this can be accomplished well enough simply by placing the necessary files in a directory that is not under the web server's wwwroot. In the case of the TCH site, this would mean not under your public_html directory. You would then give the complete path to the file in your PHP include or require statement. As long as the files are readable by the user that the web server runs as, you should be fine. This might be easier than messing with httpd.conf, which we wouldn't have access to. However, you might be able to do something similar to whatever they did with a .htaccess file. We'd have to know exactly what it was they did and do some research to find out. Also, you might have to figure out what the full path to your user directory is for that last thing. Some TCH support people might be able to answer that question. Basically, you want to know what is the full path to the home directory? /home/username, maybe? You could also find this out with a test script that prints out the location of the current directory. Personally, I think the PHP authentication is what I'd consider good enough. It is my understanding that attacks against sessions and cookies do exist, but you said you don't have super-critical information in there. Plus, I think you're doing good not putting anything that would give away the user/password pair in your cookie. I'd think the directory authentication is not as flexable as your PHP stuff, and I don't consider it more secure as long as the PHP stuff is done right. Does anyone else have input on this? Anyway, unless you're really using SSL for all this in addition, it's rather pointless to spend a huge amount of much time on the authentication system. Someone could just snatch your users' passwords as they login, if it's sent in cleartext. Overall, I'd say the system sounds pretty good. Let me know what you think about my comments/suggestions.