Technical information about our security practices

A big part of our commitment to your data protection is the security of our systems. We hold ourselves to high standards, but there is always room for improvement. Running a secure and robust web service is ongoing work at Loco, so this document will be updated from time to time.

Password hashing

Let's start with the big one: We don't store passwords. We store bcrypt hashes. This allows us to verify any password presented to us (such as when logging in) but the original password cannot be reversed from the hash other than through an infeasibly large number of guesses.

Each hash has a random salt and a "cost" factor of 10. The following is a hash of a password comprising three words in the English dictionary: $2y$10$Am7tsxy2qygsNej.U718kOSuvcpFYYzYl/khr3bq6nvx6Y9cTgo2W

Good luck reversing it. From a list of ten thousand words you could make a trillion guesses, but computing bcrypt hashes is so slow that this approach is unworkable even with very fast computers.

Future upgrades

From time to time we will upgrade the strength of this hash. This could be due to the emergence of vulnerabilities, or [inevitably] because computers have become faster. In such an event we double hash every password in our database instead of waiting for you to log in again.

Example: When Loco first launched we were using sha256 hashes before upgrading to bcrypt in Oct 2016. Users that haven't logged in since then will now have a hash that's a bcrypt of their old hash. Effectively: bcrypt(sha256(text)). This method ensures weak legacy passwords are never left lying around.

Password strength

We don't currently enforce strong password usage on the part of users, but this is on our roadmap to implement. In the mean time please use something suitably long, or random. As shown above, three adjoined words create a lot of randomness while still being easy to remember.

Staying signed in

Our auto-login feature uses the same bcrypt algorithm to hash a random 24 byte token. The clear text of this token is set on a long-lived cookie and regenerated every time it is used to log you into the site automatically. In effect this mechanism is identical to the password login, except the "password" (token) is stored on your computer until it is used.

This feature exists due to popular demand. If you're serious about protecting access to your Loco account, we recommend you don't use it.

API keys

A full access API key allows anyone in possession of it to modify and delete your translations. Although stolen keys would be worthless outside of the Loco API, you still don't want them falling into the wrong hands. For this reason we don't store full access API keys on our servers. Once a generated key appears on your screen, that's the last time we'll see it and it cannot be recovered.

We hash API keys using a function based on MD5. This is well known to be a weak hash, largely because it is fast. We chose this function deliberately for performance reasons, but we're confident that the huge range of our keys makes reversing the hashes a practical impossibility.

Our keys are unique, random strings of which there are 256^24 possible combinations. That's over six trillion, trillion, trillion, trillion. This is an example plain text key: pvfPG0zYZUkbbM5RXS2QOgAKN4U6r9H8b

If you were in possession of our database and had the resources to compute 200 billion hashes per second it would still take you trillions of years to produce a single working key from our tiny subset of combinations. We believe this provides a safe balance between speed and security, but as computers become faster we can easily upgrade the hash strength in future.

Data in transit (SSL certificates)

The Loco website and API are only available over SSL. (Actually it's TLS only). We've disabled various features known to be weak or vulnerable, and have a score of A+ on Qualsys SSL labs.

From time to time we may change our certificate. It's currently provided by Sectigo and expires on 26th August 2025.

Data at rest (Disk encryption)

It's important to note that although security between your data and the web is strong, our disks are NOT encrypted at rest. Disk encryption may be implemented in future, but currently it would make our servers incompatible with our hosting provider's backup system.

Please note that no credit card numbers are stored on our disks, not even temporarily. See card transactions below.

Servers and databases

Our main servers are hosted with Linode and located in the UK. You can read about their physical security here. Take particular note of the high level of certification awarded to their London data centre.

Our back end database and application servers are on separate hardware from our front end web servers and have no Internet-facing services except on port 22. (see next paragraph). Access to database servers from application servers requires a strong password in additional to firewall access over the local network.

None of our servers can be accessed over SSH without a certificate. SSH access using a password is disabled, and SSH login by the root user is completely disabled.

In addition to our main servers in the UK, we also use Amazon S3 to store uploaded files and backups. These buckets are located in Ireland. All files stored on S3 are protected from public access with authorized access being granted via AWS Signature Version 4.

Card transactions

Our credit and debit card payment provider is Stripe, which means that we don't have access to card numbers. All card transactions are performed using Stripe's pre-authorized tokens. Our access to the Stripe dashboard is protected by two-factor authentication. Even when logged in to Stripe, we still don't have access to card numbers. Please see our privacy policy for more information on payment data storage.

We generate card tokens using the Stripe.js v2 API. Although this all takes place over SSL this API is no longer automatically PCI compliant. We are working on upgrading our systems to use newer Stripe APIs and/or provide a PCI self-attestation document (SAQ A).

Bounty hunters

Loco does not operate a bug bounty programme.

If you've not been invited to test our systems for vulnerabilities then please refrain from doing so. Users or IP addresses that appear to be probing our servers, (or using our services in any suspicious or potentially harmful manner) tend to be blocked.

Feel free to tell us about any flaws or bugs you discover, but no remuneration will be forthcoming unless arranged prior to your commencement of any work resulting in such findings.