tags:

views:

34

answers:

4

Is it alright to post the isset password like this?

I think it should be if(isset($_POST['username']) && isset(md5($_POST['password']))) - since it posts it encrypted, but if I wrap md5 around the password w/i the conditional, it does not work properly.

if(isset($_POST['username']) && isset($_POST['password'])) {
 //run authentication
} else {
 //show form
}
+1  A: 

Brad, yes it's ok. There is really no benefit to posting the password hashed (not encrypted). First, you have to use javascript to do that, and it's easily circumvented. Hashing of the submitted password should be done server side to compare with the stored hashed value.

Edit:

Plus, run the following and see what you get:

<?php echo md5(NULL);

Thus, md5 always returns a value.

On top of that try running the following:

<?php var_dump(isset(md5($_POST['password'])));

You'll see the following: Fatal error: Can't use function return value in write context

isset() can only be used with a variable.

Edit:

There is a difference between hashing and encryption. MD5 is a simple hash, one that isn't even cryptographically secure.

Yes, you should not submit passwords in plaintext to your server, but hashing them client side is the same thing. You should be using HTTPS for password form submissions, this is how you encrypt communications between your server and the client.

hobodave
I was just worried that it is bad to post a password un-encrypted, even in a conditional.
Brad
If you want password security use SSL. Besides that, there is nothing more you can really do that can't be circumvented.
Chacha102
Brad: You are not understanding what encrypted is. md5() is _not_ encryption it is hashing.
hobodave
Also, your PHP code has nothing to do with how the data is submitted. By the time that conditional is executed the password is already submitted in whatever form it came from the client in. You can change your PHP as much as you want, it doesn't affect the data that gets POSTed.
hobodave
it is alright to do isset($_POST['password']) w/i the conditional? Just making sure. :)
Brad
@Brad: absolutely
hobodave
A: 

Your new version doesn't do anything beyond your old version.

You can check that md5($_POST['password']) == $user['password'] or whatever later on.

MQA
-1: It isn't even valid PHP. It results in a Fatal Error.
hobodave
$user = mysql_fetch_assoc(etc);if (md5($_POST['password']) == $user['password']){ // Yes it is!}
MQA
"Your new version doesn't do anything beyond your old version." - his new version throws a Fatal Error.
hobodave
+1  A: 

The whole purpose of

if(isset($_POST['username']) && isset($_POST['password'])) {

is to check if both POST parameters are set/available. There's no authentication involved, not even an assumption about the type of both elements (could be strings, arrays, ...). Only "is there such parameter in the request" and "can I access this element without raising a notice: undefined index".

No let's compare that to isset(md5($_POST['password'])) md5() takes a string, so md5($_POST['password']) makes two assumptions.
a) There is an element $_POST['password'], the very thing the "original" test checks.
b) (string)$_POST['password'] makes any sense, since whatever you pass to md5() is cast to string. If you pass an array the result is the same as for md5('Array');
Plus md5() always returns a string (the string representation of the hash for the input), so isset() is always true and doesn't make much sense there. (edit: would be always true, if isset() could be used with the return value of a function. But it can't, see comments)

bottom line; The "original" version serves a "well defined" purpose, the isset(md5(..)) version not so much ;-)

VolkerK
It's simpler even. isset() can't take a function as input, and md5() will hash anything, even NULL.
hobodave
You're right, isset(fn()) causes a "Fatal error: Can't use function return value in write context". Ok, then it not only makes no sense in a logical way, it's impossible in practice =] And md5(null)===md5('') since (string)null===''
VolkerK
A: 

If the fields are in a form which is submitted, then those values will always be isset. What you probably want to check is whether or not they are empty. One simple way is to compare to an empty string, but that requires that you first check that the variable is set, otherwise, when the form hasn't been submitted, you'll get an "array key does not exist" warning. Thankfully, there's a handy method called empty() which checks whether a given variable has been set and whether it has a non-falsey value -- hence you usually want to check if something is not empty.

$x = "";
!empty($x);  // false
isset($x);   // true :(

// beware though:
$x = "0";
!empty($x);  // false

Think of it as a shorthand for this:

isset($x) && $x != false
nickf
-1: This doesn't really address any of the several fundamental misunderstandings the OP makes. Specifically, the OP doesn't show clear understanding of how form submission works, hashing, or encryption. What does empty() have to do with anything?
hobodave
@hobodave Well it looked as though he was trying to tell whether there were values in the fields.
nickf