Forum Moderators: coopster
For now I send user & pw from a form to get authenticated. Then php compares those values to vars in the file:
$user = "username";
$pw = "password";
if ($user == $_POST["user"] && $pw == $_POST["pw"]) {do authentication stuff}
Is this a really bad idea? Could anyone just "read" the php as is on the server and grab the pw?
I`m not a security expert but I don`t see how anyone could snatch the password so I guess you can use it without a problem!
/usr/local/apache/htdocs/login.php-> <?include "../../safety/login_info.php"?>/usr/local/safety/login_info.phpIf somebody gets the level of access required to bust out of your web directories, then they've got it anyway, but at least it makes it much more difficult.
If there are other users on the box(ie, shared hosting), then you should determine if safe_mode is enabled in PHP. If it is not, anyone on the box can cause a script of theirs to take a peek through any file that is world readable or readable by apache. (assuming unix/linux)
You can determine if safe_mode is on in php by creating a .php file in some directory that looks like:
<?php
phpinfo();
?>Run that page from the site, and search the code for safe_mode. Next to it, you'll see an On or Off. You're only interested in the Master Value column, as enabling it locally would only keep your php out of others files, but not the other way around.
It seems I have at least 3 options:
1)put it in external file - which they could find anyway.
2)put in db - which they could get into anyway if they can see my connection scripts
3)encrypt it somehow - but how?
Other better, simpler options?
3)encrypt it somehow - but how?
That's the best option, usually.
Don't save the password, ever. Save an MD5 (or similar) hash (checksum etc) of the password.
Then, when a form sends a password, you MD5 that and compare it with the saved MD5 value.
Big advantage: you never save passwords.
Potential flaw: if users are stoopid enough to use easily guessable passwords, it doesn't help. (and if someone steals your password file, they can compare the MD5s with the MD5s of common passwords to find what your users are using).
Support disadvantage: if they forget their password, you have no way of telling them what it was. So need some mechanism for changing it.
The problem with the client making a new password, is that they need authenticated access so I know its them making the change. I guess the best way to do this would be to generate a random password and send it to them in an email, after which they would change it to something better?
If they know their password and want to change it, then give them a page on which they enter the old one and the new one. (Tradition has them entering the new one twice to avoid typing errors). Obviously you don't accept the new password if the old one isn't right.
But what if they've forgotten the password?
Then yes, sending something to their registered email address is the traditional response.
Sending them a new password is the easiest. But that can open you up to some nuisance attacks. If WMW used this mechanism, I could sit here all day having emails of new passwords being sent to every userid.
That can be reduced by having the user have to enter their email address on the "forgotton password" page. And only sending it if the email address is what you have recorded. Of course, that's really annoying if they've also forgotten their email address, and continue using their old password.
An alternative to changing the password and emailing it to them is to send a temporary URL to their email address, something like:
www.example.com/change-password.cgi?id=6442374737848957578938537
That URL will work for 24 hours and let them enter a new password without first entering their old one. You need to write the CGI for that, of course.
That way, even if I do attempt my nuisance attack, their password only gets changed if they visit the temporary URLs. Otherwise, they can just delete the emails.
There are a few other subtleties -- but you get the picture.
Back to my initial post: I'm still unsure as to who is able to see the actual php code in my files, if anyone? For example when a spider/crawler/indexer/bot crawls my site, do they see the php source or the output?
all processing is done on the server and only the generated output is sent to the browser/spider etc
For things like user accounts, I'd say that stuff should be in a database.
For (1) I would follow the advice of StupidScript:
put the sensitive information into an include file strictly outside the webserver's document root.
The webserver would not serve pages outside the document root.
Normally, the web server just interprets the PHP and does not leak out the source code. If, however, your provider goofs and mangles the apache's configuration one day, after a major software update perhaps, the webserver may forget about the php and give out all pages as plain text to the public including all php sources uninterpreted.
For (2) you solely depend on the skills of your hoster.
The php-safemode-setting is just a start, but would not prevent other users snooping around using other means (like a perl cgi-script) instead.
If your web-business is important for you, then I would recommend to get rid of any shared hosting and invest into a dedicated server.
Regards,
R.
The main security issue here is the PHP file as it resides on the server.
Threats include (but are not limited to):
1) Hacker spoofs your root account, and can view the raw files sitting anywhere on your server.
2) Hacker gets access to the actual machine
3) Regular shared server user navigates out of their own directory into yours, and can view raw files.
In those three cases, no file or database is safe if the data is not encrypted.
4) Regular shared server user succeeds in including your PHP files in their own files by assuming the server's directory structure and there is no "jail" in place to keep them from accessing your files
In this case, the user may succceed in copying files into their own directories for viewing or delete them from your directories.
There are many ways to accomplish the above hacks, but don't lose too much sleep over it. What the heck?
Encrypting (using MD5() or the PHP crypt() function's DES/EDES/Blowfish encryption) will provide greater security in case the system is completely compromised, with a couple of useability limitations as has been described, and with a little extra work.
The database is a little more secure than a file with or without encryption, because you can set separate access permissions for the db, but even that is hackable.
It ain't a perfect world. Take the most extreme steps you feel comfortable supporting, for now. As your application needs more security, move further down the line to the next-most extreme step.
Sooner or later you'll see that (unless you're a bank or something) people just don't want to work that hard to hack your application.
No sleeping on the job, but an occasional nap or two is okay. :)
