Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
790 views
in Technique[技术] by (71.8m points)

security - How secure is .htaccess password protection?

Is password protecting a directory with .htaccess the best way to prevent its files from being seen by unauthorized users? Are there any alternatives to protecting a directory's content while still making it accessible to people that are authenticated to view it?

Also, couldn't someone try to bruteforce their way in, causing strain on the server?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

Several things to notice:

Adding security in a .htaccess can always be done without the .htaccess, by using <Directory> instructions in the main configuration (or the virtualhost configuration). It will go faster (if you remove completly support for .htaccess with AllowOverride None) and you wont get the risk of someone altering your .htaccess.

There's several ways of adding security in .htaccess files, one of these ways is by using Basic HTTP Authentification with .htpasswd files. These .htpasswd files shouldn't be in the web directory root. One of the other possibility is using HTTP Digest Authentification, with the restriction that very old browsers won't support it (like IE6).

We usually encounter HTTP Basic Authentification. This is a very weak protection, simply because of the way it works. At the 1st request you're rejected, then your browser ask you for a password and login, and memorize this password login association for the webserver requested. Then for every request sent to this webserver until you close your browser the login and password will be added in the request header, unencrypted. There's simply a base64 encoding applied to the string 'Yourlogin:Yourpassword', to make it look like a pure ASCII7 strings and prevent encoding problems.

So anyone sniffing your request (wifi hotspot, man in the middle, local network, echo switch, etc) will know your password and login. Bad. The rule is ":

never ever use Basic HTTP Authentification if the connection isn't HTTPS (SSL).

If your webserver is completly in HTTPS no problem (see edit on the bottom), the clear text/password are encrypted by SSL.

For the brute force problem (and yes, some people can try to brute force the login/password, except if you tune a mod_security module to prevent that) the Security Consideration of the htpasswd page is quite clear:

When using the crypt() algorithm, note that only the first 8 characters of the password are used to form the password. If the supplied password is longer, the extra characters will be silently discarded

and:

On the Windows and MPE platforms, passwords encrypted with htpasswd are limited to no more than 255 characters in length. Longer passwords will be truncated to 255 characters.

So use SHA encoding hashing for passwords (even if it's not salted).

Another way to let authenticated user browse a directory content is to handle the directory listing and file upload within your application (PHP, Tomcat, etc) and not with the apache automatic listing. In term of security the automatic listing module (mod_autoindex) is something you shouldn't even have on your running apache.

Edit

Full HTTPS server is not required if you want to protect only some url with HTTP authentification. What you really need is that all these protected url should be in https, if non-protected url are in the http domain the authentification headers won't be used as this is a different domain (and the authentification headers are sent by domain). So you could add basic redirection rules in the http domain for these url, maybe something like that:

RedirectMatch 301 ^/secure/(.*)$ https://www.example.com/secure/$1

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...