Tài liệu Advanced PHP Programming- P8 pdf

328 Chapter 13 User Authentication and Session Security

Ironically, a tuned system makes dictionary attacks even easier for the cracker.At a previ￾ous job, I was astounded to discover a cracker executing a dictionary attack at more

than 100 attempts per second.At that rate, he could attempt an entire 50,000-word dic￾tionary in under 10 minutes.

There are two solutions to protecting against password attacks, although neither is ter￾ribly effective:

n Create “good” passwords.

n Limit the effectiveness of dictionary attacks.

What is a ”good” password? A good password is one that cannot be guessed easily by

using automated techniques.A “good” password generator might look like this:

function random_password($length=8) {

$str = ‘’;

for($i=0; $i<$length; $i++) {

$str .= chr(rand(48,122));

}

return $str;

}

This generates passwords that consist of random printable ASCII characters.They are also

very difficult to remember.This is the key problem with truly random password genera￾tors: People hate the passwords they generate.The more difficult a password is to remem￾ber, the more likely a person is to put it on a sticky note on his or her monitor or in a

text file or an email message.

A common approach to this problem is to put the burden of good password genera￾tion on the user and enforce it with simple rules.You can allow the user to select his or

her own password but require that password to pass certain tests.The following is a sim￾ple password validator for this scenario:

function good_password($password) {

if(strlen($password) < 8) {

return 0;

}

if(!preg_match(“/\d/”, $password)) {

return 0;

}

if(!preg_match(“/[a-z]/i”, $password)) {

return 0;

}

}

This function requires a password to be at least eight characters long and contain both

letters and numbers.

A more robust function might check to ensure that when the numeric characters are

removed, what is left is not a single dictionary word or that the user’s name or address is

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Registering Users 329

not contained in the password.This approach to the problems is one of the key tenets of

consulting work:When a problem is difficult, make it someone else’s problem.

Generating a secure password that a user can be happy with is difficult. It is much easier

to detect a bad password and prevent the user from choosing it.

The next challenge is to prevent dictionary attacks against the authentication system.

Given free reign, a cracker running a dictionary attack will always compromise users.

No matter how good your rules for preventing bad passwords, the space of human￾comprehensible passwords is small.

One solution is to lock down an account if it has a number of consecutive failures

against it.This solution is easy enough to implement.You can modify the original

check_credentials function to only allow for a fixed number of failures before the

account is locked:

function check_credentials($name, $password) {

$dbh = new DB_Mysql_Prod();

$cur = $dbh->execute(“

SELECT

userid, password

FROM

users

WHERE

username = ‘$name’

AND failures < 3”);

$row = $cur->fetch_assoc();

if($row) {

if($password == $row[‘password’]) {

return $row[‘userid’];

}

else {

$cur = $dbh->execute(“

UPDATE

users

SET

failures = failures + 1,

last_failure = now()

WHERE

username = ‘$name’”);

}

}

throw new AuthException(“user is not authorized”);

}

Clearing these locks can either be done manually or through a cron job that resets the

failure count on any row that is more than an hour old.

The major drawback of this method is that it allows a cracker to disable access to a

person’s account by intentionally logging in with bad passwords.You can attempt to tie

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

330 Chapter 13 User Authentication and Session Security

login failures to IP addresses to partially rectify this concern. Login security is an endless

battle.There is no such thing as an exploit-free system. It’s important to weigh the

potential risks against the time and resources necessary to handle a potential exploit.

The particular strategy you use can be as complex as you like. Some examples are no

more than three login attempts in one minute and no more than 20 login attempts in

a day.

Protecting Passwords Against Social Engineering

Although it’s not really a technical issue, we would be remiss to talk about login security

without mentioning social engineering attacks. Social engineering involves tricking a user

into giving you information, often by posing as a trusted figure. Common social engi￾neering exploits include the following:

n Posing as a systems administrator for the site and sending email messages that ask

users for their passwords for “security reasons”

n Creating a mirror image of the site login page and tricking users into attempting

to log in

n Trying some combination of the two

It might seem implausible that users would fall for these techniques, but they are very

common. Searching Google for scams involving eBay turns up a plethora of such

exploits.

It is very hard to protect against social engineering attacks.The crux of the problem is

that they are really not technical attacks at all; they are simply attacks that involve duping

users into making stupid choices.The only options are to educate users on how and why

you might contact them and to try to instill in users a healthy skepticism about relin￾quishing their personal information.

Good luck, you’ll need it.

JavaScript Is a Tool of Evil

The following sections talk about a number of session security methods that involve cookies. Be aware that

client-side scripting languages such as JavaScript have access to users’ cookies. If you run a site that allows

users to embed arbitrary JavaScript or CSS in a page that is being served by your domain (that is, a domain

that has access to your cookies), your cookies can easily be hijacked. JavaScript is a community-site crack￾er’s dream because it allows for easy manipulation of all the data you send to the client.

This category of attack is known as cross-site scripting. In a cross-site scripting attack, a malicious user uses

some sort of client-side technology (most commonly JavaScript, Flash, and CSS) to cause you to download

malicious code from a site other than the one you think you are visiting.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Maintaining Authentication: Ensuring That You Are Still Talking to the Same Person 331

Maintaining Authentication: Ensuring That You

Are Still Talking to the Same Person

Trying to create a sitewide authentication and/or authorization system without cookies

is like cooking without utensils. It can be done to prove a point, but it makes life signifi￾cantly harder and your query strings much uglier. It is very difficult to surf the Web

these days without cookies enabled.All modern browsers, including the purely text￾based ones, support cookies. Cookies provide sufficient benefit that it is worth not sup￾porting users who refuse to use them.

A conversation about ways to tie state between requests is incomplete without a dis￾cussion of the pitfalls.The following sections cover commonly utilized but flawed and

ineffective ways to maintain state between requests.

Checking That $_SERVER[REMOTE_IP] Stays the Same

Relying on a user’s IP address to remain constant throughout his or her session is a clas￾sic pitfall; an attribute that many people think stays constant across requests as the user’s

Internet connection remains up. In reality, this method yields both false-positives and

false-negatives. Many ISPs use proxy servers to aggressively buffer HTTP requests to

minimize the number of requests for common objects. If you and I are using the same

ISP and we both request foo.jpg from a site, only the first request actually leaves the

ISP’s network.This saves considerable bandwidth, and bandwidth is money.

Many ISPs scale their services by using clusters of proxy servers.When you surf the

Web, subsequent requests may go through different proxies, even if the requests are only

seconds apart.To the Web server, this means that the requests come from different IP

addresses, meaning that a user’s $_SERVER[‘REMOTE_IP’] address can (validly) change

over the course of a session.You can easily witness this behavior if you inspect inbound

traffic from users on any of the major dial-up services.

The false-negative renders this comparison useless, but it’s worth noting the false￾positive as well. Multiple users coming from behind the same proxy server have the same

$_SERVER[‘REMOTE_IP’] setting.This also holds true for users who come through the

same network translation box (which is typical of many corporate setups).

Ensuring That $_SERVER[‘USER_AGENT’] Stays the Same

$_SERVER[‘USER_AGENT’] returns the string that the browser identifies itself with in the

request. For example, this is the browser string for my browser:

Mozilla/4.0 (compatible; MSIE 5.21; Mac_PowerPC)

which is Internet Explorer 5.2 for Mac OS X. In discussions about how to make PHP

sessions more secure, a proposal has come up a number of times to check that

$_SERVER[‘USER_AGENT’] stays the same for a user across subsequent requests.

Unfortunately, this falls victim to the same problem as $_SERVER[‘REMOTE_IP’]. Many

ISP proxy clusters cause different User Agent strings to be returned across multiple

requests.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

332 Chapter 13 User Authentication and Session Security

Using Unencrypted Cookies

Using unencrypted cookies to store user identity and authentication information is like a

bar accepting hand-written vouchers for patrons’ ages. Cookies are trivial for a user to

inspect and alter, so it is important that the data in the cookie be stored in a format in

which the user can’t intelligently change its meaning. (You’ll learn more on this later in

this chapter.)

Things You Should Do

Now that we’ve discussed things we should not use for authentication, let’s examine

things that are good to include.

Using Encryption

Any cookie data that you do not want a user to be able to see or alter should be

encrypted.

No matter how often the warning is given, there are always programmers who

choose to implement their own encryption algorithms. Don’t. Implementing your own

encryption algorithm is like building your own rocket ship. It won’t work out.Time and

again, it has been demonstrated that homegrown encryption techniques (even those

engineered by large companies) are insecure. Don’t be the next case to prove this rule.

Stick with peer-reviewed, open, proven algorithms.

The mcrypt extension provides access to a large number of proven cryptographic

algorithms. Because you need to have both the encryption and decryption keys on the

Web server (so you can both read and write cookies), there is no value in using an asym￾metric algorithm.The examples here use the blowfish algorithm; but it is easy to shift to

an alternative cipher.

Using Expiration Logic

You have two choices for expiring an authentication: expiration on every use and expi￾ration after some period of time.

Expiration on Every Request

Expiration on every request works similarly to TCP.A sequence is initiated for every

user, and the current value is set in a cookie.When the user makes a subsequent request,

that sequence value is compared against the last one sent. If the two match, the request is

authenticated.The next sequence number is then generated, and the process repeats.

Expiration on every request makes hijacking a session difficult but nowhere near

impossible. If I intercept the server response back to you and reply by using that cookie

before you do, I have successfully hijacked your session.This might sound unlikely, but

where there is a gain to be had, there are people who will try to exploit the technology.

Unfortunately, security and usability are often in conflict with one another. Creating a

session server that cannot be hijacked is close to impossible.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.