On February 22, 2012 17:44 , Rajeev Prasad <rp.ne...@yahoo.com> wrote:
what is the best website security method?
What are your specific security requirements? What are the characteristics of your user community? What risks are you trying to protect against? How important is security? What tradeoffs are acceptable in your situation, and which ones are not acceptable?
In short, what is "best" for me may not be "best" for you: it depends on each individual situation.
1. best authentication method?(AuthMYSQL?)
Here is an example of a "best" solution for a particular organization I am thinking of, but this is probably overkill for most websites:
Have each user come to you in person every year and show two forms of government ID, plus school records and utility bills. This way, you know who they are. When they are there, in person, have them set a strong password -- a sequence of four or more random words is best, see https://www.xkcd.com/936/ Also give them a time-based OTP hardware token that implements OATH via RFC 4226 (see http://www.openauthentication.org/specifications ).
Configure your web server to use mod_authn_opt ( https://code.google.com/p/mod-authn-otp/ ) or a similar module. Users should be required to supply both their password (something they know) as well as the currently valid OTP from their token (proving that they have the token with them, something they have). For extra security, you should have the web server invalidate the session -- requiring them to reauthenicate --any time the user's IP address changes. Also invalidate the session to require reauthentication after more than the maximum idle time (example: 2 hours), more than the maximum total session time (example: 24 hours), or when they hit any "sensitive" page or attempt to perform any "high value" transaction/operation.
1.b best data authorization method?
Again, this depends on your situation. Here's an example, again probably overkill for most websites:
But, for example, authorize access based on roles rather than usernames. Associate users with one or more roles via your HR or ERP systems.
For additional security, you can restrict authorization to not just identity (authenticated username) but also location (IP address), and time (for example, working hours).
Permission or role information is usually stored in a database and checked by the web applications rather than the web server because authorization is usually heavily dependent on business logic. However, it's possible to do authorization in the web server itself by using the "Require" and "SSLRequire" directives, among others. There are examples in the Apache HTTP Server documentation about restricting access by username, by group, by IP address, by time of day, and more.
2. best website security method?(ssl?)
SSL is not a generic web site security method, it just protects communication between the web browsers and web servers from interception and modification.
When you combine SSL with authentication, you can effectively stop random people from scanning your web site for vulnerabilities.
However, if you are looking for "website security methods", then in addition to SSL, require authentication and authorization, use web-application level firewalls (such as mod_security, Suhosin, or a Citrix NetScaler), use a Mandatory Access Control system at the OS level (such as SELinux), implement tripwire to detect unauthorized filesystem changes, set up a monitoring system to detect abnormalites (suspicious processes, outgoing network connections, etc.), log monitoring (web server access log, web server error log, and operating system logs), and regularly patch/update all software on the server to fix vulnerabilities. I'm sure other people can add other recommended practices to this list.
3. which is the best open source "automated and heuristic web vulnerability scanner" ?
I don't know, hopefully someone else can answer this. -- Mark Montague m...@catseye.org --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
