2
$\begingroup$

Sorry if I'm not using the right terminology, as I'm new to crypto.

I want to know the most effective way to protect a database against brute force attacks in the case of a small dictionary.

For instance, suppose I have a user database, and that I want to protect a certain attribute/field of my users that has a small cardinality (e.g. the field can assume one of at most a few hundred values), for instance "country". There are a small number of countries in the world, so a brute force attack would be effective even if I hashed the country field: the attacker could just hash all countries and try those hashes one by one on a given user. Worse, they could use simple statistics to make their guesses more educated.

What should I do in this case? Should I add some salt before hashing? If I store the salt and the attacker gets access to it, is the field still protected?

Edit: My question is not tied to the specific case of the column of a table. Rather, I am asking what are the algorithms to use when the dictionary size is small.

Improve this question
$\endgroup$
4
  • $\begingroup$ do execute query over this data or you just want to retrieve them by querying like username? $\endgroup$
    – kelalaka
    Commented Sep 5, 2019 at 18:42
  • $\begingroup$ I think you're confusing encryption with hashing. Short summary: Encryption is reversible; given the encrypted data (ciphertext) and key, you can recover the original data (plaintext). Hashing is not reversible, and (normally) doesn't have a secret key; you can check whether a value matches the hash, but given the hash it's hard to recover the value. There are also keyed hashes, which essentially combine these: they're irreversible like regular hashes, but also require a key to generate or check. All of these can use a salt or nonce to make equal plaintexts create different results. $\endgroup$
    – Gordon Davisson
    Commented Sep 5, 2019 at 20:30
  • $\begingroup$ I was really thinking encryption, as in being able to recover the original data. Still, my question holds. If an attacker uses brute force in a small dictionary context, they'll succeed. How do people mitigate this? Is it via adding salt? Any caveats? $\endgroup$
    – Stefan Lafon
    Commented Sep 5, 2019 at 21:33
  • $\begingroup$ Your attack model is not clear. Do we trust applications server(s)? Do we trust users? There are many techniques to protect the data but all depends on the threat model. $\endgroup$
    – kelalaka
    Commented Sep 6, 2019 at 6:17

2 Answers 2

Reset to default
1
$\begingroup$

I think you're looking for column level encryption.

It allows you to encrypt specific columns in your database, in your case the cloumn "country".

Another way would be to use database encryption, which can encrypt an entire database. The main disadvantage there would be the speed, because the size of the data to encrypt / decrypt is larger than just the data in a single column.

Just be sure to store the encryption key securely. You can find more information about this topic in this post: SecuritySE - Where to store a server side encryption key.

Edit:

My question is not tied to the specific case of the column of a table. Rather, I am asking what are the algorithms to use when the dictionary size is small.

You could simply use a symmetric-key algorithm, i.e. AES in CTR mode to protect your data. It works for both small and large data.

Improve this answer
$\endgroup$
1
  • $\begingroup$ I guess I didn't mean to tie my question to the specific case of the column of a table. Rather I was asking what are the algorithms to use when the dictionary size is small. $\endgroup$
    – Stefan Lafon
    Commented Sep 5, 2019 at 15:19
0
$\begingroup$

Encrypt this attribute. Good algorithms use a random IV or a random salt. For instance, if you change IV each time, AES CBC will give you different encrypted result for the same attribute value. AES is resistant to brute forcing.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.