PROJECT: NUS Hangs

Overview

NUS Hangs is a desktop Schedule Manager application. It has a GUI but most of the user interactions happen using a CLI (Command Line Interface). It is a Java application written by developers of F11-4, to target small/mid-size interest/study groups in NUS.

Summary of contributions

  • Major enhancement: implemented security mechanism

    • What it does: manages command execution rights to two main stakeholders

      • Guest users (users without account): can only execute read-only commands

      • Admins (users with account): can execute all commands accessible by guest users. On top of that, is able to execute commands related to add and editing of data.

    • Justification: This feature secures the information stored in the application by restricting write and modification rights to admins (typically committee members of an interest group), while allowing all users to reading rights to the data.

  • Minor enhancement: added an encrypt function

    • What it does: encrypts password before storage to prevent compromising of password information.

  • Code contributed: [Functional and Test code]

  • Other contributions:

    • Project management:

      • Set up issues tracker on Github:

        • Created labels

        • Created project board

        • Set up milestones and deadlines

        • Set up branch protection

      • Trial release for .jar in v1.2.1 [Pull Request: #145]

    • Documentation:

      • Created initial UI mockup [#1]

      • Updated Quick Start portion in User Guide [#209]

      • Updated Manual Testing portion in Developer Guide [#225]

    • Community

      • Created Initial Personal Portfolio Pages for all members [#197]

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.

Security (Leslie)

Create an account: create

Create an account in the system. The password is case sensitive.
Format: create u/USERNAME pw/PASSWORD

(Coming in v2.0: Stores account details after closing and reopening app.)

At this stage, the user is required to create a new account each time they restart the application
To prevent unauthorized users from creating an account, only admin or other logged in users can create account
Admin Username: admin, Admin Password: adminPassword

Examples:

  • create u/sampleUser pw/dontUseWeakPassword

Login to an account : login

Login into the system.
Users are required to login to execute most commands of the NUS Hangs

Format: login u/USERNAME pw/PASSWORD

Examples:

  • login u/username pw/dontUseWeakPassword

Encrypt password

Encrypts password so that it will not be stored as plain text. This function runs when dealing with user’s password.

Changing password: update_pw [coming in v2.0]

Change the user password, requires user to be logged in first.
Format: update_pw c/CURRENT_PASSWORD n/NEW_PASSWORD

Examples:

  • update_pw c/password n/newpass

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.

Security Mechanism

Reason for Implementation

In a typical interest group setting, there are two main stakeholders. The (1) committee members whom organizes events and the (2) group members whom participates in the event. In this context, these two stakeholders are the main users of NUS Hangs.

The security mechanism is implemented on the following premises:

  • The application is used by the interest group on a shared computer

  • The application is offline

  • Only the two stakeholders mentioned have access to the shared computer

Based on the above premises, the main objectives of the security mechanism include:

  • Restrict group members to read-only commands

  • Only committee members can add and edit information stored in the application

The following activity diagram illustrates the workflow involving security mechanism.

SecurityMechanismActivityDiagram
Figure 1. Activity Diagram of Security Mechanism

The three main components that works together to achieve this workflow are:

  1. Account creation

  2. Account login

  3. Validation of login status prior to executing functions

Current Implementation

Account Creation

The first thing a new user must do is to create a new account. To prevent unauthorized members from creating an account, the create command can only be executed if the user is logged in. A default admin account is provided (username: admin, password: adminPassword) to allow the committee members to create their first account.

The following sequence diagram illustrates the interactions between the different classes in the process of creating an account.

CreateCommandSequenceDiagram
Figure 2. Sequence Diagram of Create Command

There are four new classes that are added to AddressBook4 in the implementation of account creation:

  • CreateCommandParser: parses input arguments and creates a new CreateCommand object

  • CreateCommand: creates a new account for NUS Hangs

  • Accounts: represents an account with username and password fields

  • UserAccountStorage: storage of account credentials in a hashmap

Minor extensions are added to the other existing classes in AddressBook4:

  • AddressBookParser: added the create command keyword for parsing

  • ParserUtil: added functions to parse username and password

Login Account

The following sequence diagram illustrates the interactions between the different classes in the process of logging in to an account. Upon successful login, LoginCommand changes the flag in AddressBookParser to allow users to execute add/edit commands on top of read-only commands.

LoginCommandSequenceDiagram
Figure 3. Sequence Diagram of Login Command

There are four new classes that are added to AddressBook4 in the implementation of account login:

  • LoginCommandParser: parses input arguments and creates a new LoginCommand object

  • LoginCommand: login to an account of NUS Hangs

  • Accounts: represents an account with username and password fields

  • UserAccountStorage: retrieval and checking of account credentials in a hashmap

Minor extensions are added to the other existing classes in AddressBook4:

  • AddressBookParser: added the login command keyword for parsing, added a check on login status to control commands execution

  • ParserUtil: added functions to parse username and password

Design Considerations

Aspect: Implementation of UserAccountStorage

Alternative 1 (current choice): Storing account credentials in a HashMap

Pros: HashMap is one of the simplest data structures to make use of. It’s especially useful since it maps values to keys. In this case, username serves as keys while the passwords serve as values to be stored in the hashmap.

Cons: By default, adding a duplicate key would overwrite the initial value. i.e. if a username is already used, the password would be changed. To prevent this, we need to implement a function to check for duplicate username before adding the account credentials.

Alternative 2: Storing account credentials in a LinkedHashMap

Pros: captures the order of account creation

Cons: LinkedHashMaps is implemented by maintaining a doubly-linked list running through all entries to capture the order. This additional data structure results in additional memory usage.

Aspect: Implementation of Encrypt

Alternative 1(current choice): SHA-256

Pros: SHA-256 is a one-way hashing algorithm. This means that it is not feasible to invert which prevents unauthorized users from getting the plain text passwords. In version 1.4, NUS Hangs is an offline application situated on a single shared computer. Hence, a simple hash function is adequate in preventing unauthorized users from retrieving the passwords from the application.

Cons: Shorter hash outputs makes it easier to brute force.

Alternative 2: SHA-512 + Salting

Pros: Longer hash output that is less predictable protects it from rainbow table attacks.

Cons: Uses more memory space to store the longer hash output.

Aspect: Validation of Login Status

Alternative 1 (current choice): Login Status Flag implemented directly in AddressBookParser

Pros: This allows for simple implementation to control commands rights

Cons: As the amount of commands increases, this might become difficult to maintain.

Alternative 2: Creating two different parsers for read-only commands and add/edit commands

Pros: Easier to maintain as the amount of commands increases

Cons: Requires significant changes to the current architecture.

Limitations (version 1.4)

Account Credentials does not persist

Account credentials are stored in a hashmap. The problem with the current storage of account credentials is the lack of persistence, i.e. when the user closes the application, the account credentials are lost. In the future version, this problem will be solved either by storing credentials in an external file (such as .xml, .txt) or in a database.

No restrictions on password

There are no restrictions on password, namely there is no checks to ensure that the passwords are strong. This means that users can use weak passwords or even leave the password field empty to make it easy to log in.

Appendix A: Instructions for Manual Testing

Given below are instructions to test the app manually.

These instructions only provide a starting point for testers to work on; testers are expected to do more exploratory testing.

Launch and Shutdown

  1. Initial launch

    1. Download the jar file and copy into an empty folder

    2. Double-click the jar file
      Expected: Shows the GUI with a set of sample contacts. The window size may not be optimum.

  2. Saving window preferences

    1. Resize the window to an optimum size. Move the window to a different location. Close the window.

    2. Re-launch the app by double-clicking the jar file.
      Expected: The most recent window size and location is retained.

Creating an Account

  1. You can use NUS Hangs without creating an account. In that case, you are restricted to the following read-only commands:

    1. help

    2. list

    3. find

    4. select

    5. find_group

    6. view_group

    7. view_slots_all

    8. view_slots_ranked

  2. Prerequisites: The application is set up such that you have to login in order to create an account. This prevents unauthorized creation of account and manipulation of stored information.

    1. Login with the following command login u/admin pw/adminPassword

    2. Create a new account using create u/newuser pw/strongerpassword

    3. Login to the new account using login u/newuser pw/strongerpassword

At the current version, user account credentials are lost upon closing the application.
If you restart the application during testing, you are required to create a new account or simply make use of the default admin account provided.

Create command

  1. Test case: create u/newuser pw/pass
    Expected: Account is successfully created.

  2. Test case: create u/nopass pw/
    Expected: Account is successfully created. The password field is allowed to be blank, although not recommended. This is a way to allow admin to quickly login to the application.

  3. Test case: create u/ pw/
    Expected: Account is successfully created. The username and password fields are both allowed to be blank, although not recommended. This is a way to allow admin to quickly login to the application.

  4. Test case: create u/admin pw/pass
    Expected: Account is not created as the username is already in use.