How to Prevent Cracker Getting a Login Access via Stealing Cookies
I'm trying to find a solution for securing remember me functionality. Cookies will be used.
function enc($string) {
$slat = "%32!@x"; //can be auto-generated
$hash = sha1(md5($slat.$string)).md5($string).sha1(md5(md5($string)));
return $hash
}
echo enc("password"); //store user's password in db
I started thinking "What if a cracker steals my member's cookie!" In this case, the Hacker will have access until hacker OR original user logs out. There will be no evidence (other than last login) that account is hacked. In this case, hacker will always have access every time the original user logs in with "Remember Me" until original user changes the password.
Assuming, hacker couldn't have the password.
Solutions (how to prevent hacker get an access if he/she stole the user's cookie):
1. In db user table, i put "Token" field which will carry salt value.
2. Everytime user logs in via the form or via the cookie (auto-login), update the token with auto generated value. Also, update the password field with the new hash.
3. Now set the cookie with the new values.
4. The previous cookie is not valid anymore.
5. Assume hacker got access, his access will be temporary until original user access his account and won't be able to do major changes such as changing password/email.
Hacker and User will share step 2! Everytime hacker logs in, user is kicked out from access due to multiple account access and vice versa. This will indicate account being stolen, so it won't be so long till the original user simply go and change the password.
This not a %100 solution, but reduces chances of risks and warns the user that there is another person using the same account.
I'm trying to keeping it as simple as it can.
Is the solution good enough? Are there major flaws in the solution?
What you are looking for is session hijacking prevention. This link will explain to you what needs to be done. There is no need to parrot in here what is already said and done. This is a description of the attack with illustrations from The Open Web Application Security Project.
I'm going to try to keep this short, because it could easily get too long.
An option is to include some more identifying data within the cookie, such as the user's IP address (which obviously may change) or their browser's user-agent (which really shouldn't change). You can include other things if you want, I'm just using these for now so I can keep it shorter :)
encrypt ( (user-agent and/or ip) and hash(token) )
Would give you a decryptable string which you could substr() a known length off the end of to get your token back, and compare the other parts to the user's current data.
Alternatively,
hash(user-agent and/or ip) + hash(token)
Would allow you to substr the token off the end immediately then just hash the current user-agent and/or IP and compare it to the cookie value.
Obviously this is more about how to narrow down the chance the hacker can use the stolen token. If the original user was using Firefox 3.5 with a certain user-agent, the hacker would have to use that too. If it came from a certain IP, that would need bypassing, and so on.
链接地址: http://www.djcxy.com/p/54746.html上一篇: str之间的行为不一致