Planned features and security considerations
Features
Our system has a web application and a mobile app. Below are the features provided by our applications.
General Covid related information for example:Daily cases and deaths, cumulative data can be viewed for anyone visiting our website. Data will be updated with the Government regularly. Data will be represented both in figures and graphs for easily viewing fluctuations in the statistics.
For registered users, you can login to the account and get the infected percentages of the locations you have visited. You can also view temperature measurements and oxygen levels that were measured at entrances of these places. To register to our system, through the web application you need to upload a clear image of your NIC, and for the mobile app users you can easily scan the barcode of the NIC and get verified. After you can create an account.
The traces will be given in both tabular and graphical views. Other features like searching for the average infected percentage of a specific location, getting the locations with the highest infect percentage of an area will also be provided.
Mobile application users can also use the QR scanning option to check-in to a venue.
Security Considerations
As our system handles critical information of people like SPII(Sensitive Personally Identifiable Information) and Health data, we need to ensure that data protection
is accounted and guaranteed at each and very component of our system. There can be many attack vectors targeting our system when deployed in the community. Below are some attack vectors we figured out in
our software interfaces.
Database System
Conceptual Schema- ER Diagram
This is the er diagram of the relational database of our system. Below is a description of each entity
- MERCHANT-Commercial Merchants can register to our System and they will be provided with an IoT device with the Unique serial number. Their details will be kept in the Merchant entity
LOCAL_COMMUNITY-When people enter into locations scanning their NIC, full details of the person will be entered into this relation
TRACE-We will be keeping track of the locations people visit for a 2 weeks period along with the temperature measurements obtained
USER-When people register to our system they will be added to the user relation. Automated details facility is provided for anyone despite of whether they are registered or not. The registered users have the aditional facility of viewing their traces and getting infect percentages
UNDER_QUARANTINE, INFECT-Our database will be updated with the Government through a REST API to get Covid related information and details about people under quarantine and infects during certain time intervals
Logical Schema
Technology Stack
Implemented Features
UI/UX
Why is it important?
Our system controles the entrance system of most of the commercial and Government places. Our target audience of users Therefore
includes people from different parts of the country and people from all ages. Our applications should be easily intercated by all these different people.
Our interfaces mainly provide statistical and health care data. Highlighting the important data and providing the straight-forward data on to the point are some
main considerations for the UIs.
Features to enhance UI/UX:
- Simple interface
- Color-scheme choices-Green/aquamarine kind of depicts health, growth and hope!
- Data represented in both tabular and graphical views such as Charts depicting fluctuations and maps to easily see the locations with the percentages
- Easiness of finding required information. We have implemented searching options to search for the infected percentage of any particular place or places of an area
- Get the locations with the highest infected percentage of an area
- Persistant sessions of two weeks for personal devices. Users don't have to get authenticated each time they access their account
- Cryptographically signed cookies for 2fa. For personal devices uses can enable this option and they can authenticate just by the username and password and two factor authentication will be bypassed by these tokens
security
Authetication
All the passwords are hashed. Two factor authentication has been added as an additional layer of security.
Authorization
Server-side session based authorization. Why not jwt? In jwt the payload is only signed but not encrypted. The payload can have information
such as username, roles etc. Therefore in case of a browser hijack, these cookies can be seen by an attacker. The hacker can see these information and can get an idea of
what the roles in our system are? what are the UUIDs like?. Considering the criticality of the information we handle, we do not want
any such data to be exposed to an attacker. Session ID doesn't give any such hint. Also these are sent in cookies which are http only cookies,
therefore cannot be accessed by the user or any javascript.
One time tokens for CSRF attack prevention
Since we have persistant sessions, it can lead to CSRF attacks. Eventhough we are only sending any sensitive actions in POST methods,
still attackers can try to trick users by forms that are hidden. To handle that we are using one-time tokens for each form submission and only perform
the action after validation,
therefore the attacker wouldn't have any clue of the token.
Request throttling(Rate limiting)
To prevent brute-force attacks to user accounts and system clashes, we have added throttling. Aftfer a user makes a limited amount of requests
to the server within a timeout, the users requests will not be served by the server after for a timeout.
Hadeling file uploading
The maxium file size has been limited to 512KB and formats have been limited to only images. Even going further we can enhance our system
such that we handle the NIC verification in a seperate domain and send only the sanitized data to our server. Also the images will be deleted automatically after
the verification.
Validity periods
All persistant sessions have a two week validity period.
cryptographically signed tokens as cookies
Tokens for bypassing 2fa will be a UUID that doesn't give a hint of any user details. The mapping is kept on the server. These tokens are sent in
cryptographically signed cookies such that any change made to these tokens, signature validation will not be passed.
Providing only the necessary data
This is something simple yet important. There are no API methods for calling information of a user such as a fullname, NIC, address. A user wouldn't
need to get his own details from the application, only an attacker would! Without these information, even when an account is hacked, it's just some set of data without a recognized owner.