可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
I'm in the middle of coding a 'remember me'-equipped login form, and so far the tutorials I've read (partly to make sure I'm doing it right) all say to store the encrypted password in a cookie along with the username. Then, each time PHP checks if the current user is not logged in, check their cookies and look for those values. If the username matches the password, you're in.
To me, this is a gaping security hole. If somebody were to hack the database or somehow get access to the encrypted passwords, they wouldn't even need to crack them. Just set your own cookies and go. Am I correct, or just being paranoid?
My login system uses sessions to keep track of the current user id, and a 1/0 for a quick logged in/logged out check. The user can't edit sessions AFAIK, so this is secure (if it's not, please let me know). I was thinking of just storing the session ID in a cookie, to later resume it, but that's also not secure.
I care a lot about the security of my users, how can I properly protect their information while still maintaining a functioning website?
回答1:
Usually when the server is requested to remember the user, it issues an additional cookie beside the normal session cookie, and this new string contains the username and a reasonable amount of random characters which make it unguessable. This is obviously saved in the database (for security reasons you may want to treat it like a password and thus salt and hash it), and the next time the user connects with the same browser (assuming the old session expired) the application receives the random string, checks the database, and if there's a match the user is authenticated.
An alternative is moving the session expiration time ahead of some amount.
What are the security holes here? Provided you use a good random generator, the only thing that can happen is that the user accesses the application from a shared browser and doesn't manually logs out when it ends.
The normal rules always apply since you are on an insecure channel: use HTTPS, otherwise whoever sits in between your computer and the server can steal cookies (either the session one or the remember-me one) and act as if it were you.
Bonus, this must-read by Jeff Atwood
回答2:
Never save passwords in any way (encrypted password which can be used to login is still a password) on client.
Use randomly generated key, safely stored on server. These keys can be revoked later unlike the encrypted passwords which will be valid until changed.
Using php you can generate random key like this md5(uniqid(mt_rand(), true))
. For better safety store it salted and hashed in db.
Example table:
login_keys (
user_id int,
key char(40), # sha1
salt char(15)
)
Also note you should enable the HTTP only cookie option.
回答3:
If you want it secure, dont allow your users to keep them logged in.
When setting the session, make sure to bind the ipaddress to the session ID, so that if someone picks up a session later, it can only be done from the same Ip address.
Yo can do this by keeping a database with (hashed) session ids + hashed ipaddresses.
I use phps function http://php.net/manual/en/class.sessionhandler.php to set a session handler and match sessions with ipaddresses.
回答4:
I have encountered this same issue while working on my own website, the best way I found to solve it was to simply not remember passwords, only usernames, providing a faster loggin but not a less secure one. The fact is that there is no sure fire way to keep the passwords absolutely secure. Besides with new browsers, the user can have their browser remember it.
But if you must have a saved password, try this:
Have multiple cookies, 2 would be the easiest, and use one for an encrypted password, while the other held an encryption key. The password in the database would hold a further encrypted password, obtained by using your stored encryption key(s). When you are ready to check the password, extract the values and encrypt the password.
Hope this was helpful. Good luck!
Edit: I might have misunderstood this, if the user is still logged in, it is good practice to store a session variable.