I'm trying to protect a folder with Digest Authentication through a .htaccess file:
AuthType Digest
AuthName "Restricted Area"
AuthUserFile /web/htdocs/www.domain.com/.../.htdigest
Require valid-user
I've created the file of passwords with the comand "htdigest".
All works fine on my local server ... but not on my remote server (hosted website)!
The browser shows the login panel even if I enter a correct password!
On the remote server PHP is running as CGI not as a module of Apache ... should be this the cause? Is there some workaround?
A Basic Authentication with .htaccess works fine on the same remote server!
If the script is running as CGI, that means it is running as the local user, not as www, which is probably the problem, yes. Is CGI the only option?
The code above is missing the AuthDigestDomain directive, about that the documentation says:
This directive should always be
specified and contain at least the
(set of) root URI(s) for this space.
Omitting to do so will cause the
client to send the Authorization
header for every request sent to this
server. Apart from increasing the size
of the request, it may also have a
detrimental effect on performance if
AuthDigestNcCheck is on.
However, I've definitely solved the problem by enabling the Apache module mod_auth_digest instead of the module mod_digest.
Related
I am trying to secure a website with an .htaccess file with Apache2. It works well but the message specified with the AuthName line is not visible on Chrome (but it is visible on Firefox !). What should I do to make it visible on Chrome?
Here is my .htaccess file
AuthType Basic
AuthName "Restricted Access"
AuthFile "/etc/apache2/.htpasswd"
Require valid-user
On Firefox the pop-up tells
The site ... is requesting your username and password. The site says: "Restricted Access"
But on Chrome it only tells
Sign in
What should I do to make it visible on Chrome?
There is nothing you can do.
The browser decides whether it wants to display this information to the user in some way, or not.
The phrasing used in the Apache documentation already hints at that (highlights by me) -
https://httpd.apache.org/docs/2.4/mod/mod_authn_core.html#authname:
The string provided for the AuthName is what will appear in the password dialog provided by most browsers.
https://httpd.apache.org/docs/2.4/howto/auth.html#gettingitworking:
The AuthName directive sets the Realm to be used in the authentication. The realm serves two major functions. First, the client often presents this information to the user as part of the password dialog box. Second, it is used by the client to determine what password to send for a given authenticated area.
Here is a workaround which can give some info for your unlucky visitor, using custom error document feature after the login attempt fails:
Put this line into your .htaccess file:
ErrorDocument 401 YYYY-MM-DDTHHMM-Site-update-under-way-Estimate-30-min
The continuous text seems to get displayed after login fails or is canceled. No dots (.) or colons (:) allowed. Of course it should represent a valid filename, but if the user has no access to public_html due to login fail a file maybe can't be served anyway. If You can serve a proper 401 error page, You can explain the situation there.
(edit 1) Maybe this behaviour is a curiosity in my case with shared hosting. The shared server there seems to be nginx which I guess "is forced" to accept .htaccess directives.
(edit 2) Confirmed this behaviour also with Apache 2.4 server
I am trying to password protect my whole website temporarily, using .htaccess and .htpasswd
The .htaccess file reads:
AuthUserFile .htpasswd
AuthGroupFile /dev/null
AuthName EnterPassword
AuthType Basic
require user xxxxxx
When I try to access the website, an ID and password are requested:
To view this page, you must log in to area “EnterPassword” on xxxxx.com:80.
Then I get this:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, postmaster#xxxx.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
After I typed the password several times, I still get this. Why?
Is it not finding the page where I want to go after I type the password successfully? (the index.php - should this file be linked somewhere?)
Or is it something else?
I've set up a small test server that does custom two-factor authentication on Apache, using a mechanism similar to this:
In <VirtualHost> file (of course, there are lots of other settings!):
<Location /2factor>
PerlAccessHandler Apache::TicketAccess
ErrorDocument 403 /perl/login.pl
</Location>
So, when I try to access a file in the /2factor directory I get redirected to a login script where I verify a user, password and TOTP from Google Authenticator, if an appropriate cookie is not present. This all works perfectly from both a browser and a smartphone app.
I've been asked to move this code to IIS, but all the example code I see uses either the browser's built-in authentication or LDAP-based solutions. How should I approach this? I'm not wedded to Perl; a C#-based method is perfectly acceptable.
Note, my test environment is just IIS 5.1 and XP.
i have a website that need to be unavailable for public.
I cannot test my website locally because lot of contents are depend on databases and images.
At present i am using .htaccess to deny all the people,bots and allow my ip address to use the site. What happens i have a dial-up ADSL modem and my ISP connection is frequently disconnecting. So i need to change the allowed IP address in htaccess frequently.This is terrible.
Is there any other way to overcome this situation. I saw an article to make the site password protected. is it okay or what should i do to overcome this terrible scenario.
Thanks
Yes, password protecting is fine. Follow this guide: http://httpd.apache.org/docs/2.2/howto/auth.html
You need to create an htpasswd file, essentially the file that holds your username and password. If you don't have shell access on your hosting plan, you can go to an online generator and create the file locally and upload it to your hosting site (don't put it in your document root).
Then add this to your htaccess file:
AuthType Basic
AuthName "Restricted Files"
AuthUserFile /usr/local/apache/passwd/passwords
Require valid-user
You can also whitelist IPs like you did before but you need to add this line:
Satisfy Any
So that your Allow from 123.45.67.89 lines is sufficient and don't need to log in from that IP.
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?
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