Security considerations #4
Description
At the time of this writing, this is just a personal hobby project made primarily for myself. With that, security is nonetheless a critical consideration.
To get off the ground quickly and build a proof concept, Laravel 12 defaults are used. That means using SQLite and the Wealthsimple session/token stored in db to facilitate the desired seamless UX. The idea behind the design is to allow the user to connect Wealthsimple accounts, view a detailed history / audit trail of those connections, and maintain control over them, being able to disconnect or delete sessions as desired. Due to the handling of Wealthsimple session/token, security is paramount.
For local use or testing, the defaults could be acceptable. For an instance running in the cloud or one made available to public, not so much.
The main vectors to design for are:
- Unauthorized access to the user facing application
Basic auth scaffolding is included in the Laravel 12 starter kits, which is fine for local testing during early development. A robust solution is needed to ensure the login being easily compromised is not a low hanging fruit. Laravel has partnered with WorkOS which is one option under consideration to enhance the login flow, but there are many possible approaches here.
If credentials are being handled by the app at all, then they need to be handled with the latest security standards in terms of salting/hashing/encryption. Looking past a basic user and password model, we are looking at SSO, MFA (TOTP, email, FIDO2/webauthn), Magic Auth, passkeys.
The design must strive for a balance of security and usability in line with modern expectations.
- Unauthorized access to the database
This must be taken into consideration during application development to ensure no vulnerabilities that could lead to database being compromised by any external means. Past that, the database being compromised via internal means must also be considered in the design. Data breaches happen, so this is always a risk worth designing for in any application that could be hosted in a remote or cloud environment. A design ensuring any sensitive information is encrypted before being stored in the db helps mitigate this risk.
One of the approaches under consideration is to leverage external key vault services such as HashiCorp Vault, AWS Secrets Manager or Bitwarden Secrets Manager. They are one way to avoid ever having long term storage of the Wealthsimple session/token in the application database. The external key vault service requires a token of its own however, so these are not a panacea and come with their own complexities and trade offs to think about.
- Unauthorized access to the server environment the application is running on
If a determined attacker has root access to the server environment, as is the case with any other web application, all bets are off. With that said, consideration of this vector in the design phase can mitigate potential damage by avoiding dealing with and storing any additional sensitive details unnecessarily and employing best practices.
One future possibility to explore on this front would be to have the application encrypt everything on the client-side prior to sending anything back to the server, leveraging user device local keychain, hardware security key, and/or strong passphrase. This could require a desktop application version to implement well. This is above my pay grade for initial phase of a hobby project, but something I am keeping in mind. These approaches typically detract from usability in multi-device use cases.
- Unauthorized access to the application via compromised end user devices of authorized users
This is a vector that ultimately, little can be done - if an end user's device is compromised, there is no way for the application to know about it - but every effort should be made to foster good cybersecurity posture for users and access to the app should remain secured in the event attacker does not gain access to TOTP etc.