It means that a "bad" user can recover the plain text password from that cookie string. Does it post any security problem?
For worst case, if someone hijack your (or admin) cookies, then it means they could recover the password as well ( possibly ).
I saw the password is using one way encryption (e.g. md5) to save in database, do you think the password in cookies should also do the same?
I am a metal monkey!
Administrator Community Supporter?
Jedai Sword Master
Gender:
Posts: 5779
46271 credits Members referred : 3
« Reply #1 on: Jan 24, 2009, 01:13:29 am »
I am not sure how an md5() encryption would help prevent session/cookie hijacking, but maybe we could add the user's ip (and checking) or even better add some plugin feature to allow users write their own session handling code.
BTW thanks for the contribution, even a simple quote can help the development of an open source project
Just another rainy day
Posts: 1
6 credits Members referred : 0
« Reply #3 on: Nov 22, 2009, 04:00:16 pm »
Hi there, first post here...
I best way is to validate a cookie with browser specs, cookies can't (should not) be usable on other browsers then the logged in one.
So i think if you like a valid and good validation of your cookie and then its contents you need to also include in the 'cookie' in a hashed version some of the browser specs plus salt. This you need to validate before using any other data.
Im not in the mood to write an example... so have fun creating one
Google dot what?
Posts: 2
12 credits Members referred : 0
« Reply #4 on: Dec 14, 2010, 05:59:11 am »
storing passwords in a cookie, in any form: md5, sha1, plaintext, or some other hashing method is a very bad idea. Cookies are plaintext meaning they could be read. I suggest hashing username, email, and some salt. Using the IP wont work, I may have a different IP next time I connect.
Another suggestion I have is salting the passwords stored in the database. $hashedPass=sha1($password.$userSalt.$siteSalt); The user salt can be stored in the same field as the password. Just append to the front. This is to make a rainbow attack, basically taking a dictionary and hashing it till one matches a password, harder. Google md5 search to see a nice big database of md5 hashes.
You may think who would want to hack your little site, but people tend to use the same password over and over. Hence stories like McDonald's, Walgreen and Gawker Media were hit by hackers are scary with several million accounts. The same password used in your little app may also be used for banking or email.
Oh, I wouldn't bother with md5 if your goal is to make a one way hash, its dated and compromised. Id use at least sha1 if not something better.
Bill Cosby is my Father
Posts: 4
28 credits Members referred : 0
« Reply #5 on: Feb 03, 2011, 05:52:24 am »
This class is fine until you find better. I found a user class called uFlex which is a hell lot simpler to use yet more complex in a sense of security and flexibility.
Google dot what?
Posts: 2
12 credits Members referred : 0
« Reply #6 on: Feb 03, 2011, 06:48:21 am »
Well the first thing I look at when looking at authentication systems is how it hashes the password. Its using salt, which is good, but its using md5 to actually generate the hash. This one at least used sha1, which isn't the best for passwords, but its much better then md5. I don't see anything in uFlex that this one doesn't have that would make me want to switch now that i've fixed my issues with it.
Bill Cosby is my Father
Posts: 4
28 credits Members referred : 0
« Reply #7 on: Feb 27, 2011, 01:02:50 pm »
Hi,
I added a salt feature to the class. I think it really helps a lot. At least criminals can't find your hash in a rainbow table.
I also think it would be safer if you save the hash in the cookie instead of the original password for the "Rember me" feature.
Using the session_regenerate function ([url]http://php.net/manual/en/function.session-regenerate-id.php/url]) may also increase the security.
Destructive.
Trackback URI for this entry : http://www.webdigity.com/trackback.php?topic=8419