Assessing security issues

[Stefano Mtangoo]

I have recently being interested in Web security and I have some reading. I then found this post, and it is great. I would like to hear what do you think is missing or what isn't necessary a.k.a overkill.
It is not criticizing as such but discussing security ;)

[mschroeder]

In general that article looks like it touches on most of the basics however I disagree with some of their basic security methods

• Handle errors gracefully
  No production environment should ever be running with error_reporting enabled. This being disabled will prevent php from displaying errors or returning query issues. That doesn't mean you shouldn't be handling errors gracefully though.
  As much as possible code should be wrapped in try and catch blocks and instead of letting php functions throw their own errors catch them and handle the output in your own manner. e.g. email a site admin or log it to a database, send the user to a 404 page anything as your design requires.
• Passwords in the user account table of your database must be encrypted (SHA-1)
  This statement is incorrect. Passwords in your database should always be hashed not encrypted. Hashing is designed to be a one-way change. Encryption however is designed to be reversible. SHA-1 is an example of a hashing function.
  Something this article fails to mention is the usage of a salt to add to the complexity of the original string, mostly to control dictionary attacks.
• Use the "maxlength" option in your HTML form elements
  This isn't worth the time it would take you to type it in. The only place this may be convenient is when you're entering something where you know it is an exact length. e.g. 5 digit zipcode. If your form is going to be attacked, then simply posting the same fields directly to your form action from somewhere else would be a lot more efficient and would avoid the maxlength all together.

I absolutely agree on limiting user access based on role, ACL (access control list) and/or RBAC (role-based access control) make a lot of sense.

One thing that I usually see mentioned in these articles that I did not see in this one is the idea of throttling how long it takes for a login script to respond to the user. Basically something that tracks the number of login attempts via a session value, and then for each failed login attempt sleeps longer and longer before returning the result to the user. Obviously a grace period of 5 - 10 logins would be necessary to not interfere with normal users, but I've seen this implemented all the way to after x tries it starts serving up a 403 forbidden error.

[Stefano Mtangoo]

Thanks mschroeder,
Anyone with such helpful tips is welcomed :)