CLASP Password Manager
Concept of Operations
COP4331 - Processes for Object Oriented Software Development - Fall 2014

Modification History:

Team Name: Group 8

Team Website: http://www.cs.ucf.edu/courses/cop4331/fall2014/cop4331-8/

Team Members:

• Nigel Carter (therealnigel@knights.ucf.edu)
  
• Cindy Harn (charn@knights.ucf.edu)
  
• Mathew Church (matchurch@knights.ucf.edu)
  
• Thomas Bergens (tjbergens@knights.ucf.edu)
  
• Michelle Edwards (michie@knights.ucf.edu)
  
• William Pearigen (wapmon@knights.ucf.edu)
  

Contents of this Document

The Current System
The Proposed System:

• Needs
• Users and Modes of Operation
• Operational Scenarios
• Operational Features
• Expected Impacts
• Analysis

The Current System

The current system is for a user to risk remembering their various username and password combinations for their myriad of accounts on different websites. This results in a plethora of forgotten username and password combinations denying access to the account that the user needs at that time. Multiple attempts to remember the password for that specific account based website leads to account lockouts and/or many password recovery requests.

The alternative to the previous method is to write down the password and username and risk someone stumbling upon it and gaining access to the users account and personal information. Also, the user could lose the paper that the account information was scrawled upon and then have the same consequences as the previous method. Then the consequences could also be faced when the platform, such as a laptop, with the installed password manager is not accessible to the user at that time and place.

The Proposed System: Needs

The system being proposed is a multi-user secure password manager. A web server will allow for the account creation and password recoveries. This will also assist in the storing and returning of the information, such as the encrypted passwords, username information, as well as their associated account website. The server will communicate with a client-side app that will provide the web server with a master password and username using some form of secure key pair encryption.

Upon successful account credential verification, the client will be sent all of the encrypted usernames and passwords associated to the client's master account. The account information will then be decrypted locally and displayed for the client. However, while the username and the corresponding account will be displayed, the password will remain hidden. This default setting will not change unless copied from the manager and pasted into a text field of a separate process, such as a password field in an internet browser, or if the client decides to display the passwords through the settings.

The application will allow for new account usernames and passwords to be created on the master account. Furthermore, the user will be able to modify or even delete accounts already tied to the user's master account as long as the user is connected to an internet connection.

The Proposed System: Users and Modes of Operation

The system will include the following classes:

1. Admins - This class is responsible for maintaining the server and its content. There will be access to the server data, but not the privilege to view decrypted customer information since the server will only store encrypted data. The admin will also be responsible for fixing bugs in the system and updating the desktop application.

2. Users - This class is responsible for the maintenance of personal accounts and security of their local machine. All of the users will be allowed to access their own master account as well as the control to add, delete or modify passwords associated with their accounts.

The Proposed System: Operational Scenarios

Users will be able to create an account with the necessary information. The system will save the information and create a personal database for the user to store their passwords. The user will also be able to add, edit, and delete passwords from the database after logging into the password manager. Once logged in, the server will send the encrypted database of all the user's usernames and passwords that have been stored, followed by the application decryption process. The data will then be accessible by the user in plaintext.

The scenario may arise in which the web server is inaccessible for some reason. This may be due to loss of internet connection by the user, or failure of the server itself. Consequently, the user will not be able to access their passwords unless they have previously saved them elsewhere. A further risk is that the server may have an unacceptably high latency when it is overloaded as a result of serving too many users concurrently.

The Proposed System: Operational Features

Must Have:

• Data of the usernames and passwords must be encrypted and secure so as to not leak any account information making it accessible to others.
• The Password Manager has to be accessible on multiple platforms, such as for desktops and tablets.
• Product must be an ease-of-use and incorporate keyboard shortcuts, such as copying-and-pasting a password onto the website.
• There must exist a master key so the user can prevent other users from accessing stored passwords on the platform.

Would Like to Have

• The interface is aesthetically appealing to promote all of the functionalities of the system.
• Incorporate a multi-language support to allow more universal usage of the product.

The Proposed System: Expected Impacts

The final product of the proposed system will have the expected impact of allowing the user to have a wider scope of accessing their account information. This implementation of the design removes the possibility of a user being locked out of their account or requesting a new password. Without the obligation to memorize all of the account details or bring the machine with the installed password manager everywhere, the user receives an increase in convenience and accessibility, thus reducing the chances of facing difficulty even further.

The Proposed System: Analysis

Expected Improvements:

• Multi-user platform to allow information to be obtained on several machines

Disadvantages:

• Increased difficulty of implementation for a multi-user project
• Initial chosen platform may need to be reconsidered

Limitations:

• Time (only have a couple of months until the project must be submitted)
• Money (the project will be done with zero budget)
• Technologies (restricted to what each user knows, along with technologies that can be learned within the timeframe given)

Risks:

• The project may not be completed in time due to the limitation
• The design may be found out to be ineffective and have to start over (prototype model should mitigate)

Alternatives and Tradeoffs:

• The chosen implementation may not be as secure as the highly tested and widely used alternative password management systems
• The system trades off a wide number of options and features for fewer more developed and stable features

This page last modified on October 21, 2014.

Please do not reproduce this page.