Detailed Design

CLASP Password Manager
Detailed Design
COP4331 - Processes for Object Oriented Software Development - Fall 2014

Modification History:

Version	Date	Who	Comment
v0.0	09/19/2014	Cindy Harn	Created Template / Empty Document
v1.0	10/14/2014	Cindy Harn	Wrote and uploaded the Design Issues section.
v1.1	10/17/2014	Cindy Harn	Uploaded the Traces of Requirements to Design section.
v2.0	10/21/2014	Cindy Harn	Upgraded the design / layout of the page.
v2.1	10/23/2014	Cindy Harn	Uploaded the Detailed Design Information section.

Team Name: Group 8

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

Team Members:

Contents of this Document

Design Issues

Detailed Design Information

Trace of Requirements to Design

Design Issues

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.

Associated Risks with Reusability:

The reusable source code may prove to be faulty or incomplete, and harm any potential reuse of the code later on in the future. Thus, all previous versions of the source code must be kept in order to revert any incorrect changes. In addition, each functionality of the system should be thoroughly tested to ensure the accuracy and reusability of the code.
A particular reusable code may appear similar to another required functionality in the system, but is difficult to reuse and implement into this functionality. Thus, if the amount of necessary time to spend to modify and reuse a component would be unreasonably large, then the programmer should make the decision to code the functionality from scratch and save crucial time.

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.

Associated Risks with Maintainability:

In order to prevent incompatibility issues, each member of the group will utilize the same programming language and environment. Furthermore, due to the software creating and utilizing reusable components, there may be the risk of group members accidentally utilizing or modifying old source code. To prevent this from happening, the most recent source code will be listed in Github for the members to modify, and any conflicting or incorrect changes made may be reverted.

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).

Associated Risks with Testability:

There may be a fault discovered during the testing phase despite individual functions carrying out their separate tasks properly. This may cause the situation to be difficult to find the source of failure, as one program will most likely influence another program in the same system. So all of the source code must be modified to a minimal (avoiding unnecessary changes) along with all changes being saved in a version control procedure.

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.

Associated Risks with Performance:

In the case that the server is down, users will become unable to log in or retrieve any of their stored passwords. The users should then be notified with a return message of the current inability of the server to securely connect the users' account and will re-establish connection as soon as possible.

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.

Associated Risks with Portability:

The selected programming language may cause the software to be unable to work properly across multiple platforms. Therefore, the programming language selected must be widely implemented in the system of different platforms. In this project, the Java programming language was selected, such that any machine with JVM (Java Virtual Machine) may run the software.

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

Associated Risks with Safety:

The selected encryption methods or the security of the stored information may later appear to not be safe enough. If such a case appears, the group should be quick to respond and restore the safety of the system in order to prevent any potential harmful results to the users.

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.

Associated Risks with Prototypes:

The planned prototypes may prove to be inadequate to perform all of the required functionalities of the system or simply incorrect in its design. So before the group begins focusing all of their time in developing the prototypes, sufficient planning and research should be done to verify the correct implementation of the prototypes.

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.

Detailed Design Information

Use Case Diagram:

The user from the main menu will be able to do three actions: register for a new master account, recover their master password if they have forgotten it, or log on to the password manager. From there the user will be able to add, edit or remove any of the usernames and passwords associated to the various accounts the user has stored in the database.

Class Diagram:

Front-End

Back-End

Sequence Diagrams:

Event Types	Actions for: Can't Reach Server
External Stimuli	User attempts to log in without connection / server is down
External Responses	Report error through client software
Internal Data and State	Software cannot establish connection to the server, login does not succeed

Event Types	Actions for: Log In
External Stimuli	User enters correct username and password and presses button to log in
External Responses	User is successfully logged in, can access their accounts
Internal Data and State	User is logged in to the server successfully

Event Types	Actions for: Log In (Failed)
External Stimuli	User attempts to log in with either invalid username or password
External Responses	User is not logged in, error message is shown
Internal Data and State	User remains not logged in to the server

Event Types	Actions for: Log Out
External Stimuli	User is currently logged in and presses button to log out
External Responses	User is successfully logged out
Internal Data and State	User is no longer logged in to the server

Event Types	Actions for: Register
External Stimuli	Account information is filled out correctly and submitted by user
External Responses	User account is generated
Internal Data and State	Server creates new entry for the user, including account information

Event Types	Actions for: Password Recovery
External Stimuli	User clicks on the password recovery button
External Responses	User is allowed to recover or their main password after filling out information
Internal Data and State	Server verifies information and allows user to recover password

Event Types	Actions for: View User Database
External Stimuli	User logs in successfully and clicks on the accounts button
External Responses	User is shown a list of their accounts
Internal Data and State	Server verifies credentials and login state, and sends accounts list if valid

Event Types	Actions for: Add Account
External Stimuli	User is in the user database screen and clicks the add account button
External Responses	User is allowed to choose a name for their new account if still logged in
Internal Data and State	Server verifies credentials and login state and accepts / adds new account if valid

Event Types	Actions for: Login Timeout
External Stimuli	User's login session times out and user attempts to access their information
External Responses	User is presented with a login dialog box
Internal Data and State	Server verifies credentials and allows the user to continue if valid

Event Types	Actions for: Remove Account
External Stimuli	User select account and clicks remove account button
External Responses	User is presented with a dialog box asking them if they are sure, clicking yes completes the operation
Internal Data and State	Server verifies credentials and deletes the account if valid

Event Types	Actions for: Edit Account
External Stimuli	User selects account and clicks edit account button
External Responses	User is allowed to view and edit the details of the account
Internal Data and State	Server verifies credentials, and sends account details if valid

Event Types	Actions for: Save Account
External Stimuli	User clicks save account button in edit account screen
External Responses	User account is saved
Internal Data and State	Server verifies credentials and updates account information if valid

Trace of Requirements to Design

Functional Requirements

Functional Requirements	Direct Trace (Implementation)
The program will incorporate validity checks on the users to allow login into accounts.	A hash of format (PBKDF2) will be generated using our key generated for encryption/decryption as the phrase input and the Master Password as the salt. This will act as our Password Hash that we give to the server to store for authentication.
The program will establish communication with the web server if the login was successful.	A token will be generated upon authentication with the server. This token will be used when passing HTTP requests to the server for authentication.
The program will perform an error handling exception if the application does not have an active network connection, and allow the user to retry connection when applicable.	The HTTP handler within java will return an int that signifies "HTTP Status-Code 408: Request Time-Out" upon a connection error due to loss of connection. This will be handled by retrying a number of times until the client gives up and notifies the user of a possible connection issue.
The server will return the user's password database upon successful connection, and then decrypt it on the application.	Upon successful authentication, a token will be returned. This token will then be used to get the user's Vault from a URL request to the web service. The response will be a JSON formatted Vault with a some meta-data of the user along with their passwords stored in the vault. This will be serialized into the proper objects within the Java client for display.
The user will receive the permissions to access any username and password they have saved in the past.	Once the user has authenticated with the web service and received their token, they will be able to request their Vault which includes all passwords and other data they have stored. They will be able to edit this data to their liking, and submit the data back to the server, along with their authentication token, for processing and storage.
Depending on which user is logged in (the parameter), the program will return the necessary database.	The response for the correct user's Vault data will be returned using the authentication token to identify the user. This will be compared against the database within the web service to query for the appropriate vault to retrieve, convert to JSON format, and submit the HTTP response to the client.
After the user is finished, the program will support the choice to log out and the database will be re-encrypted and sent back to the webserver, ready to be accessed and decrypted again at any time.	The user can either log out or "save" their Vault which will carry out this feature. This will prompt the client to gather the objects which contain the encrypted information into JSON format. This will be a single JSON file that will represent the user's vault. The vault will then be sent back to the server with the authentication token and the JSON Vault in a POST request to the server. The server will then update this data as needed within the database for that user's vault.

Interface Requirements

Interface Requirements	Direct Trace (Implementation)
Upon opening the application, the user will input their master username and password to access their database.	The start window of the GUI will display two entry boxes for the user to type in and enter their username and password to log into their account that will then be connected to the server.
The output after logging in will be the decrypted database of information sent back from the server in response to the login.	Upon "logging in", the user's Vault will be retrieved using the authentication token. This is encrypted information in JSON format. The client will use the key generated from the user's credentials to decrypt this data, serialize the data into objects, and display the information to the user.
The database will be consisted of strings for all the usernames and passwords stored by the user.	The user's credential list will be base64 encoded and encrypted client-side. This information will be organized in JSON format to be sent to the server. The server will take this data, as is, and perform an UPDATE query to MySQL with the new data for the user's table in the database.
When stored in the web server database, the information will be turned into some form of hash code, but will still be a string.	The data stored in the database will be in exactly the same form as was received by the client, after parsing the JSON "Vault". The data will be a string that was base64 encode and then turned into ciphertext by the user's encryption key.
The data for the user will be transferred every time a user logs on or off of the application.	The user's Vault will be retrieved upon every log in and will be sent for updating to the web service upon saving or logging out of the application.

Physical Environment Requirements

Physical Environment Requirements	Direct Trace (Implementation)
In order to host a web server for the user databases, a dedicated machine is necessary.	In particular, the server will be a Xen VPS on a quad-core Xeon 3.0 GHz with 2GB RAM.
This machine will be kept off site in a secure location, safe from physical intrusions. There are also precautions for temperature, humidity, fire safety, etc.	The machine will be kept in a secure room that can only be accessed via a lock. The room environment will be maintained to ensure the suitability of storing the machine at the location.

Users and Human Factors Requirements

Users and Human Factors Requirements	Direct Trace (Implementation)
The system will support regular users and administrators. The user will only need a minimal skill set in order to operate the application since there will be a simple interface for them.	The system will be accessible to administrators to maintain the server and the application. The front-end of the application will be simple enough that it will be self-explanatory to use.
Each user will have their own database that will be saved on the server. The interface will be universal for all users, since the options will be limited.	Each user's Vault will be stored within a table of the application's database. This table will consist of the credentials of the user that is stored in the vault, with the authentication token acting as the primary key.
If someone tries to log into another user's account without their permission, then the account will be locked for a set amount of time.	If the submitted credentials are invalid for 3 consecutive times within 5 minutes, all future requests for the next 30 minutes under that user's account will return a HTTP 401 Unauthorized response, if those requests do not have authentication tokens passed with them.

Documentation Requirements

Documentation Requirements	Direct Trace (Implementation)
For the users, there will be a simple form of documentation.	There will not be much necessary documentation aside from the users' personal database. Once they access the database from the web server, it will be sent back to them and printed on the screen (using special characters for the password so it can't be copied over the shoulder.
The administrators will have these databases, along with some common logs and debug files.	The web service will include a number of logging features such as SSH logs, HTTP access logs minus any POST request/response bodies, server statistic logs including past load, I/O wait, and free memory. The web service application itself will have debug logs enabled, but only a low logging level in production which will write only the most severe errors or warnings to the logs. The database will have error logs as well as slow query logs enabled for debugging and load investigation.

Documentation Requirements

Direct Trace (Implementation)

For the users, there will be a simple form of documentation.

There will not be much necessary documentation aside from the users' personal database. Once they access the database from the web server, it will be sent back to them and printed on the screen (using special characters for the password so it can't be copied over the shoulder.

The administrators will have these databases, along with some common logs and debug files.

The web service will include a number of logging features such as SSH logs, HTTP access logs minus any POST request/response bodies, server statistic logs including past load, I/O wait, and free memory.

The web service application itself will have debug logs enabled, but only a low logging level in production which will write only the most severe errors or warnings to the logs.

The database will have error logs as well as slow query logs enabled for debugging and load investigation.

Data Requirements

Data Requirements	Direct Trace (Implementation)
The main calculations will be for the encryption and decryption of the databases. Depending on the technique used, different hash formulas may be used, requiring precise solutions. If some of the formulas are off, then they may not result in correctly encrypted and decrypted account information, leading to irreversible data loss. Keeping these formulas precise and consistent will ensure that all data is safe and reliably accessible to the user.	Since we have an encryption key, we can use that together with a cipher to produce our ciphertext to be sent and retrieved from the database. We are using a symmetric cipher called AES-256 to encrypt/decrypt data. This let's us use one key to go both ways with the data. The key itself will be generated using the "PBKDF2WithHmacSHA1" implementation in Java.

Data Requirements

Direct Trace (Implementation)

The main calculations will be for the encryption and decryption of the databases. Depending on the technique used, different hash formulas may be used, requiring precise solutions. If some of the formulas are off, then they may not result in correctly encrypted and decrypted account information, leading to irreversible data loss. Keeping these formulas precise and consistent will ensure that all data is safe and reliably accessible to the user.

Since we have an encryption key, we can use that together with a cipher to produce our ciphertext to be sent and retrieved from the database. We are using a symmetric cipher called AES-256 to encrypt/decrypt data. This let's us use one key to go both ways with the data.

The key itself will be generated using the "PBKDF2WithHmacSHA1" implementation in Java.

Resource Requirements

Resource Requirements	Direct Trace (Implementation)
Team of administrators to maintain the server and application	Upon deployment, a small team would be used to maintain the application. The datacenter would handle maintaining a server as we would migrate to "Managed" services within the datacenter.
Space online for a server in order to store the encrypted user information	Currently, the disk space is configured for 30GB of SSD data storage in a RAID 10 configuration. This allows for some amount of redundancy as well as good I/O performance.
Working bi-weekly, span should last about three months	Until the submittal of the project, the group will set up meeting times via online posts, meet at the designated times, and complete the assigned tasks until the completion of the software.
Funds for server fees and any other necessary tools	The development time for the server of a period of 3 months was issued for free by the provider. Any additional time can be allocated for 10 dollars per month.
Eclipse IDE, JDK 1.7, web server	The web server for development is using a built-in Django web server, based on Python's simple HTTP server. In production, a reverse proxy would be used with an Apache module to handle requests from Apache to be forwarded to the Python handler. The Eclipse IDE will be the main IDE in use by the team. This IDE is completely free, as well as the plugins that are being used with it. JDK 1.7 with the latest updates is being used to compile the client application.

Security Requirements

Security Requirements	Direct Trace (Implementation)
Access to the system must be controlled since there is account sensitive information.	Access to the system is limited by SSH access within the container as well as dropping into a shell from the main node of the VPS. The administrator of the main node is considered trustworthy and access to the node is restricted to SSH keys of the administrator in question. SSH access to the VPS is separated into one account for each member of the team. History logging is enabled to track all commands that were processed during each SSH session. Root SSH access is enabled as well but it requires and extremely strong password for authentication. All SSH access is limited to 3 failed logins for each account before the IP responsible is banned within the firewall (IPTables). This is all logged through SYSLOG so that any abnormalities can be dealt with accordingly.
Even though all the information is encrypted on the server, it will still be kept separate for each user for simplicity.	Each user will have their own table whose permissions for query will be limited to root and the user created for the web application. The web application will be constructed sufficiently so that queries to each table will only return data for the user that instigated the query. The user does not have a direct line of control to the database. The user is limited to only retrieving and updating their table in bulk in the form of encrypted JSON data which helps with sanitation of input.
The User Interface will not store any information.	The User Interface will be used only as a connection to the web server and as an encryption and decryption tool. The interface will be a separate entity from the OS and other programs.
Everytime the user accesses their password information on the server, the information will be decrypted and then re encrypted when the user is finished.	The Vault will be retrieved from the server in JSON format, where each field within the JSON is fully encrypted from when the user previously stored their information. The decryption key will be regenerated using their main credentials as input in order to decrypt this data. Once the user is done editing or viewing their credentials, the data will be encrypted again by using this generated key, converted into the JSON format, and POSTed back to the server.
All of the information on the server will be backed up on a daily basis on a local and remote server backup.	The application itself is stored within version control on a number of the team member's machines. In addition, the application is pushed to a remote repository hosted on GitHub which will act as a backup for our application. In the event of data loss on any machine, the code can simply be cloned back to the application server or the developer's machine to continue with production. In the case that the application moves to the production phase, a full-featured backup solution will be implemented where the server's configuration files and application data will be stored off-site on a nightly basis, either via FTP or RSYNC.
Server location will be protected against fire and has ample physical security to avoid theft.	The server location is hosted locally in Orlando, FL with a trusted company. The datacenter has a number of alarms and monitoring systems to prevent and act against an immediate fire threat. The datacenter is protected by both RFID authentication and biometric authentication to prevent unauthorized entry. In the case of unauthorized entry, a trap door configuration is implemented to prevent entry into the datacenter floor.

Quality Assurance Requirements

Quality Assurance Requirements	Direct Trace (Implementation)
The system should be available for access by the users at all times since the machine should be running the webserver at the designated secure location at all times.	The system should be simple to maintain with only an application and a web server to look after. With this use of this web server, users will be able to access their data from any platform at any location, so long as they have stable network connectivity.
The user should be presented with relatively quick access and response times, with the connection strength taken into account.	Each database will only be composed of text, leading to a small storage space. Thus, there will be ample room for a large number of users to store their data and still be relatively light in resources.
If there is no network connection, then the application will experience a fault and allow the user to retry when connection is successful.	Upon server connection failure, the front-end application will display a notification message for the user of the situation. The server should restore its status as soon as possible or be fixed by the maintenance team.
There will be a fault catch if the wrong user information is entered too many times, locking the application for a set amount of time.	If a set of credentials submitted are invalid for 3 consecutive times within 5 minutes, all future requests for the next 30 minutes under that user's account will return a HTTP 401 Unauthorized response, if those requests do not have authentication tokens passed with them.

This page last modified on October 23, 2014.

Please do not reproduce this page.