We'd like to preface this by saying that we can all make mistakes from time to time, and learning from experience is part of being human.
Now, with that said, we'll get into the some of the changes we've made.
With RLAPI v3 gaining a boost in development speed we have had to think of a few things to make sure that our user's data will be kept safe. We also strive to protect our users themselves insofar as their involvement with our service is concerned.
As such, we've taken steps to prevent unauthorized access to any and all user data.
Some of those include, but are not limited to:
- Each and every SQL query happening from the API is sanitized and prepared.
- Actions that affect the user's account (such as changing the user's e-mail, or password) are always factored for twice, by requiring the re-entry of the user's password.
- Actions that affect other users (Such as bucket deletion) are always ownership-verified.
- User passwords are encrypted with bcrypt, and are never stored in plain text.
- Password authentication over SSH is disabled on our servers as is usually standard.
- SSH Auth timeout is set low to prevent unattended server access.
- All SSH keys with access to our servers are strong, random-passphrase SSH Keys.
- PostgreSQL and Minio are only available to services on localhost.
- TLS 1.0 and 1.1 are disabled on our service.
- We've added DMARC policies to help prevent email spoofing.
Several of the steps we've taken are on the API level, and most others are in our server configuration which is equally important for a secure environment.
For starters an essential component of security is ensuring that your data is secure in transit, and disabling older TLS protocols is another important step for security as it ensures that traffic to and from our service stays secure. This along with using a secure cipher this keeps our site free from the vulnerabilities that we would otherwise have to rely on browser and web server mitigations to prevent.
We have also made sure that none of our services are exposed to the outside world directly, and instead opted to route our web services and file delivery through reverse proxies.
In practice that means that our internal services do not exist as far as people who do not have access to the server's local network are concerned, and finding a point of ingress is considerably harder if not impossible. This also gives us greater control over how data is served and allows us to implement useful things like load balancing, hosting multiple services in the same space, as well as caching and compression in the future.
That is not to say we intend to be lax on keeping the software and services up to date and properly secure. This instead will ensure we have an easier to maintain secure point of entry that can take into account if exploits have been found and where our own mitigations can be implemented. This is especially important if we have to wait on 3rd party software suppliers to patch something.
Building on what I mentioned previously, we are going to actively do our best to keep our services up to date and as secure possible.To that end we've started using Sqreen as they've recently sponsored our services. Their service helps us keep an eye dependenices for vulnerabilities and keep our services from being attacked by providing us with easy to implement setup scripts and configurations that help mitigate attacks.
We also utilize them in API functions directly to prevent account takeovers and to provide ratelimits for API requests. Sqreen provides a nearly all in one solution to help us monitor service health and and various API metrics as well as monitor and alert us if an attack is discovered as well as allow us to block malicious incoming traffic once identified.
Thanks for taking the time to read through this update, and we sincerely hope everyone is looking forward to the future of this service!