What's the purpose of MD5 then??

In the latest version 1.92, you have double password checking in the login_user method.
If the MD5 hashed pw doesen't work, you recheck it with full text pw.

I think it is not very wise because it is possible then to log in with the MD5 hash. In such case hashing password's has no meaning.

Suppose someone gets the hash from the db: he can use it without knowing the actual password ...

Unless I'm wrong??

[Free WordPress Themes]

you may be right (keep an eye on  your database )

I have changed this because the password was stored in the cookie without encryption. I'm not happy how this is working now. Do you have a suggestion?

I think it's better to store unencripted password in the cookie in such case. The damage is lesser and only those who use the Remember me function, take the risk.
I'd personaly rather give up to this functionality than compromise this othwrwise very good script.

A good solution would be to use a reversible key based encription like gnupg_encrypt .

[Join us @ facebook]

A reversable key would be fine, but not a gnuPG one. The gnupg functions in php are experimental and anyway gnupg would make the requirements high for the usual shared hosting accounts....

Having the password encrypted in the cookie is also a good solution as the cookie can be easilly be stolen.

My suggestion is to leave as is, but make it possible to login only with the unecrypted pass. I am not sure how this can be right now, but as I am going to use your class for my next product I will check the code and maybe have more feedback on that later

[Free WordPress Themes]

Nick, at the moment the login data is stored in the cookie and is called into the login form (if available).

So it's possible to use the cookie to automatically login (like here at webdigity)

this way the password can be used encrypted inside the cookie and the login method accepts only unencrypted passwords

A solution can be that cookie check inside the constructor.

[Join us @ facebook]

A solution can be that cookie check inside the constructor.

I agree. The login page, and the cookie based login should not be treated as the same thing in any way.

[Free WordPress Themes]

A solution can be that cookie check inside the constructor.

I agree. The login page, and the cookie based login should not be treated as the same thing in any way.

I will change that...

[allways a security risk]

Having the password encrypted in the cookie is also a good solution as the cookie can be easilly be stolen.

If you can login with encripted password it doesen't matter wether the password is encripted inside a cookie or not since you can login directly with what you found in the cookie (either the password or the hash).

If you want that the login pages actually offer you your username and pw, you have only two soultions: either you store unencrypted password in the cookie, or you use a reversible encription that uses a site specific key.

However, cookie based authentication is allways a security risk. If a hacker can steal a cookie, he can "pretend" to be the user that originaly used the cookie and his doors are open no matter the encription you use.
You can never trust cookie information: it's ok for the stats, personal preferences etc. but not suitable for login!

My suggestion is that the cookie based login should be disabled  or at least that there would be a simple way of disabeling it (ie in the db_config file).

[Join us @ facebook]

However, cookie based authentication is allways a security risk. If a hacker can steal a cookie, he can "pretend" to be the user that originaly used the cookie and his doors are open no matter the encription you use.
You can never trust cookie information: it's ok for the stats, personal preferences etc. but not suitable for login!

That is a fact. You can't do much for the cookie. I mean as the cookie can be stolen, the "hacker" can pretend that is a user no matter what you do. The solution is that the significant parts of your app allways require a secondary login. That would be an admin page for a forum, or the page where you edit your personal information as a user.

My suggestion is that the cookie based login should be disabled  or at least that there would be a simple way of disabeling it (ie in the db_config file).

Disabling it wont be a solution as none uses this class for a banking system, right?

But having it more customizable sure will work.

[Free WordPress Themes]

Ok, I changed the class that people need to enter a password, this PW is encrypted inside the class to compare it withe value of the database.

While calling the class there is a check for a cookie, if this cookie exists and is valid, the user is logged in automatically.

since prev. versions it is  possible to disable the cookie saving process by :

Code:

$my_access->save_login = "no";

I will publish the new version later (this night)

[Guest]

[37.018]

Yahoo crawler, Googlebot, Msnbot, Nikolas