A point in|on HTTP basic auth
The story of HTTP basic auth is actually quite funny. It is definitely the most mature, and probably the most often mistaken authorization, maybe even security approach I know to exist. At least in web terms.
Understanding “basic”
The term basic actually translates ambiguously. For one, it may mean simple, easy. For another, there is a very, well, basic meaning, as in base. In an efficient security chain, you may always want to rely on the strongest link, but probably rarely on it alone. Consider an airport, although I dislike this example for some reasons. They finally happened to find the most reliable and secure body-check engine ever, still it costs some hundred K each. The item, as effective as it works, consumes additional energy, maintenance, probably attention and, eventually, time. I suppose you recognize the bottle-neck by now. So, while that item would reliably determine some guy with a huge sword in a huge sheath, this could have been done just as well by some legacy staff. While “the item” does the most sophisticated check, it is not done in the first place. But after a preliminary, basic check.
Misunderstanding “basic”
Of course, there are downsides. Unless it is done right. The (I figure: still) most common fault is to “protect” any unencrypted connection by such login.
Do not use plain. Ever.
You really do not want to do this, unless you maintain at least some kind of additional, automated one-time token system for a good reason. Sending credentials over plain HTTP is, basically, so much of a flaw that the one committing it should reconsider his or her career given that the year is 2015.
Avoid generic logins
Using static credentials, or shared ones, or both, is a common practice. It is an acceptable one, for so long as you are clear on the fact that this is not protecting anything, but only putting a delay on things. Static credentials, especially when pre-shared, are prone to spread almost on their own before someone even used them. It makes just as much (or few) sense as you consider “delay” a sensible factor.
What instead? At the very least, you should consider manually maintaining a personalized credentials file. This leaves you means to restrict access selectively in case of compromise or loss.
Basic approaches
Now what’s the point in basic? Aside from taking load off the actually protected system, it also adds an obfuscation factor to your resource. Those coming uninvited will have no idea of the service behind the generic HTTP response, as HTTP basically means “anything”. So, instead of concentrating their powers on the actual resource (and a probably known exploit), they have to deal with a generic HTTP password ping pong, which can be mitigated by additional measures. It depends on your situation, how likely the case may be that they will keep trying or move on to the next opportunity.
Minimize user impacts
Depending on the resource behind the basic auth protected frontend, which presumably has further security factors in place, you could provide some kind of SSO to your users. That done, you have also done everything you can do to minimize the impacts of the basic layer. Customers may, or may not, store their personal credentials in their browser, or password manager. Still you should take care to deploy additional credentials securely; you may want to consider defined patterns users may apply to their main credentials.
Integrate authorization backends
Apache, as most contemporary web servers, provide a bunch of backend integration out of the box. You could also consider a set of user management scripts, linked to some external service (i. e. your actual resource) - the sky is the limit.
Basically
I recall situations where suggesting a “basic” layer has been ridiculed. I figure it was not for the bare facts, but much for the said misunderstandings. Depending on the integration, you might have much additional protection at few additional efforts. It depends on the case. But then again, what does not.