Passwords Create Security But Should Be Secure PHP Help

With your new database-driven login facility, you have lots of new possibilities, First and foremost, you can create groups in the database, and grant users access to certain parts of your application based on their group membership. For example, instead of letting just anyone into show_users.php you can grant access only to users that are members of an administrator’s group;

Before you do all of that, take a second look at a sample SOL statement and its results:

Passwords Create Security,

Anything odd there? Well, other than James Roday’s lousy choice of password. (Sure, Psych is a good show, but it’s not exactly a hard-to-crack password.)

All the same, the more glaring issue is that the password just sits there in the database. It’s plain-old text. Even if you’re new to the world of authentication and authorization, you probably have heard the term encryption. Encryption is simply taking a piece of information, usually something valuable like a password, and making it unreadable for the normal mortal. The idea is that other than the user who “owns” a password, nobody-even you, the all-wise, all-knowing programmer-should see a user’s password in normal text. What you need is a means of encrypting that password into something unreadable. And, you know what’s coming: PHP has a function for that.

Encrypting Text by Using the crypt Function

First, you need to convert the password to something that’s non-readable. You can do that using PHP’s crypt function. This function takes a string (and an optional second parameter you’ll need shortly) and produces what looks like gibberish:

Encrypting Text by Using the crypt Function

That’s quite an improvement. In fact, you should probably increase the size of the password field because crypt adds a good bit of length to the originally entered password.

ALTER TABLE users
CHANGE password
password VARCHAR(SO) NOT NULL;

That gets the password I, to your database …but what about getting it out?

crypt Is One-Way Encryption

The crypt function, by definition, is one-way encryption. This means that once a password has been encrypted, it can’t be unencrypted. While that presents you some problems as-a programmer, it’s a good thing for your users. It means that even the administrators of the applications they use can’t go digging into databases and pulling out their passwords.

Well, to be accurate, they can but they’ll only get an encrypted version. And there’s no special formula or magical command that lets them get at the original password. Users are protected. And, ultimately, you, as an administrator, are protected. If you can’t get at an encrypted password, for example, you can’t very well be blamed
for identity fraud.

But, how do you see whether a user has entered a valid password if you can’t decrypt their password value in the database? Easy: you can encrypt his supplied password, and compare that encrypted value to the encrypted value in the database. If the encrypted values match, things .are good-and you still haven’t seen that user’s real password. You want something like this in u: r;-u) o, in which passwords are checked:

crypt Is One-Way Encryption

At this point, you should be able to try things out. You’re encrypting passwords on user creation, and you’re encrypting the value to compare with that password on user login.

Unfortunately, try as you might, you’re going to be stuck with Figure 12-11-a failed login because the password doesn’t match.

So, what gives? Remember that briefly-mentioned second argument to crypt (page 415)? It’s called a salt.  A salt is a key-usually a few characters-that’s used in generating the one-way encryption used by functions like crypt. The salt helps ensure the randomness and security of a password, and unless the salt matches, the encrypted password values won’t match.

FIGURE 12-11

FIGURE 12-11

Encryption Uses Salt

So far, by not providing a salt, you’ve been letting crypt figure one out on its own. But unless the salt provided in two different calls to crypt is identical, the resulting encryption. In other words, calling crypt on the same string two times without providing a salt will give you two different results.

To see it in action, create a simple script called test.
<?php
$input = “secret_string”j
$first_output = crypt($input)j
$second_output = crypt($input)j
echo “First output is {$first_outputt\n\n”;
echo “Second output is {$second_output}\n\n”;
?>
Run this script in your command-line terminal:

 [-/www/phpMM/chll]# php test_salt.php
Content-type: text/html
First output is $1$gJp.bgbG$6rLQRuAkG34msBk09MoN51
Second output is $1$n84SPtys$Mv9SllqzZJj/.xjSPSj20S0

echo “First output is {$first_output}\n\n”;
echo “Second output is {$second_output}\n\n”;
?>

Now, run this updated version and smile at the results:
[-/www/phpMM/chll]# php test_salt.php
Content-type: text/html
First output is sazmlw2D3KJ/M
Second output is sazmlw2D3KJ/M

As you can see, you need to ensure that both calls to crypt in your application’s scripts use the same salt. Of course, you could just create a new constant, but there’s an even better solution: use the user’s user name itself as the salt! This actually means you could completely lose your scripts and any constant that defines a salt. and your authentication would still work.

The user name always stays with the password, so you’re essentially ensuring that they are truly a united combination.

First. update create_user.php (yes, one more time!) to utilize the supplied user name as a salt:

Encryption Uses Salt

Now, make the exact same change in authorize.php; Remember in this script, the user name comes in through the $_ SERVER superglobal:

Encryption Uses Salt

Finally, create a new user (hopefully you’re not running out of friends yet!). Then, try to log in by using that user’s user name and password.

And voila! Getting that same old show_user.php screen means you’ve got a lot more than the ability to delete users. It means you’ve got a solid, working authentication system. Congratulations. You’ve got one more big hurdle left to over come controlling user login with cookies.

Posted on January 12, 2016 in Authentication and Authorization

Share the Story

Back to Top
Share This