Web Development



What is the best method for Apache Authentication?

By mmcgillem ·
I have a website that I want to make as secure as possible. Currently i'm using SSL and the sspi_auth_module for authentication with Active Directory. I am still in the testing phase and can make any changes that are needed. I'm mainly looking for opinions on what others are doing. Is this configuration secure enough or is there a better way of doing it? Any advice or recommendations would be very helpful.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -

No website is secure...

by Peconet Tietokoneet In reply to What is the best method f ...

The only secure way for your website is to make sure you have a backup of it and also the changes that you have made to it. Make sure the backup version is not online. When, or if, your internet goes down and your website is gobblygook when it comes back online you will be pleased that you have a backup on hand.

Collapse -

Define 'Secure'

by robo_dev In reply to What is the best method f ...

If you front-end a web application with an RSA Authentication server, that makes for some very strong authentication. Despite all the hoopla about RSA getting some of it's seed material stolen by hackers, you won't find a more secure method for web app authentication than RSA SecurID.

RSA makes an agent for Apache


Collapse -

Reponse To Answer

by mmcgillem In reply to Define 'Secure'

I'm mainly talking about the authentication side. Obviously I don't want to send user credentials in plain text which I'm not doing right now. I'm just curious what other options are out there besides what I'm doing now. I know there is nothing that is 100% secure and sometimes what you choose for authentication is a matter of personal preference. You're answer is exactly the kind of answer's I'm looking for. Thanks.

Collapse -

From a security point of view

by robo_dev In reply to What is the best method f ...

My thought is that anything you develop is only as good as your testing and dev skills. Realistically, if your server is fairly well patched and hardened, and you do some monitoring, you will see that 95% of the 'abuse cases' that hit your page are automated scripts that are blindly trying to exploit a six-month old vuln, a really sloppy web page, or are trying to enumerate a vulnerability on your server/host.

A real attacker would look at the same things you look at when testing....extra code laying around, vulnerable versions of services, mistakes made, etc. Of course if you're monitoring that closely, you can most likely see where people are poking around.

If you purchase a 'canned' solution, such as RSA Authentication manager or something like a Bluecoat reverse SSL proxy, you're doing two things, you're reducing your attack surface significantly (sometimes virtually completely), AND taking advantage of the fact that these pricey solutions went through LOTS of costly QA.

For example I've spent hours picking at the RSA ClearTrust authentication page code, on both the server side and from the outside...it's as solid as code can be, PLUS it's really hard to screw up the implementation, even if somebody has no real tech skills.

Collapse -


by oldbaritone In reply to What is the best method f ...

You haven't said what the application is, nor given much detail.

Is it a customer application for in-house use only, like process control or inventory control. or maybe finance? Put it on an intranet-only server and block internet access to it with routing and/or ipsec rules.

If it's a general-consumer application for internet use, there are many methods of security available. You might even consider using a couple of different methods layered, such as https on the server and java/RSA within the website page itself.

And don't forget things like session limitations, CAPTCHA and Tarpit. End users understand a 10 or 15-second pause after a bad password entry, There is also some reasonable limit to the number of sessions from a single machine trying to sign in. There are also some simple-question verifications to find "bots" like "What color is [something]" or "How many [somethings] are ..." With the question chosen randomly from a list, it's fairly easy to identify bots and tarpit them.

But the bottom line is that there is no "security." And your end-users are their own worst enemy.

Related Discussions

Related Forums