Security Issues

Handling Sensitive Data

Our software will store emails and passwords to authenticate users. These are both highly sensitive pieces of information. Because of their sensitivity, user emails and passwords will only be stored in Firebase Authentication which hashes and salts passwords before storage and is built by Google, a company with the resources and expertise to implement authentication to the current standards. Thus, data of this kind will be safely stored.

Our app will also store personal information about the students in each class. This information may include full name, graduation year, and photos. We will store information of this type in Firebase Realtime Database. Firebase (and all Google customer data) is encrypted at rest. Furthermore, it is also encrypted in transit since Firebase Realtime Database uses HTTPS to communicate with its clients. Thus, this data will be encrypted and secure whenever it is not being stored and displayed on our users’ devices. We will also maintain another layer of security by using Firebase Security Rules. These enable developers to specify exactly what kind of data clients can read and write (typically based on the user’s UID or their read/write privileges). We will use these rules to allow users to access only the data relevant to them.

Protection Plan Against Attacks

There are many attack vectors that malicious users may try to gain access to sensitive information from our app. One method of attack is to gain the login information of a user using various techniques like phishing or using keyloggers. To protect against these attacks we will assure users that our app will never request their login credentials outside of the login screen of our app. We may also use multi-factor authentication so that a user needs to enter more than an email and password in order to access their account. Furthermore, we may notify users of new logins on their account when they occur.

Another attack vector is abusing weak security rules allowing unauthorized users to access data. To avoid this method of attack, we will ensure our rules are as restrictive as possible. Users will only be able to access data relating to the classes they have created. In our Firebase Realtime Database, every object will store the UID of the user that created it. Our security rules will then limit access to these objects so that only users who created the objects or have had them shared with them can read/write to them.

Yet another attack vector is through weak authentication. If password strength is unchecked or new accounts are not verified, malicious actors may easily create fake accounts or break into current accounts and attempt to gain unauthorized access. To avoid these problems, we will enforce strong password rules and send email verifications whenever a new account is created with an email.

Finally, another attack vector is using data input into the app. Many methods of attacks abuse the failure of apps to sanitize text or other data inputs. Although this is a more significant risk with web applications (with methods such as XSS attacks), we will still sanitize all inputs in our app. Sanitation will happen both on the client-side and database-side. We will perform basic checks on the client’s side like input length and characters used (alphanumeric characters plus a handful of special characters will be allowed). In our database, we will define validation security rules (with the “.validate” tag) to further check the input. Throughout our application, we will maintain a separation of data and code to ensure that user data cannot be interpreted as code.