Lab 9
Web Server Security

Due: May 1st, start of normal lab time.
Can be turned in May 3rd with no penalty. Zero credit if turned in after May 3rd, start of normal lab time.

Introduction

This lab will explore a few ways to secure a website using tools on the web server itself. You will briefly explore Apache Web Server settings, and implement your own password database that encrypts user passwords.

Directory Requirements

1. Make a new Lab09 directory. Copy Lab07 into it.
2. Create your .htaccess file in the new directory (or a subdirectory of it).

Apache Server Management

Create a .htaccess file so that your website behaves as follows:

Tip: Windows may not directly allow you to create a ".htaccess" file (because the name begins with a period). You can, however, make a file with Notepad++ and then save it with this name. Be sure to choose "All files" (not "Text files") from the file types in the Save dialog window.

1. Comments: as always, your code must be commented! In this case, you are adding comments to the .htaccess file.
2. Re-Write: create a re-write so that one of your Perl files that took an argument in the URL now instead has a nice URL. For example, you want the user to be able to type in a "nice" URL like:
   http://intranet.cs.usna.edu/~mXXXXXX/Lab09/weather/21401/
   and (silently) the web server will call something like
   http://intranet.cs.usna.edu/~mXXXXXX/Lab09/query.pl?zip=21401
   Use an actual Perl file that is already used by your website. You should not change the name of your Perl file or edit it in any way.
3. Javascript: modify your JS code to make use of the re-write that you just made, e.g. it no longer directly calls query.pl but invokes the same program using the "nice" URL instead.
4. Redirect: create a URL redirect so that you redirect people looking for any file containing the token "passwd" to a fun page mocking their lame attempts to find a password file in your directory. For instance, typing in http://intranet.cs.usna.edu/~mXXXXXX/Lab09/passwds.txt into a browser might redirect to "nicetry.html" that contains an entertaining message. This should not be a silent redirect.
5. Password: add "Basic" password protection to your index.html file, via .htaccess. Make at least two users with valid access - one should be "test" with password "test". Don't try to enter passwords manually (even with a web script that claims to encrypt them for you - this doesn't work!). Instead, run "htpasswd" from the shell. Use it based on the examples given in class (you run it via the command line prompt, not via double-clicking). Hmmmm... what does that -c option do?

Store User Passwords

Write a server-side script to receive usernames and passwords, and store them securely in your database.

1. Signup Form: Create a simple page (signup.html) with just a form that has two text fields (username and password) and a submit button. You don't have to do anything else; just make an empty page with this form.
2. Server Script: Create a perl (or php) script to accept the above form's submission. The script should read the username and password, and store them in a user database.
3. Encrypt Passwords: Do not save the passwords in the database as plain text. Use md5 encryption and save the resulting hashes.
4. Fill the DB: Using your form, submit 10 or more passwords. For this lab, make the username the same as the password, so we can compare in the database. Make sure they are all different passwords.
5. Print the DB: When finished, print the resulting DB table. You will turn this in.
6. Reverse Lookup the md5: Now see how secure your hashes really are. Visit: http://md5.gromweb.com . This website has generated lots of md5 hashes from passwords. Enter 10 of your passwords, and indicate on your DB printout which were found and which where not found in their reverse lookup. If the website is not available, search google for "md5 hash lookup" and just choose a different lookup site.
7. Questions: On your printout, answer these questions:
   • What types of passwords are found in the reverse lookup database and thus your md5 encryption offers no security?
   • Let's assume your users still give dumb passwords. How might you still use md5 but store them in such a way that they are not found in these reverse lookups? In other words, I give you "happy" as my password. How might you use md5 that results in a hash that isn't (not likely) in a reverse lookup, but still lets you check my "happy" password for a match later? (hint: you can search for "salt" online if you are stumped)

Deliverables

Turn in the following hardcopy on or before the due date, stapled together in the following order (coversheet on top):

1. A completed assignment coversheet. Your comments will help us improve the course.
2. Printout of your .htaccess file
3. Printout of your password file. Write the plain text passwords for each user on it.
4. Printout of your database of users/passwords. Manually indicate which hashes showed up (and which did not) in the online md5 lookup. Answer the two questions about the hashes.