Session 3: Security blankets

liunx · Jun 5, 2008

Session 3: Security blankets Ah, childhood, when you could have a security blanket for stuff animal. Though I don't think I ever had a security anything, I can say I like to sleep with an extra blanket under my head at night. But anyway, this session of my learning series is going to look at the security side of things. You may be familiar with the use of cookies and sessions to keep track of users and allow them to be automatically logged in whenever they come back. These are awesome tools that can either be used for good or evil and whenever you are using them for your project, always assume they are being used for an evil intent. Why assume an evil intent? Because even if you encrypt a password, someone can still take that and use it to "log in" to someone else's account. Of course they have to get the encrypted password first, which is why most online communities don't allow JavaScript. And if they do, they shouldn't, or at the very least monitor the JavaScript the users are using. But even if they could, of if we wanted to allow users to be able to use JavaScript, how could we stop the malicious attacker from taking over accounts? One thing we could do is require each user to authenticate any changes to either their account's email or password through an email address they control. This would allow them to change their password or email only when they want or need to and not allow an attacker ultimate control. This is what I believe most forums and other online services use. While that makes it impossible or extremely difficult for our attacker to gain complete control over an account, how do you suppose we could help thwart him even being able to gain access in the first place? I mentioned at the end of the last session that we'd look at ways to keep the real password out of the hand of the wrong hands. Even though I'm using MD5 hashes to mask passwords, someone could still take that hash and decrypt it or even use that hash on another site to see if the victim uses the same password at various places. You can easily stop this by adding something more to the password just before you encrypt it and store it in the database. That is add some secret string that is constant to the passwords. EXAMPLE: <div class='codetop'>CODE</div><div class='codemain'> $username = $_POST['username']; $password = md5("THIS IS A PASSWORD FOR A USER!_-___".$_POST['password']); $SQL = "INSERT INTO passwords (`username`, `password`) VALUES ('{$username}', '{$password}');</div> Note I have not used addslashes(), this was for simplicities sake. The third thing that could be done is make use of what I think is called "rolling encryption". That is, the password hash stored in the cookies or session object change. This change could be instigated by adding something like a time stamp to the original hash, then hashing that, and then storing this new hash in the cookie or session. This would allow us to remix the password hash every time the user logs in or quite possibly every X number of minutes. Thereby always keeping the attacker on his feet by making him to constantly have updated password hashes. The three factors of authentication are:<ul><li>Something you know (like a password)</li><li>Something you have (this is like an email address)</li><li>Something you are (the username)</li></ul>We could combine the email address and username into one thing. The only reason I'd probably not do this is for the sake of having to remember the username change when the user changes email addresses. Another area that requires security is user input. If we never validate user input, we could be allowing users to rewrite SQL queries or even insert their own php code to do and could do all sorts of things not good. For validating numbers all we really need to do (with PHP anyway) is recast the user supplied variable as an integer. This is by far the easiest of things to take care of. But since strings are generally variable in length and content, we must work on either a white or black list of what's acceptable or not. Say for instance the user is to supply their home state. As we know all the states we can check what is provided to a white list containing all the states. Or say they're wanting to edit some personal info on the profile page. Here it's a toss up between a white or black list. On one hand, if we are using bbcode and a select few HTML tags, a white list would be the obvious answer. But if you're going to allow almost unfettered HTML use, it quickly becomes unrealistic to use a white list. That's all for that. Next time I'll be going to the actual implementation of the ideas about database layout.
</div>

Session 3: Security blankets

liunx

Guest