I have a web app, in which I am encrypting user data client side. Each client has their own password, which is used to derive an encryption key (via Scrypt) for encrypting their data. Since the data is client side and a hacker has full access to the (encrypted) data, would it be necessary to use a salt for Scrypt? The reason why we use a salt for KDFs is to reduce rainbow tables affecting web servers. Since there is no web server in play here, and the attacker can attack however they like, then a salt would provide no additional benefit, am I correct?
$\begingroup$
$\endgroup$
5
-
1$\begingroup$ Some terminology notes; Scrypt is a password hashing algorithm, not an encryption algorithm. It is designed to hash passwords, not designed to encrypt them. The IV is rather called salt in this context. Now your question is not clear. Are you asking a client uses script to hash a password or for a key generation? Anyway, when the attacker has accessed the scrypt result do you want your users to be vulnerable to existing rainbow tables? $\endgroup$– kelalakaCommented Mar 1, 2021 at 19:36
-
$\begingroup$ Sorry, my question was unclear. I've edited my question so that it now clearly describes the scenario. $\endgroup$– Evan SuCommented Mar 1, 2021 at 19:49
-
1$\begingroup$ The salt is useful in that it helps prevent an attacker from precomputing keys based on common passwords ahead of time. For PBKDF2 NIST recommends a minimum salt size of 128 bits. I've got to believe that something similar should be used here as well. $\endgroup$– SwashbucklerCommented Mar 1, 2021 at 20:24
-
$\begingroup$ But there's no point in precomputing keys since there's no web server to bruteforce. $\endgroup$– Evan SuCommented Mar 1, 2021 at 20:28
-
1$\begingroup$ @HACKERALERT I should note that there is also information security where they have currently 3688 question about passwords. You might want to look at some of them. $\endgroup$– kelalakaCommented Mar 1, 2021 at 21:29
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
Can you guarantee that the users are going to use high-strength passwords like dicewire? What if they are using simple passwords? Are they going to sue you when they are hacked and their data exposed? Lots of questions?
Consider that all of your users are hacked due to a bug in your application, then the attackers can execute a batch attack, too. Using salts can prevent this batch attack.
Using salt is the countermeasure to the rainbow tables where applicable. Therefore you limit them to single searching. In this case, two vectors remain
- How good are the users' passwords?
- How much can the password hashing algorithm slow the attacker?
The answer to the first question has a human side. You can test the quality of passwords up to some point and reject if lower. Teach your users to use the dicewire. Not hard to learn, see XKCD 936
The second question has a better answer as the Argon2id is the best choice. You can parametrize;
- Number of iterations $t$, affecting the time cost.
- Size of memory used $m$, affecting the memory cost.
- Number of threads $h$, affecting the degree of parallelism.
This parameter must be tuned according to your target systems.
Therefore you can limit the attackers to use Massive GPU/ASIC parallel search mostly single case and with the timing, you can cripple their effort.
The recommendation is to use the salt, it is not hard to generate one by using /dev/urandom or similar methods.
And remember that the entropy and output cannot exceed the entropy of the input. Make sure that users have high-strength passwords.
answered Mar 1, 2021 at 20:21