Security at Transloadit
We should distrust platforms that claim they are 100% secure, and you won't catch Transloadit making claims like that. Our pledge instead is that privacy & security is our number one concern. We openly share what we do to keep you safe.
What we do to keep you secure.
Here’s a list of things we are doing to keep you and your data secure.
#securitychannel where we raise awareness and share and discuss all the latest relevant threats. We continuously review and update policies here.
Authorization & Encryption
Hardening & Process
Uptime & Continuity
Responsible Disclosure of a Security Vulnerability.
At Transloadit, we care a great deal about security. We realize that mistakes can happen, but we are always looking to fix and prevent those. That is why we really appreciate it when you notify us if you find a security issue.
If the issue is valid - i.e. when we think it
should be fixed, and you are the first to report it - you will be awarded a place in our Hall of Fame.
For severe cases we hand out swag of choice from
Hall of Fame
Please include in your report how you would want to be credited in the Hall of Fame. You can supply a site and a name or handle, but we draw a line where things get too noisy, spammy, or offensive.
Automated tools can generate a lot of noise for our audit tools, so we ask you not to use those.
Please keep in mind that we do have rate-limiting for login failures and many other events, but that it kicks in quite late.
In addition, some parts of our website are static and hosted on S3. We cannot set some security headers there without passing each request through Lamda which we decided is inefficient overhead, knowing that with plain HTML files, the attack vectors that these headers intend to reduce, do not apply.
Hall of Fame
The following security researchers have identified and responsibly disclosed vulnerabilities to us. Top 3 is shown on the list. To see the complete list of people who have contributed to make transloadit a safer place click the show hall of fame button.
If you have questions about Transloadit security in general, here are a few Security-related questions and their answers from our FAQ:
Are the UUIDs that Transloadit uses for files and Assembly IDs secure?
Transloadit uses UUIDv4 for generating these IDs randomly. Guessing, or generating a UUID that matches one of ours, would be as probable as generating a collision. This is so improbable that it is not considered a viable attack vector.
Since we keep around five million Assemblies in active storage at any given time, the chances are admittedly five million times more likely to generate a collision. That being said, since we rate-limit to 250 operations per minute, it would still take machines longer than mankind has existed on earth to generate enough UUIDs to have a 50% probability that one of those will match a UUID that Transloadit has once generated. We deem this far from being a viable attack vector.
For files, the window gets even smaller again as we remove them after 24 hours. A few reasons for why we choose to do this are outlined here.
Beyond the guessing of files or Assembly URLs, it is of course a concern that these addresses would leak somehow. We consider an Assembly ID and file URL private. They are a secret shared between Transloadit, our customer, and depending on your integration, the specific end-user for whom the customer is supplying the files and running the Assembly on your behalf.
This communication between these parties happens over HTTPS, for which we have A+ grading on SSL Labs across the board. If HTTPS is used for integration with Transloadit and the end-user for any request involved, the URLs to Assemblies and files can not leak beyond these trusted parties, to the likelihood of becoming a viable attack vector.
Then there is Transloadit to look at as trusted party. Our policy is that only our trusted core-team-members have access to these files for debugging purposes. We receive millions of files every day and they are just UUIDs to us until a customer asks us to take a closer look.
We run all our processes as non-privileged users, injecting secrets, so if an attacker has possessed these secrets, that means they have gotten root access to our machines somehow. In this case, encryption of the file buckets would not suffice, as with the credentials acquired to get full access to the bucket, the attacker almost certainly also has access to our decryption keys, as is the case when we regard Amazon as hacked. Luckily, both Amazon and Transloadit have a very high focus on keeping our systems secure. But it is true that anyone who would give you a 100% security guarantee here, does in fact, not quite understand security, and you would be wise to steer clear.
Can I whitelist Transloadit's IPs in my firewall?
Our platform is highly volatile in the sense that we'll have 1000 servers online today that will be gone tomorrow. Trying to keep your firewalls up to date with this pace is asking for dropped connections.
We don't funnel outgoing connections (e.g. /sftp/store or Notifications or /http/import) through one point because of performance and SPOF reasons. Using a fleet of proxies that scale along with load puts us back in the same problem, and using NAT has prohibitive limitations performance-wise. The trade-off of our decision to have maximum reliability & throughput is that our outgoing IPs change rapidly.
How are my Amazon S3 credentials protected?
If you want us to store files in your S3 bucket, it is recommended to save the credentials in a Template in your account. We keep this Template encrypted in our database.
The keys needed to decrypt these are injected into process memory by another system user. This means that if someone was able to exploit the user under which we run our API or website processes, they could still not access the keys. If they tried to change our code to display or send the credentials, they would have to restart the service (not permitted under that user) and access the key files (also not permitted).
If our servers are rooted, it is a different story. This is why we use firewalls, use protected SSH keys, and limit our sudo, but as any expert will tell you, 100% security is a myth and it is better to prepare for the worst.
This is why we recommend to create IAM policies that only have Put and List permissions on your buckets (for an up to date and precise list of the required permissions, please check the S3 Store documentation), and let Transloadit use that for writing only. So if your credentials were ever stolen and the criminals managed to decrypt them as well - they would still only be able to add more files to this particular bucket, until we notice and intervene.
While, as said, 100% security is a myth, our security philosophy is to make it as hard as possible to for anyone to gain access to your credentials and the keys necessary to decrypt them, and if they do manage to acquire them, to make them as useless as possible.
MD5 is not a secure hashing algorithm, why are you using it?
First of all, for signature authentication and all other things that need to be secure we do not use MD5. We provide MD5 hashes for files as a means to detect duplicates from trusted sources, as well as for other purposes where there’s no rewarding use case for the attack vector of calculating colliding hashes.
Since MD5 is both faster to calculate and even more widely available than, for instance, SHA1, a deliberate trade-off was made by providing MD5 hashes for encoding results. It goes without saying that, since MD5 is not secure, you should not be using these hashes as building blocks for anything that is security sensitive in your application.