Security - Pjiwm/circle-project GitHub Wiki

When sending a request a v4 UUID is attached next to the hash of the object that will be sent in the request.
A JSON array with these two values is encrypted with the private key. The JSON array is converted to a string for consistency accros Javascript and Java.
(This could also be the backend server, when sending something back)
This is the signature and will be placed together with the plain object in the request.

A request should also be broken down later to check its integrity and to do something with its content.
To validate a request and proceed further, the first step is to decrypt the signature with the public key. The key is stored in the database of the backend web server.
The signature is decrypted using the public key resulting in the strinified version of the JSON array with the hash and UUID.
The string is converted to a JSON array object.
The plain object in the request is hashed and this hash is compared to the hash from the decrypted signature. If these are equal, the object has not been tampered with.
Checking the hash alone does not protect against a replay attack. This is what the generated uuid is for. Every uuid that has been used is stored in the database on the web server. If the uuid exists in the database the request has already been sent before, hence the package has been sent twice and is therefore a replay attack.
If the hashes are equal and the uuid does not exist in the database, an OK response is sent back.
The web server also encrypts its response in the same manner as seen in the prior image using the privateKey of the web server.

A private key is given to the user beforehand.

During the fill form process a private key will be inserted. This is where the user logs in.
In the center of the diagram KeyUtils is referenced. This is a library in the monorepo. The same utils can be used in both front and back end. This helps with encryption and decryption consistency.

We chose not to use a CDN service because of the following reasons:

• Lack of time. The time required to correctly implement a CDN would take more time than we had available.
• High cost. CDN services are very expensive, and our current service does not generate enough revenue to justify such an expense.
• Users are local. Our users are located in Breda and the surrounding area. A CDN would not help us.

If our userbase was global and large it would be feasible to implement a CDN. The users would be able to provide us with revenue, and this revenue could be used to buy the CDN services. This would also mean that the latency of far-away users would be improved. Low latency has been proven to increase user activity, causing revenue to increase even further.