Project 3: Feeling Insecure
Phase 0 Due: Friday, October 31, 2025 at 12:40 p.m.
Phase 1 Due: Friday, November 14, 2025 at 11:59 p.m.
Phase 2 Due: Wednesday, December 3, 2025 (Results due in class)
Introduction
Your goal in this project is to create a secure system. Unlike other projects, you are permitted a fair amount of creativity and some freedom as well. The system is very simple: It must provide a basic interface with a few features that are available to anyone running the program, such as a listing of all users. The most important feature of the system is a secret message connected with each user. Because of the number of teams in the class, each system will have at least nine users: one for each team, one for me, and a guest user.
Overview
At its heart, the system you write is just a treasure chest with its riches locked inside, hopefully securely. The system must display a menu of its options. One of this options must be to log in. If the user chooses to log in, he or she will be prompted to enter a user name followed by a password. At a minimum, the following user names must be supported:
- alani1
- garantche2
- guest
- hinkle5
- kent4
- perez10
- rheyne1
- toure3
- wittman1
Except for guest and wittman1, user names will correspond to the leader of each group. Each user name will have a fixed password. Each password must consist only of letters and numbers. Only the team that has created a given system will know the passwords on it. If a user enters a valid user name followed by the password for that user name, the secret message for that user will be displayed. The goal of an attacker of the system is to recover these secret messages.
For example, my user name is wittman1. On some system, my password might be helgoret, and my secret message might be A little sincerity is a dangerous thing, and a great deal of it is absolutely fatal. In that case, part of my interaction with the system might look like the following (user input is marked in green):
Enter user name: wittman1 Enter password: helgoret Secret message: A little sincerity is a dangerous thing, and a great deal of it is absolutely fatal.
The project will have three separate phases:
- Phase 0
Create the passwords and secret messages for everyone in your system. - Phase 1
Design and implement your secure system. - Phase 2
Try to break into everyone else's secure system. Produce a document describing your attacks and also the safe-guards in your own system.
Phase 0
Phase 0 Due: Friday, October 31, 2025 at 12:40 p.m.
Create a list of passwords and secret messages for all users. A password and secret message for your own group is optional. Write (or ideally print from a printer) this list of user names, passwords, and secret messages. Bring this list to class on Friday, October 31 in a sealed security envelope. I will provide a secure way to store all of these envelopes so that no one (including me) can read it.
This step commits everyone to a choice of passwords and secrets so that no one can change his or her mind later. Think carefully about the passwords you will require. Short passwords can be easily broken, but the passwords must not be so long that they are unrealistic to remember or type.
Phase 1
Phase 1 Due: Friday, November 14, 2025 at 11:59 p.m.
During Phase 1, you will be doing the majority of the programming needed for this project. You will create the secure system so that it can read a user name and password and display the secret message. If the user enters a correct user name and password combination, you must print out the secret message. If the user does not enter a valid combination, you must say so. Do not output a garbled secret message if the user enters the wrong user name and password. The user must be clearly informed whether or not the user name and password combination is valid.
The password for user guest must be password. In this way, we will be able to see what correctly entering a user name and password combination looks like in your system. Feel free to choose any secret message for guest.
Also, you will be required to provide a List Users option. This option will list all the users in the system. Additionally, the List Users option should list the number of times successful and unsuccessful log in attempts have been made on each user during the current run of the secure system. Output for the List Users option might look like the following.
User Successful Logins Unsuccessful Logins -------------------------------------------------------------- alani1 0 0 garantche2 0 0 guest 0 0 hinkle5 1 0 kent4 0 1 perez10 1 0 rheyne1 0 0 toure3 2 0 wittman1 0 0
Finally, the menu displayed by your program must have a Quit command. This command is the only legitimate way for your program to end. Your program should display the menu repeatedly until the user selects Quit. If your program crashes before the user selects Quit, no matter what input caused it to do so, this will be judged a failure in the area of Availability. Write robust code!
Open Design (Three-Person Team Only)
An important principle of secure design is Open Design. For professional grade security, everyone should know how your system works and still be unable to break it. For most groups in this class, the principle of Open Design is not a requirement. For the three-person team, however, it is. Along with the executable .class files, the three-person team must submit a short document describing (at a high level) the countermeasures they have adopted. For example, if they do not store the plaintext of the password but instead store a hash of it, they must state that they store a hash of the message. Every conceptual element of the three-person secure system must be explained (and must match the source code that is eventually turned in as well). If this group uses known encryption or hashing algorithms, it should state what they are. If this group uses its own algorithms, it must give an outline of how they work. Specific details involving special constants, specific random numbers, initialization vectors or other fine-grained information may be left out.
Phase 2
Phase 2 Due: Wednesday, December 3, 2025 by 11:59 p.m.
The second major phase of the project is attacking the other secure systems. You should do everything reasonably possible to recover the secret messages for your group's user name from the other 7 (6 other teams + my system) secure systems. You should document your attacks as well as document the features of your system that are resistant to attacks.
Note that you can run a Java program in a class file (such as Wittman1.class) by running the JVM with the name of the class (not the file itself):
java Wittman1
Or if the program is stored in a JAR file, you can run it with the -jar option:
java -jar Wittman1.jar
If your system doesn't recognize the java command, you might need to add it to your path.
Some files might be compiled with very new versions of Java. If you get an error message stating that version of the class file was too new, you might need to install the latest Java JDK to run it.
Be creative! Your attacks might take some of the following forms:
- Brute force trial of passwords
- Reverse engineer code
- Attacks that crash the program
Physical security plays a small role. It's true that I want you to pit your wits against each other, but we cannot break school rules. If someone is discussing the design of their secure system and you happen to overhear them, that's perfectly legal. I must ask that no one use keystroke loggers, spyware, listening devices, or anything else of that nature to learn information about each other's systems. If you have questions about the legality of a particular measure, ask me.
While breaking other people's systems, you will also need to document your own (potentially leaving yourself open to eavesdroppers, if you aren't careful). You must explain each of your countermeasures in detail. Likewise, you should explain how you have used each of the following security design principles or why you didn't use them:
- Least Privilege
- Fail-Safe Defaults
- Economy of Mechanism
- Complete Mediation
- Open Design
- Separation of Privilege
- Least Common Mechanism
- Psychological Acceptability
Many of these principles will not be directly applicable to this project, but you should still give a good explanation as to why not.
Hints
Libraries
You must implement the entire system using only the standard Java libraries. Your code should not do any networking. You should not use any Java cryptography libraries. (BigInteger is fine, though.)
Reverse Engineering
Java .class files can easily be decompiled. Try one of the following:
When designing your system, make sure that you protect yourself against the attacks you plan to make. Think about both attacks and defense at the same time.
Submit
Phase 0
Submit your list of user names, passwords, and secret messages on Friday, October 31, 2025 at 12:40 p.m. in a sealed, security envelope with your group member's names written on the front. I can provide security envelopes if they are not easily available. No grace days may be used for Phase 0 submission.
Phase 1
Your group leader must submit a copy of your secure system (in executable form only) by uploading it to Brightspace. Do not submit your source code at this time! All work must be submitted by Friday, November 14, 2025 at 11:59 p.m. Again, because other students will be attacking your system, no grace days may be used for Phase 1 submission. After the deadline, I will post these executables above. The executable for your secure system must be named after your group leader's user name, as shown below.
- Alani1.class
- Garantche2.class
- Hinkle5.class
- Kent4.class
- Perez10.class
- Rheyne1.class
- Toure3.class
The executable should be a Java .class file which will run without problems by invoking the java command on any computer in the Point 113. Please do not use any packages, since that will make it more difficult to run your program. Note: If you are unable (or unwilling) to put your entire secure system in a single class, you may submit an executable JAR file instead.
Phase 2
Zip up all the .java files you use to solve this problem from your src directory and upload this zip file to Brightspace. In addition to the code, you must include in the zip file a short (no more than 10 page) document describing the design of your system and your attacks on other systems. Include any passwords and secret messages you were able to recover. All work must be submitted before Wednesday, December 3, 2025 at 11:59 p.m. For this final submission, grace days may be used. However, you should bring your list of recovered secret messages to class on Wednesday, December 3, 2025 at 12:40 p.m. so that we can see who defeated whom (and dole out extra credit).
All work must be done within assigned teams. You may discuss general concepts with your classmates, but it is never acceptable for you to look at another team's code (unless you are learning how to break into it!) Please refer to the course policies if you have any questions about academic integrity. If you have trouble with the assignment, I am always available for assistance.
Grading
Your grade will be determined by the following categories:
| Category | Weight |
|---|---|
| Choice of Passwords and Secret Messages | 10% |
| Quality of Design | 20% |
| Implementation of Design | 25% |
| Quality and Quantity of Attacks | 30% |
| Documentation of System | 15% |
In addition, for every one of your group's secret messages that you are able to recover from other groups' secure systems, you will receive 1% point of extra credit applied to your final semester grade. However! You will lose half a point of this extra credit for every group that is able to recover their secret message from your secure system. You can't go negative. That is, people penetrating your system can never cost you more than the extra credit you gain.
Code that does not compile will automatically score zero points.
