Advanced PHP Programming- P8

Tham khảo tài liệu advanced php programming- p8, công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả
Nội dung trích xuất từ tài liệu:
Advanced PHP Programming- P8328 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 Registering Users 329not contained in the password.This approach to the problems is one of the key tenets ofconsulting 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 easierto 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 failuresagainst it.This solution is easy enough to implement.You can modify the originalcheck_credentials function to only allow for a fixed number of failures before theaccount 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 thefailure 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 aperson’s account by intentionally logging in with bad passwords.You can attempt to tie330 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 ...