It is the norm to store the value of the hash of the password rather than a cleartext password. You don't want to just store '123pass' or something in your database as-is. So it is common to 'hash' the password value using MD5, SHA1, or any number of other common hash methods, and instead store the hash value. When you check the database against the user's password, you check it against the hash value, not the actual input value. That value would be consider safer to send along in a GET string than a plaintext password. Not perfect, but safer.
Try this:
PHP Code:
$password= '123pass';
echo "The MD5 hash value of '{$password}' is: " .md5($password) .'<br />';
echo "The SHA1 hash value of '{$password}' is: " .sha1($password) .'<br />';
Play around with that a bit, substitute '123pass' with any number of real passwords you might use, experiment with different hash functions. Make sure you check the string length of each hash output as well. For example, MD5 is
always a 32 char base 16 (hex) value. SHA1, similarly, is
always a 40 char base 16 (hex) value. Other hashes produce longer (or shorter, but you don't want to bother with them) values. It is usually a safe bet that the longer the hash value, the better it is. When designing your database, define the column length to be a CHAR(32) or CHAR(40), etc. to fit that size hash value.
You can also use a 'salt' combined with a hash to make it even more secure. Every password you store in the database, for example, might be 'salted' prior to storage and checking.
PHP Code:
$password= '123pass';
// the salt - uniform for all passwords stored
$salt= 'YeScurvyDogs';
// return the value
$hashedPassword= md5( $salt . $password);
See what we're doing there? We're using the salt concatenated to the password value to make it even more secure. So the hashed value doesn't match the plain hash of
md5($password). It may be complex at first, but play around with it and see how it works. I typically store the salt in a database field that is retrieved prior to every hash, so it actually stays in the database and not in the script.