0

I'm looking at creating an Amazon DynamoDB table that uses user input as it's hash key. I'm concerned that an attacker could launch a denial of service attack by maliciously choosing keys that have the same hash so that lots of data is added to a single partition.

Amazon's article on partitions doesn't address this issue: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html

Here is an article describing this kind of attack: https://lwn.net/Articles/474912/

This question is sort of similar, but doesn't focus on security, and doesn't have an answer: Is it good to use user-input as partition key value in DynamoDB

smac2020
  • 9,637
  • 4
  • 24
  • 38
Logan Grier
  • 61
  • 1
  • 5
  • 1
    Why would you do that? If you want your users to select the key, then you should hash it yourself after you sanitize it. – Marcin Sep 07 '21 at 04:18
  • The table stores user data. I was thinking of using the Cognito username of the user since it's immutable. I am aware that I could cryptographically hash the username to ensure that it is well-distributed. For my use-case, it makes more sense to assign users a user ID on account creation, and use that ID as the table key. As I understand Cognito, this would be implemented as a custom attribute. – Logan Grier Sep 07 '21 at 12:12
  • 1
    DynamoDB hashes the key for each item with its own salt in order to produce a uniform distribution of keys in the partition key space. However, if the table uses a partition + sort key schema and you accept both as inputs from the user, all bets are off in terms of the distribution in the key space. – Mike Dinescu Sep 07 '21 at 20:26

1 Answers1

1

You are absolutely correct that a user could, at least in theory craft data to have it all hashed to the same partition. It won't be easy - Amazon doesn't publish the specific algorithm they used for the partition hashing, but neither does it claim that it is cryptographically secure. However, for this to be a problem, it also means that you are allowing this particular user to insert huge amounts of data into your database - isn't that already a problem? Moreover, if your plan is to use user id as a key, this exploit would require an attacker to create a huge number of user ids - again, isn't this already a problem that you'd like to solve higher-up?

In any case, as another layer of security you can indeed solve the problem that bothered you: You can use whatever cryptographically-secure hash function that you choose to hash the user id and use the result of that function as the key you hand to Amazon. This will remove the risk that the malicious user could manufacture collisions.

Nadav Har'El
  • 11,785
  • 1
  • 24
  • 45
  • 1
    A lot of techniques that make it more expensive for attackers to create fake accounts also add friction for legitimate users. Fixing vulnerabilities that allow attackers to amplify their attacks adds significant cost for would-be attackers without creating friction. – Logan Grier Sep 11 '21 at 13:35