PROJECT: StardyTogether

Overview

StardyTogether is a desktop contacts and venues manager application specially for National University of Singapore (NUS) students to help them find free time and rooms to study together with their friends.

Summary of contributions

  • Major enhancement: added Password Encryption

    • What it does: allows the student to encrypt their data

    • Justification: This feature gives the student an option of encrypting their data to ensure the privacy of their data.

  • Minor enhancement: added Timetable UI

    • What it does: visualises the timetable for students to see their friend’s timetable.

    • Justification: This feature enhances the looks of StardyTogether, making the user experience better.

  • Minor enhancement: added PersonDetailCard UI

    • What it does: allows the student have a detailed overview of his/her friend.

    • Justification: This feature makes it easy for the student to get all the information needed.

  • Suggested enhancement:Auto Completion and Correction of Commands and Parameters

    • What it does: allows students to auto complete or correct commands or parameters using Tab key

    • Justification: This feature will make using of Command Line Interface (CLI) a lot faster than it currently is, improving the user experience.

  • Code contributed: [Functional code] [Test code]

  • Other contributions:

    • Project management:

      • Managed releases v1.3 - v1.5rc (4 releases) on GitHub

    • Enhancements to existing features:

      • Updated the Tag color scheme (Pull requests , #5)

    • Documentation:

      • Did cosmetic tweaks to existing contents of the User Guide: #79 #105 #161

    • Community:

      • PRs reviewed (with non-trivial review comments): #135, #138, #191

      • Reported bugs and suggestions for other teams in the class (examples: 1, 2, 3)

Contributions to the User Guide

Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users.

Encrypting data files : encrypt (since v1.2)

To encrypt ST and protect your data, you can enter the command encrypt followed by your password.
Format: encrypt PASSWORD

  • Passwords are case-sensitive.

  • The password string can only contain characters in the UTF-8 format.

Examples:

  • encrypt test
    Encrypts addressbook.xml with "test" as the password.

Subsequently, when you are re-opening the app, you will be prompted to enter your password, as shown in the picture below.

passwordBox

Removal of password: decrypt (since v1.3)

To remove the password protection of ST and decrypt addressbook.xml, you can enter the command decrypt.
Format: decrypt

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

Data Encryption

Current Implementation

We are using javax.crypto.cipher and java.security.key package provided by java for the encryption of the data. The SecurityUtil class is used to provide the SHA-1 hashing and AES encryption/decryption required.

Using a given password, it is first hashed using SHA-1 to be used as the AES key. The first 128 bits of the digest created by the SHA-1 hash is extracted. This is required as AES requires its key to be 128 bits long.

  • The encryption can be done simply by using SecurityUtil.encrypt() which will encrypt the addressbook.xml.

  • The decryption can be done simply by using SecurityUtil.decrypt() which will decrypt the addressbook.xml.

  • Currently, decryption/encryption is done in XmlAddressBookStorage class before/after readAddressBook and saveAddressBook.

No encryption is done if the user do not set a password. Users can change their password using the command encrypt and decrypt it permanently using the command decrypt.

When an 'encrypt' command is issued, the argument is parsed and hashed. Is is then passed to the Model.

PasswordSdForLogic
Figure 1. Password Sequence Diagram for Logic Component

The ModelManager then updates the password in the AddressBook as shown below:

PasswordSdForModel
Figure 2. Password Sequence Diagram for Model Component

The 128 bit password used to encrypt addressbook.xml is saved in the address book as XmlAdaptedPassword to ensure that the password is not lost after every reset of the application. This is secure as even if a malicious user were to somehow get a copy of the 128 bit password, they would still need to use a computationally unfeasible second pre-image attack. This is because users are unable to input hashed password directly.

When the user first starts the application, ModelManager would try to load the data from addressbook.xml without using any password. If addressbook.xml is encrypted, this would cause the following code to trigger which would morph the ui to PasswordUiManager instead of UiManager.

private void checkPasswordChanged() {
    if (passwordChanged) {
        ui = new PasswordUiManager(storage, model, ui);
    }
}

This change would cause the PasswordWindow to display instead of the MainWindow, requesting for a password input by the user.

passwordBox
Figure 3. Password Box UI

If the password the user input is unable to decrypt addressbook.xml, a WrongPasswordEvent is raised which will cause the PasswordUiManager to display the following dialog to the user:

wrongPasswordDialog
Figure 4. Wrong Password Dialog UI

If the password the user input successfully decrypts addressbook.xml, a CorrectPasswordEvent is raised. This event is handled by the PasswordUiManager which will start the UiManager. The application would behave as if it is not encrypted from here on.

Design Considerations

Aspect: How to generate the AES key

  • Alternative 1 (current choice): Generating the key from a password

    • Pros: Users are able to key in their own passwords

    • Cons: Users have to input password for their data to be encrypted.

  • Alternative 2: Generating the key within the code into a file for user to share.

    • Pros: It would be guaranteed to be more secure than using our own generated key. This is because keys generated by java.crypto.KeyGenerator have their algorithms reviewed by many experts in the area.

    • Cons: This would require a file to be carried by the user to decrypt their address book which makes it very inconvenient for the user.

Aspect: Where to encrypt and decrypt file

  • Alternative 1 (current choice): Encryption and Decryption done in XmlAddressBookStorage class

    • Pros: Easy and clear to understand implementation where file is encrypted and decrypted before and after readAddressBook and saveAddressBook.

    • Cons: addressbook.xml is in plain text longer than is required.

  • Alternative 2: Encryption and Decryption done where needed in XmlUtil and XmlFileStorage

    • Pros: addressbook.xml is exposed minimally.

    • Cons: Increase coupling of more classes and makes the implementation harder to understand.

Aspect: Where to save the password

  • Alternative 1 (current choice): Save in addressbook.xml

    • Pros: The password is not lost after every reload of the application.

    • Cons: Plaintext of addressbook.xml contains the 128 bit AES key used. However, this is still secure as even if a malicious user were to somehow get a copy of the 128 bit password, they would still need to use a computationally unfeasible second pre-image attack.

  • Alternative 2: Password not saved

    • Pros: No chance of password being compromised.

    • Cons: Password reset after each reload of application.

Aspect: Default Password

  • Alternative 1 (current choice): addressbook.xml not encrypted by default

    • Pros: Users are able to choose whether they want their data to be encrypted or not as encryption and decryption requires computation which may make the application slower than desired.

    • Cons: Unfamiliar users may not be aware of the option of encrypting their data making it less secure.

  • Alternative 2: Default Password provided to encrypt addressbook.xml

    • Pros: Data is always encrypted.

    • Cons: A default password is, most of the time, as effective as no password and it also slows down the application more than necessary.

Auto Complete or Correct feature

Proposed Implementation

Currently, some commands such as add and edit requires many different fills to be filled in for it to work. This makes it extremely tedious as users have to remember what fills are there to be included. Spelling mistakes are also very costly as users would need to retype the command.

When the user press the Tab key, commands ,and parameters carets will auto complete or auto correct. Pressing Tab again would give the next suggested input.

The Auto Correct can be implemented in CommandBox as all user inputs can be easily accessed in it. Editing the text already entered can also be done easily in CommandBox.

Since all commands are in the form of String, we can use a TreeSet of the current input’s character to find the closest matching command and traverse the TreeSet to get other suggestions.

To prevent a situation of the need to differentiate between a auto completion of the next parameter or getting the next suggestion of the current command or parameter, next suggestion is always chosen before a space is entered and auto completion only happen for non-empty strings.

Suppose that the user wants to type the encrypt command, he can press Tab to auto complete.

commandautocomplete
Figure 5. Auto Completion of Command

If he were to have a spelling error typing encrytp instead, the Tab key would instead correct it to encrypt

commandautocorrect
Figure 6. Auto Correction of Command

Now suppose he is trying to add a friend, once he types p/123 and press Tab after the space, e/ caret will be auto completed for him.

parameterautocomplete
Figure 7. Auto Completion of Parameter

Design Considerations

Aspect: What is done after user presses Tab key

  • Alternative 1 (Suggested): Automatically completes for the user.

    • Pros: Easy and improves efficiency of typing. Familiar for users who uses CLI frequently.

    • Cons: Can be confusing as can be auto complete or next suggested input.

  • Alternative 2: Suggest to user what is expected

    • Pros: Does not change the user’s current input making it less confusing.

    • Cons: Does not really improve the user experience by much.

Aspect: Where to implement it

  • Alternative 1 (Suggested): In CommandBox.

    • Pros: CommandBox has access to the text showing what is already keyed in, making it easy to implement there.

    • Cons: CommandBox has to do an extra task of determining suggested commands and input, increasing coupling as it would need access to the parser or list of commands.

  • Alternative 2: In Parser

    • Pros: Does not increase the coupling of CommandBox.

    • Cons: Makes changing the current input display a difficult task which may require access to the CommandBox.

Aspect: What to auto correct or complete

  • Alternative 1 (Suggested): Commands and Parameters.

    • Pros: Makes it easy for users as everything can be auto completed or corrected.

    • Cons: Makes it more confusing as sometimes it completes commands while other times it completes the parameters. Also makes the implementation complicated as a clear distinction of Command and Parameters have to be made for completion and correction.

  • Alternative 2: Only Commands or Parameters

    • Pros: Easier to understand.

    • Cons: Not as efficient for the user.