Security problem

On your line 173

$cookie = base64_encode(serialize(array('uname'=>$uname,'password'=>$originalPassword)));

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 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 :)

Nick, use md5 encryption plus a "salt" value and you're fine (maybe you need two cookies)

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 :)

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.

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.

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.

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.