Frequently Asked Questions

Questions about Services and Scripts

Can I require a password for access to a web page?

The short answer, for people who are familiar with Apache web servers and familiar with AFS, is "Yes, stuff.mit.edu supports .htaccess. Just set that up, and restrict the AFS ACL to system:stuff.mit.edu".

Here'a a more detailed explanation. Our web server supports the standard Apache basic authentication feature. This means that you can create a .htaccess and .htpasswd file that, together, will result in your web-site visitors being presented with a password prompt.

One weakness of a simple password-protection setup is that, for files to be accessible to our web server, they need to be located in AFS. Normally, the files need to be readable to every AFS user or else the web server cannot read them. This means that potential web-site visitors could bypass your password requirement by simply going directly to your AFS directory. This bypassing is very simple for Athena users, since all Athena machines have access to AFS. Also, many people outside MIT have AFS clients on their computers. Together, this means that setting a password would normally prevent casual access attempts by most people outside of MIT, but would not prevent more determined access attempts.

Our web server supports a somewhat better password-protection facility, though. Rather than allowing files to be readable by every AFS user, you can instead make the files readable only by a special AFS group named system:stuff.mit.edu. With this setup, anyone trying to go directly to your protected AFS directory would get a permission error. In conjunction with this change to the AFS ACL, you would set up .htaccess and .htpasswd in the standard way.

To set up password protection, the general sequence of steps is:

• Choose a directory that will be password protected.
• Set the AFS ACL appropriately.
• Create the .htaccess file inside the protected directory.
• Choose a username and password. Do not use your Athena password or your password for any other computer.
• Create the .htpasswd file inside the protected directory.
• Give the username and password to authorized persons.

For this example, we will imagine that you want the directory ~/www/restricted to be password protected. To set the AFS ACL, type the commands:

fs sa ~/www/restricted system:anyuser none
fs sa ~/www/restricted system:stuff.mit.edu rl

The .htaccess file will typically look like:

AuthType Basic
AuthName "My Restricted Directory"
AuthUserFile /afs/athena.mit.edu/user/y/o/yourname/www/restricted/.htpasswd
Require valid-user

The .htpasswd file will normally have one line, and look like:

guest:$apr1$ubzF/ltz$QNuZaPbcy5.Pm.UqkAKep/

The username here is guest. You can have multiple usernames, listed one per line, if you want. For each line, you need to run a program to calculate an encrypted-password string, which is $apr1$ubzF/ltz$QNuZaPbcy5.Pm.UqkAKep/ in this example. Here, the corresponding unencrypted password is a+secret. (Again, this should be a new password, not an important password such as your Athena password.) There is a colon in between the username and the encrypted-password string. An encrypted-password string can be created using the htpasswd command on an Athena workstation. You would type:

add sipb
htpasswd -n guest

New password: 
Re-type new password: 
guest:$apr1$ubzF/ltz$QNuZaPbcy5.Pm.UqkAKep/

Once you have these files set up, you can tell people "To visit my private web site at http://stuff.mit.edu/~yourname/restricted/ use the username guest and the password a+secret". Remember to give a URL that starts with http://stuff.mit.edu/ rather than http://web.mit.edu/ or http://www.mit.edu/. The password protection applies to the directory that contains the .htaccess file, and all directories underneath it (for example, you might also have http://stuff.mit.edu/~yourname/restricted/photos/).

Again, the intent of this setup procedure is to prevent AFS users from bypassing the password protection by going directly to your AFS directory (i.e., typing cd /afs/athena.mit.edu/user/y/o/yourname/www/restricted). It does not provide perfect security, and in many cases you would instead want to use the certificate-authentication capabilities provided by web.mit.edu. Some of the risks are:

• The AFS ACL is really only blocking access to clients that do not have the IP address of the web server. The web server is not actually authenticating to the AFS server via a cryptographic mechanism. Thus, someone who is able to launch a successful address-spoofing attack can access your web page. This is fairly difficult, however. The system used by web.mit.edu has exactly this same weakness.
• The password is not encrypted. Anyone who can sniff the network in between the client and our web server can obtain the password.
• The web session is not encrypted. Anyone who can sniff the network in between the client and our web server can read the contents of your web page, during times when an authorized user is accessing it.
• The AFS session is not encrypted. Anyone who can sniff the network in between our web server and the AFS server can read the contents of your web page, during some of the times when an authorized user is accessing it.