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 6 Current »

Security issue

How dealt with

User security

  • Each user is required to register an account.

    • Details are then stored on the database.

  • 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

    • Who was emailed.

Secrets security

  • Our service requires a number of secrets to operate, which are kept private and never published into the GitHub repo. These include:

    • logins for the email server

    • the secret used to encrypt the jwt tokens.

  • 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 “secretssection.

    • 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, ensuring privacy

  • The server is also deployed on heroku with 2 step verification enabled to keep the database login and server admin tools secure.

  • No labels