Subject: | ATTENTION: The class stores... |
Summary: | Package rating comment |
Messages: | 5 |
Author: | Fabian Schmengler |
Date: | 2010-10-18 14:15:15 |
Update: | 2010-10-24 05:23:40 |
|
|
|
Fabian Schmengler rated this package as follows:
Utility: | Bad |
Consistency: | Not sure |
Examples: | Insufficient |
|
 Fabian Schmengler - 2010-10-18 14:15:15
ATTENTION: The class stores passwords as clear text and is vulnerable to SQL injections. DO NOT USE THIS IN PRODUCTION ENVIRONMENT!
 ian james - 2010-10-20 18:14:55 - In reply to message 1 from Fabian Schmengler
The Tools class cleans all GET and POST array variables with addslashes or mysql_real_escape_string if desired. Prevents sql injections.
I agree the passwords are stored in the clear. Simple change to accomplish. I will make an update if I have the time. Passwords in the clear are not absolutely a "bad" thing depending on the level of security you are attempting to accomplish.
I agree the class should have a config setting to enable/disable password encryption.
The real attempt with this class is to demonstrate the ability to add user authorization/management to any existing project and database.
Also to demonstrate the agnostic UserInfo class to allow user information to be changed from project to project and even updated as the project evolves without interferring with the basic authorization mechanisms.
Its not intended to a finalized product just a base frame work to apply your specific needs too.
 ian james - 2010-10-20 18:16:58 - In reply to message 2 from ian james
Added the Tools class. Forgot to add that. opps.
 Fabian Schmengler - 2010-10-20 19:43:44 - In reply to message 2 from ian james
I disagree that clear passwords are "not a bad thing", just think about reused passwords.
But the more dangerous part is still your escaping. I appreciate your attempt with the Tool class but this is still not a good approach. First, addslashes does NOT prevent SQL injections. Here is an example:
shiflett.org/blog/2006/jan/addslash ...
Then, any escaping should be used context dependent and at the right place, i.e. mysql_real_escape_string() right before building the query and not upfront with every value in $_POST and $_GET. What if you want to use them otherwise than in an SQL statement? The implicit dependency to your Tool class is also not a good thing as everything seems to work without it but is just more vulnerable...
After all, nowadays prepared statements should be used where available, then there is no more need to think about escaping values in SQL queries ;-)
 ian james - 2010-10-24 05:23:40 - In reply to message 4 from Fabian Schmengler
good points all. I have learned something. Thanks.
|