Analysis ratelimiting

[baltpeter]

Since analysing apps takes quite a lot of time and resources, we unfortunately need to implement ratelimiting to prevent abuse of the service and ensure all users actually get the option to use the tool without having to wait forever for a spot.

[baltpeter]

I found https://www.npmjs.com/package/rate-limiter-flexible, which seems perfect for our use case. And as the name implies, it is indeed very flexible, so we can extend/adapt our ratelimiting strategy in the future if necessary.

[baltpeter]

At the moment, the only sensible property we can ratelimit by is the user's IP address. We will implement user accounts in the future, which we can then use additionally, but for now, we only have the IP address.

Since IP addresses tend to be personal data from data protection standpoint, we need a legal basis for processing them in this way, with Art. 6(1)(f) GDPR being the only option. Our legitimate interest here is obvious: It would be impossible to run our platform in a way that works at all for users without ratelimiting and as I said, the IP address is the only property that we can use (besides, it's the most obvious and common one for this purpose, anyway).

In addition, we will implement technical measures to limit the impact on the user's fundamental rights and freedoms as much as possible:

• We only work with hashed IP addresses.
  • But, since the IP address space (IPv4, anyway) isn't exactly huge, it is very feasible to reverse a hash of an IPv4 address.
  • Thus, we use a randomly-generated and sufficiently large salt.
• The salt is regenerated for each ratelimit period (1 day?) and only kept in memory. Thus, old hashes automatically become worthless after each ratelimit period. After the salt is thrown away, it is essentially impossible to reverse the hash.
• Nonetheless, we of course only keep the hashes in memory and never write them to disk.
• We use Argon2id as the hash function. Argon2id is recommended for password hashing and compute-hard.

[baltpeter]

One gotcha to keep in mind: I'm using hash-wasm to compute the Argon2id hash of the IP. I was quite confused as to why its function for verifying a hash isn't passed the salt:

const isValid = await argon2Verify({
  password: 'pass',
  hash: key,
});

As it turns out, Argon2id hashes are typically stored in PHC string format (outputType: 'encoded' in the hash-wasm options, implementation). This format includes all parameters that were used to generate the hash, including the salt.

That of course makes a lot of sense for its intended purposes like password hashing, where you would otherwise have to store the salt alongside the hash anyway. But as I explained above, we explicitly want the hashes to become worthless when we throw away the salt of the day.

We'll instead be using hash-wasm's hex format, which doesn't include the salt.