Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 3 Next »

Security issue

How dealt with

User security

Each user is required to register an account. Their details are then stored on the database. We are hashing the passwords using sha256 to keep the users password secure. Users are allocated sessions when they wish to interact with the service. These sessions then expire after 1 hour. Interactions with the server are tracked with “/sendInvoice” requiring the user to be logged in. All “/sendInvoice” calls are logged, with details as to who sent the request and who was emailed.

Secrets security

Our service requires a number of secrets to operate. These include logins for the email server and the secret used to encrypt the jwt tokens. To keep these private we made sure to never publish them to the github repo. We kept them in a number of secure places. When developing locally we kept a file which was added to git ignore. We also kept them on github in its “secrets” section. This is an encrypted part of github that allowed us to use the variables within our testing with github actions. For access during deployment, they were added to the deployment environment on heroku. The login for our postgres database was also automatically added to the deployment enviorment.

Server security

The secret_key to secure the flask server is a randomly generated key that’s only stored on the heroku deployment server to keep it as private as possible. The server is also deployed on heroku with 2 step verification enabled to keep the database login and server admin tools secure.

  • No labels