CLASP Password Manager
High-Level Design
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

High-Level Architecture

Design Issues

High-Level Architecture

• The Front End Application represents a major component with an interface built for the user to use. It will be located on the user's local machine. It will not store any user account details locally, and will only include the items needed to run the Desktop Application. Upon execution, the application will establish a connection with the database server. After established communication, the application will request the master account information from the user or provide options for password recovery or registration of a new account. Then that information will be sent to the database server. For password recovery, the server will send the challenge question and have the user reply. If the reply is correct, a random password will be generated and sent to the user's associated email. (Upon the next login that user will be prompted to enter a new password.) For new user registration, the application will collect the required user information and send it to the server. For normal account login, if the login attempt is successful, the application will receive a copy of the encrypted account information from the server. It will decrypt the data and allow the user to edit any accounts, including adding new accounts or removing existing ones. After logout, the application will re-encrypt the new information and send it to the database server before ending communication with the server and exiting.


• The Database Server of the software is another major component in order for the software to execute. Every time the desktop application is executed it will connect to the database server. The application will then send the user's master account login information and wait for access to the server. If the account login is successful, the server sends a copy of the encrypted information associated with the account to the desktop application. Upon exiting the desktop application, the application will send the encrypted information back to the database server, which the server will then use to replace the old information associated with the user's account. If the desktop application receives a password recovery request, it will lookup the username and reply with the associated security question. If a correct response is sent back from the user, then the server will generate a random password and send it to the user's associated email address. Furthermore, the server will mark the account to prompt the user to change his/her password upon the next successful login. If the server receives a new user registration request, it will compare the information received to its current master account database. If the information provided by the user is unique, then the server will reply with a success and store the new user information in its master account database.


• The Webservice will be a web site where the public may download a copy of the front end application. As of this writing it will be hosted on the database server. The front end application, once downloaded through the webservice, will be stored and installed on the user's local storage.

Design Issues

All of the evaluation of the issues described below are relevant to the project, as each impact the performance and the behavior of the overall system.

Reusability:

• There should be reusability in the design of the password manager, such that the design can be used in a similar project. In other words, the code should incorporate different classes, each with a specific purpose to manage their own set of functions. So these separate entities that are related to one another can then be modified and adjusted to a new purpose without recreating the entire system. The major components of the code will be to encrypt and decrypt passwords, create or edit account information, as well as to send and recover passwords between the user and the server. Therefore, the fundamental functionalities of the source code should be reusable to assist the development of an improvement or change in the password manager.

Maintainability:

• Once the project has been completed, the program should be easily maintained for any fixes or updates. Even during the development of the project, the code should be broken up into adequate parts to support cross checks and general changes. The main approach to the maintainability of the project will be in the form of documentation of the finished product. Extensive commenting will be encouraged throughout all aspects of the project. Standard naming conventions will be used to ensure consistency and readability of the project for any future developers or for maintenance needs. Documentation will be generated from these comments in the form of the JavaDocs for the client application. This allows for near-consistent documentation throughout the project, as a specific format must be followed when creating comments and function descriptions for the documentation.

Testability:

• The software has to be able to be tested to verify the encryption of the data to maintain the security of the passwords. Furthermore, the password manager should be tested for easy accessibility in recovering the requested passwords without any loss in data during the transfer of information. Thus, the system will be tested on its accuracy in taking an entered password, encrypting the string, and then returning a decrypted password that should match exactly (including case-sensitive).

Performance:

• The team has discussed several measures of performance as well as the maximum time for several operations In particular, the system should be able to securely transfer data, efficiently perform encryption or decryption, as well as quickly find the account information. Therefore, the response from the server back-end should be sufficiently fast (no more than three seconds) to allow the user to have a smooth experience.

Portability:

• The program has to work across a number of different platforms, so that a user may access it on devices with different operating systems (such as between Windows and Linux). As a result, the front-end will be created in Java to maximize cross-platform compatibility. Then the program will be accessible to the user via a download, such that the user has portability in accessing the password manager.

Safety:

• Security is important for a password manager, as it is necessary to maintain the confidentiality of the user's passwords. Without proper security, an attacker can discover vital passwords, allowing them access important information, such as to bank and credit card accounts. With this in mind, we have decided to use common standards in Information Security. The recommendations of NIST [http://www.nist.gov/] have been taken into account, as well as guidelines on password storage approaches as outlined by OWASP [www.owasp.org]. OWASP provides "cheat sheets" for various implementations of information security. Specifically, the group will be using the Password Storage, Authentication, and REST Security cheat sheets as a guide for designing and implementing the security aspects of our system:
  https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
  https://www.owasp.org/index.php/Authentication_Cheat_Sheet
  https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
  

Prototypes:

• Advanced Encryption Standard (AES) prototype will be implemented to evaluate the design strategy of securely encrypting the data and disallowing any easy access to the passwords.
• Interface prototype will be created and tested to confirm the functionalities of the interaction between the server and the user utilizing the program.

Technical Difficulties Expected:

• Getting the APIs to interoperate properly may take more effort than originally anticipated. Frameworks may prove to be an inadequate fit for a specific purpose due to feature set deficiencies or unnecessary features. As a result, frameworks and libraries may need to be swapped out to maximize compatibility and efficiency. Not all group members share the same technical skills, and additional experience is needed by all group members to complete the project.

Solutions to Technical Difficulties:

• Frameworks will be chosen to maximize compatibility and minimize unnecessary features. In addition, they should be stable between releases.
• Group members will learn any skills required to complete the project.

Architecture:

• Design Trade-offs: The Client-Server Architecture has been chosen as it offers very few trade-offs with respect to the project design. The Password Manager requires access across multiple devices/locations. This is best achieved through the client-server architecture. One trade-off with this design is the requirement of two separate pieces of software working together in the system. There are a number of complications that arise to this. The most important complication is the time constraint to deliver the project. Developing two pieces of software can affect the design approach and the group may need to make some trade-offs on the system requirements should there be any major risks that are realized.
• Reasons for Selecting: The Client-Server Architecture was selected in response to the main functionalities that must be incorporated into a secure password manager. For this type of architecture, there are two types of components. This includes the server to offer services (such as storing and returning account information), as well as the clients accessing the services through a request/reply protocol (such as retrieving their passwords). Thus, this frequent interaction between the user and the server causes the client-server architecture to be the most suitable.

Technical Risks:

• The password manager may not be completely secure, and could be vulnerable to attacks. Any single vulnerability would be enough to compromise the security of the entire program as well as any passwords stored. APIs may change mid-development, forcing code to be rewritten for compatibility if possible.

This page last modified on November 21, 2014.

Please do not reproduce this page.