This project has three due dates:

• Friday, April 24: A threat model for the system
• Thursday, April 30: Your working site
• Tuesday, May 5: A security analysis of another group's system

The threat-model deadline is a bit close to the implementation deadline so that you have time to prototype a bit as part of working out your architecture and threat model. These dates do not suggest that you should wait until April 24 to start implementing your site.

You have the option of doing this as a group project. The size of your group will affect the scale of project you need to implement. I'm expecting most groups to be 2-3 students. If you want to form a larger group, you need to implement some additional features that have privacy or security implications.

For the third due date, you will analyze another student/group's submission in two ways: you'll try to attack it (using your threat model for guidance) and you'll assess the usability of its security features. Both the analysis done to your system and the analysis you do of another system will figure into your grade on the project. The security analyses will be done individually, not in groups. This gives each student a clear, solo deliverable as part of the project.

Requirements

Your job is to build a social networking site with at least the following features:

• New members can sign themselves up for accounts.
• Each user has a profile with at least their name, birthdate, email address and school (these are required of all users). Profiles may also include (at least) a photo, home state, and a list of interests.
• Users may maintain multiple categories of friends (ie, from home, from work). Users may tag information in their account as private, public, or limited to particular groups of friends.
• Users may post blog-like entries on their pages. These entries can also be tagged with descriptive categories (ie, music, food, travel).
• Users may subscribe to the blog entries of their friends. They can subscribe to entries in general or on a per-category basis.
• Users may send short (Twitter-like) messages to friends with text or URL links to interesting items. When a user logs in, they see any unread messages issued by their friends.
• [For groups with more than 2 students] Support for third-party applications that use data from the social network. This requires an API for gathering data and a way for users to add applications to their profiles.

Expectations

Threat Model: Your threat model should follow the STRIDE method we used on the second assignment. We should see a systematic presentation of threats to the site, following the STRIDE categories.

Implementation: We are mainly focusing on the security aspects of your implementation for this assignment. Interfaces, for example, don't need to be spiffy visually, but you should pay attention to interface decisions that might have security implications. Your implementation should use components similar to what you would use in a real system (ie, a standard database on the backend rather than just a bunch of files). Our goal is for you to demonstrate secure application skills that you might need in the real world, so don't avoid a real world technology just because the security implications are messy.

Assessment of Another System: For the attacks portion, we expect a writeup like you did for the turnout attacks. For the usability assessment, follow the metrics from the "Why Johnny Can't Encrypt" paper (linked to the readings for the usability class on April 16) to conduct a cognitive walkthrough of the system you are evaluating.

Logistics

In general, I'm open to you choosing your own development languages, with the caveat that there be at least two groups using each language (to simplify the security-analysis deadline).

There is a page on the myWPI wiki for you to indicate groups and language preferences.

Course homepage