security concerns

[sim_pack]

how secure are php codes/scripts when they are deployed in a server (or when they become online)? if i put constants and/or passwords in my php codes, will they be visible and be 'sitting duck' targets for hackers?

[Will Gresham]

Your script can be as secure or insecure as you want.

Generally, the end user would not see constants or any of the actual code as this is executed on the server. All the end user should see is the output of any functions in your script.

If you are worried that a function may output some important data, use an @ symbol before it to suppress the standard errors:
@mysql_connect("...", "...", "...");

Or better, add error handling into your code to make sure that if an error occurs then you have a specific response for it.

[sim_pack]

thank you for the information, xan. it was a great help..

[darkagn]

Also, make sure that you never send unencrypted passwords via GET as they will be visible in the URL. There are also hacking tools which allow the retrieval of POST data, so watch out for that too.

[cwarn23]

Also, make sure that you never send unencrypted passwords via GET as they will be visible in the URL. There are also hacking tools which allow the retrieval of POST data, so watch out for that too.

Even better yet, use javascript to encrypt the passwords before sending it over $_POST. This way if the post data is hacked the data is still encrypted. This sort of hack attack can happen when a hacker attaches a device to a fiberoptic cable to scan data running past. Also as a security question, is there any security difference between the following two codes because a tutorial years ago told me there was but find hard to believe.

mysql_connect('localhost','root','password111');

//or

$host='localhost';
$user='root';
$pass='password111';
mysql_connect($host,$user,$pass);

Those are the two scripts but the tutorial (I forget where) says the second script should be more secure although I don't see how. And it was also said in the tutorial that it would be even more secure to place the variables in an include() file. Is that true or just a myth?

[kkeith29]

Even better yet, use javascript to encrypt the passwords before sending it over $_POST. This way if the post data is hacked the data is still encrypted. This sort of hack attack can happen when a hacker attaches a device to a fiberoptic cable to scan data running past. Also as a security question, is there any security difference between the following two codes because a tutorial years ago told me there was but find hard to believe.

mysql_connect('localhost','root','password111');

//or

$host='localhost';
$user='root';
$pass='password111';
mysql_connect($host,$user,$pass);

Those are the two scripts but the tutorial (I forget where) says the second script should be more secure although I don't see how. And it was also said in the tutorial that it would be even more secure to place the variables in an include() file. Is that true or just a myth?

Very true. All sensitive data should be stored above the web root. Along with classes and other functions. Think if something happened to the server and it stopped parsing php and your code was presented in plain text. If everything is where the user can't get to it there is no way they can look through it.

Also,

Passwords should always be hashed, no matter what.

If you are sending info that you wouldn't want intercepted you should be on a secure connection (https) using a ssl certificate. The day rsa keys are able to be decoded is the day the world collapses.

The company I work for forces us to use ssl for user login, members areas and registrations. You should do the same, if you can afford it.

If you are wanting to store credit card info or ssn numbers, don't. If you must then you will need a virtual private server and heavy encryption. There are laws for this stuff.

[kkeith29]

[EDIT] Duplicate post somehow

[digital-ether]

Even better yet, use javascript to encrypt the passwords before sending it over $_POST. This way if the post data is hacked the data is still encrypted. This sort of hack attack can happen when a hacker attaches a device to a fiberoptic cable to scan data running past. Also as a security question, is there any security difference between the following two codes because a tutorial years ago told me there was but find hard to believe.

mysql_connect('localhost','root','password111');

//or

$host='localhost';
$user='root';
$pass='password111';
mysql_connect($host,$user,$pass);

Those are the two scripts but the tutorial (I forget where) says the second script should be more secure although I don't see how. And it was also said in the tutorial that it would be even more secure to place the variables in an include() file. Is that true or just a myth?

Using JavaScript to encrypt passwords is not something I'd recommend. Anything that is client side can be bypassed. An attacker sniffing the network can modify the HTTP request response to their benefit.Very true. All sensitive data should be stored above the web root.

I think you meant below the web root?
It is very useful to practice this. Not just to remove the possibility of the HTTP server accidentally serving the file as text, but also to disable remote access of the PHP files in an order not intended.

Imagine having an index.php where you want all requests to be made. Then you have page2.php

On this page you have some variables that should have already been defined. If page2.php was accessed directly from the web, instead of through index.php then you have unintended behavior.

[cwarn23]

Using JavaScript to encrypt passwords is not something I'd recommend.

Well I think you mis-understood exactly what I meant. The process I was refering to was that javascript encodes the data first then php decodes it then php re-encodes the data.I think you meant below the web root?
No because this way the user cannot access the file when apache is displaying the php code instead of html code. A rare problem but does happen. An example of including the files from above the web root:

include('/home/exampcom/phproot/file.php');

Where in that example the folder phproot is a directory with php files which is not in the web root to prevent any access at all.

[Will Gresham]

Well I think you mis-understood exactly what I meant. The process I was refering to was that javascript encodes the data first then php decodes it then php re-encodes the data.

I would agree with digital-ether on this.

I always browse in Firefox with NoScript enabled (which means JavaScript is disabled for untrusted or unknown sites)

Lets say I visit your site with Javascript off, I enter a password which is not encoded before sending, meaning that your PHP script will get an unencoded password and will try to decode it.

Also, if you are encoding with JavaScript, an unfriendly user would be able to see exactly what you are doing and could reverse it anyway.

As a rule of thumb, I use JavaScript to make things 'pretty' after I have completed a project. I would never rely on JavaScript to handle even the smallest part of the security on any of my sites.

[cwarn23]

Well the only thing is that the value javascript encodes isn't the value that's stored in the database. Php would have to change that value to something like a hash. Also as for the problem of javascript being disabled - perhaps Java or Flash would be a better language.

[digital-ether]

Well I think you mis-understood exactly what I meant. The process I was refering to was that javascript encodes the data first then php decodes it then php re-encodes the data.

I actually do understand what you're saying.

Let me give you an example of why you should not rely on the client hashing passwords for you, unless you can verify the integrity of the data transmitted.

Sever has a page, login.php
It has a Login form, and field, "password".
Server also sends some JavaScript that hashes password.

Server sends this to a client via a HTTP response:

An attacker has managed to take over the TCP session between the client, and server. Thus all HTTP requests are being proxied through their machine.

Attacker's machine has a script, that removes the javascript that hashes the password.

Client machine receives form, with no hashing. User does not realize that when they submit the form, they have sent a plain text password.

Attacker receives the plain-text password. Attacker encrypts the password with the algorithm expected by the server. Attacker forwards the HTTP request to the server.

The server does not realize that they have made the users password available to a remote attacker.

The reason TLS is able to keep the data safe, is that it ensures the integrity of the data. So an attacker cannot modify a HTTP request, nor should they be able to read it.No because this way the user cannot access the file when apache is displaying the php code instead of html code. A rare problem but does happen. An example of including the files from above the web root:

include('/home/exampcom/phproot/file.php');

Where in that example the folder phproot is a directory with php files which is not in the web root to prevent any access at all.

I was merely commenting on the use of "above", in "above the web root". We are referring to the same thing here, it is just that I view the directory structure as a tree, while you're viewing it as an inverted tree. Thus when you say above the web root, I say below the web root.

I think generally programming refer to hierarchical structures as inverted trees, so I think the better term is "above the web root".

[cwarn23]

I actually do understand what you're saying.

Let me give you an example of why you should not rely on the client hashing passwords for you, unless you can verify the integrity of the data transmitted.

Sever has a page, login.php It has a Login form, and field, "password". Server also sends some JavaScript that hashes password.

Server sends this to a client via a HTTP response:

An attacker has managed to take over the TCP session between the client, and server. Thus all HTTP requests are being proxied through their machine.

Attacker's machine has a script, that removes the javascript that hashes the password.

Client machine receives form, with no hashing. User does not realize that when they submit the form, they have sent a plain text password.

Attacker receives the plain-text password. Attacker encrypts the password with the algorithm expected by the server. Attacker forwards the HTTP request to the server.

The server does not realize that they have made the users password available to a remote attacker.

The reason TLS is able to keep the data safe, is that it ensures the integrity of the data. So an attacker cannot modify a HTTP request, nor should they be able to read it.

It is only this part of the situation that makes that possible.Attacker forwards the HTTP request to the server.
If however the attacker enters the password into the webpage, then when javascript and php both encode the password, because javascript has encoded it twice, the password will not match. Keep in mind php still encodes the password with this system. It is an additional layer of security.
Edit: But it is probably best if Java or Flash is used.

[digital-ether]

It is only this part of the situation that makes that possible. If however the attacker enters the password into the webpage, then when javascript and php both encode the password, because javascript has encoded it twice, the password will not match. Keep in mind php still encodes the password with this system. It is an additional layer of security. Edit: But it is probably best if Java or Flash is used.

Having Java or Flash do it still doesn't make any difference. It is still client side.

The problem here isn't the encyption/hashing. It doesn't matter how many times you hash the password. In fact, hashing a password twice makes it less secure.

The problem here is data integrity. If you cannot ensure the browser that the data you sent it has not been modified.

TLS ensures this: http://www.javvin.com/protocolTLS.html

Hashing on the server side, only protects you against viewing of the data in storage. Like someone viewing passwords your database. It does not protect you against the sending of the password from the client, so you can leave it out in that context.

The hashing of the password on the client side, does protect it from viewing while sending to from client to the server.

However, without ensuring the integrity of the data being received by the client, then the hasing of the password will not occur in the first place. So the password will be sent as plain text.

In fact a lot of sites will hash passwords on the client with JS. For example Yahoo! login (MD5), and Meebo IM (SHA-256 and RSA).

sources:
Yahoo: https://s.yimg.com/lq/i/reg/js/login_md5_1.1.js
Meebo: http://js.meebo.com/script/meebo_v78.js?1252058884

However, both use TLS to transport the login data. Yahoo! has the whole login page under HTTPS.
Meebo however, only has the login form, under HTTPS.
http://www.meebo.com/security/

I would not recommend what meebo does. In fact their not putting the login page under TLS makes their use of TLS useless, but that is a different discussion.

[cwarn23]

The hashing of the password on the client side

The thing is, itsnot hashing on client side. It's hashing on server side but using a reverible encoder on client side. I'll write an example so we can get over this loop hole.

[cwarn23]

Here is the example of secure password transfer and storage:

<head><title>Secure Post Transfer</title><script>
function sendpost() {
    var data=document.getElementById("data").value;
    data=data.replace(/--|-\+\+\+2\+/,"---|-+++2+").replace(/--|-\+\+\+8\+/,"---|-+++8+").replace(/\+\+|-\+--8-/,"++|-+--8-");
    data=data.replace(/([0-9]+)/g,"--|-+++2+$1--|-+++8+").replace(/([0-9])/g,"--|-+++8+$1--|-+++2+");
    data=data.replace(/([a-z])/g,"++|-+--8-$1++|-+--8-");
    document.getElementById("data").value=data;
    document.dform.submit();
    return true;
    }
</script></head><body>
<form name="dform" method="POST">
<textarea name="data" id="data" style="width:400px; height:150px;">Add some random text in here aza</textarea>
<input onclick="javascript:sendpost();" value="Search" type="button">
</form><?
function truehash($hash) {
    return hash('crc32b',substr(hash('whirlpool',$hashzzz),64));
    }
$var=stripslashes($_POST['data']);
$var=str_replace(array('--|-+++8+','--|-+++2+','--|-+++--|-+++8+2+','--|-+++2+','--|-+++8+','++|-+--8-'),'',$var);
$var=truehash($var);
echo 'Value to send to mysql: '.$var;
?></body>

I hope that explains it better because both php AND javascript are encoding the password so there is less chance of man-in-the-middle-attack.

[digital-ether]

Here is the example of secure password transfer and storage:

<head><title>Secure Post Transfer</title><script>
function sendpost() {
    var data=document.getElementById("data").value;
    data=data.replace(/--|-\+\+\+2\+/,"---|-+++2+").replace(/--|-\+\+\+8\+/,"---|-+++8+").replace(/\+\+|-\+--8-/,"++|-+--8-");
    data=data.replace(/([0-9]+)/g,"--|-+++2+$1--|-+++8+").replace(/([0-9])/g,"--|-+++8+$1--|-+++2+");
    data=data.replace(/([a-z])/g,"++|-+--8-$1++|-+--8-");
    document.getElementById("data").value=data;
    document.dform.submit();
    return true;
    }
</script></head><body>
<form name="dform" method="POST">
<textarea name="data" id="data" style="width:400px; height:150px;">Add some random text in here aza</textarea>
<input onclick="javascript:sendpost();" value="Search" type="button">
</form><?
function truehash($hash) {
    return hash('crc32b',substr(hash('whirlpool',$hashzzz),64));
    }
$var=stripslashes($_POST['data']);
$var=str_replace(array('--|-+++8+','--|-+++2+','--|-+++--|-+++8+2+','--|-+++2+','--|-+++8+','++|-+--8-'),'',$var);
$var=truehash($var);
echo 'Value to send to mysql: '.$var;
?></body>

I hope that explains it better because both php AND javascript are encoding the password so there is less chance of man-in-the-middle-attack.

If you can easily derive the password:

str_replace(array('--|-+++8+','--|-+++2+','--|-+++--|-+++8+2+','--|-+++2+','--|-+++8+','++|-+--8-'),'',$var)

Then it is as good as being sent plain-text.

I understand that this could be useful to mitigate against automated password sniffing programs that extract passwords off the network blindly. It doesn't protect against a man-in-the-middle attack however for the reasons I already posted.

[cwarn23]

If you can easily derive the password:

str_replace(array('--|-+++8+','--|-+++2+','--|-+++--|-+++8+2+','--|-+++2+','--|-+++8+','++|-+--8-'),'',$var)

Then it is as good as being sent plain-text.

I understand that this could be useful to mitigate against automated password sniffing programs that extract passwords off the network blindly. It doesn't protect against a man-in-the-middle attack however for the reasons I already posted.

That I would agree with because although this type of script does not much extra in security, it still does something.

[sim_pack]

No because this way the user cannot access the file when apache is displaying the php code instead of html code. A rare problem but does happen. An example of including the files from above the web root:

include('/home/exampcom/phproot/file.php');

Where in that example the folder phproot is a directory with php files which is not in the web root to prevent any access at all.

how do you include files above the web root again? do you mean that files containing constants should be saved above the folder containing the index.php file (or index.html)? or like

inlcude('folder_containing_the_index.php/folder_containing_the_files_with_constants/constants.txt')

thanks..

[darkagn]

Yes that is exactly what they are saying, although it would not be a txt file but a php file. Many sites also add a .inc extension to include files, for example:

include("home/includes/constants.php.inc");