Should we salt informations that are unique and randomSecure hash and salt for PHP passwordsHow does password salt help against a rainbow table attack?Non-random salt for password hashesAre hashed and salted passwords secure against dictionary attacks?Where do you store your salt strings?Any value in salting an already “strong” password?How should I ethically approach user password storage for later plaintext retrieval?Why do salts make dictionary attacks 'impossible'?How can bcrypt have built-in salts?Best Practices: Salting & peppering passwords?
Installing PowerShell on 32-bit Kali OS fails
Resetting two CD4017 counters simultaneously, only one resets
Is there an wasy way to program in Tikz something like the one in the image?
Visiting the UK as unmarried couple
Is there enough fresh water in the world to eradicate the drinking water crisis?
Calculating the number of days between 2 dates in Excel
Is infinity mathematically observable?
Why isn't KTEX's runway designation 10/28 instead of 9/27?
What is the opposite of 'gravitas'?
Why is delta-v is the most useful quantity for planning space travel?
Did US corporations pay demonstrators in the German demonstrations against article 13?
Identify a stage play about a VR experience in which participants are encouraged to simulate performing horrific activities
"lassen" in meaning "sich fassen"
Science Fiction story where a man invents a machine that can help him watch history unfold
Can I create an upright 7-foot × 5-foot wall with the Minor Illusion spell?
A workplace installs custom certificates on personal devices, can this be used to decrypt HTTPS traffic?
Simple recursive Sudoku solver
Partial sums of primes
Simple image editor tool to draw a simple box/rectangle in an existing image
Can I use my Chinese passport to enter China after I acquired another citizenship?
Why are on-board computers allowed to change controls without notifying the pilots?
Have I saved too much for retirement so far?
Lifted its hind leg on or lifted its hind leg towards?
Who must act to prevent Brexit on March 29th?
Should we salt informations that are unique and random
Secure hash and salt for PHP passwordsHow does password salt help against a rainbow table attack?Non-random salt for password hashesAre hashed and salted passwords secure against dictionary attacks?Where do you store your salt strings?Any value in salting an already “strong” password?How should I ethically approach user password storage for later plaintext retrieval?Why do salts make dictionary attacks 'impossible'?How can bcrypt have built-in salts?Best Practices: Salting & peppering passwords?
Salt is used when storing passwords in databases in order to protect against dictionary attacks and rainbow tables.
However, let's assume we need to store unique and random (sensitive) information about users. Is there still an advantage in salting this information before hashing it ?
Wouldn't salt use, in this case, just add randomness to an already random data (unlike man-typed passwords) ?
security hash salt
asked Mar 8 at 8:15
Chaï SarfatiChaï Sarfati
112
add a comment |
Salt is used when storing passwords in databases in order to protect against dictionary attacks and rainbow tables.
However, let's assume we need to store unique and random (sensitive) information about users. Is there still an advantage in salting this information before hashing it ?
Wouldn't salt use, in this case, just add randomness to an already random data (unlike man-typed passwords) ?
security hash salt
asked Mar 8 at 8:15
Chaï SarfatiChaï Sarfati
112
what do you mean by unique and random ? Salt is just placed to prevent decryption. That's all it is. If you must protect that unique and random information, use salt. If you don't, then leave it be.
– Kianii
Mar 8 at 10:50
Could you elaborate theunique and random?
– kelalaka
Mar 8 at 11:14
@Kianii hash don't encrypt, they hash. What the dictionary attack and rainbow is actually tries to find pre-image or secondary image the hash function which are hard to invert.
– kelalaka
Mar 8 at 11:16
@kelalaka What about deterministic encryption ?
– Kianii
Mar 8 at 13:08
random : no pattern can be identified, unique: for every r1 in the database, there exist no r2 such that r1 = r2
– Chaï Sarfati
Mar 9 at 17:18
add a comment |
Salt is used when storing passwords in databases in order to protect against dictionary attacks and rainbow tables.
However, let's assume we need to store unique and random (sensitive) information about users. Is there still an advantage in salting this information before hashing it ?
Wouldn't salt use, in this case, just add randomness to an already random data (unlike man-typed passwords) ?
security hash salt
asked Mar 8 at 8:15
Chaï SarfatiChaï Sarfati
112
Salt is used when storing passwords in databases in order to protect against dictionary attacks and rainbow tables.
However, let's assume we need to store unique and random (sensitive) information about users. Is there still an advantage in salting this information before hashing it ?
Wouldn't salt use, in this case, just add randomness to an already random data (unlike man-typed passwords) ?
security hash salt
security hash salt
asked Mar 8 at 8:15
Chaï SarfatiChaï Sarfati
112
asked Mar 8 at 8:15
Chaï SarfatiChaï Sarfati
112
asked Mar 8 at 8:15
Chaï SarfatiChaï Sarfati
112
asked Mar 8 at 8:15
Chaï SarfatiChaï Sarfati
112
asked Mar 8 at 8:15
Chaï SarfatiChaï Sarfati
112
112
what do you mean by unique and random ? Salt is just placed to prevent decryption. That's all it is. If you must protect that unique and random information, use salt. If you don't, then leave it be.
– Kianii
Mar 8 at 10:50
Could you elaborate theunique and random?
– kelalaka
Mar 8 at 11:14
@Kianii hash don't encrypt, they hash. What the dictionary attack and rainbow is actually tries to find pre-image or secondary image the hash function which are hard to invert.
– kelalaka
Mar 8 at 11:16
@kelalaka What about deterministic encryption ?
– Kianii
Mar 8 at 13:08
random : no pattern can be identified, unique: for every r1 in the database, there exist no r2 such that r1 = r2
– Chaï Sarfati
Mar 9 at 17:18
add a comment |
what do you mean by unique and random ? Salt is just placed to prevent decryption. That's all it is. If you must protect that unique and random information, use salt. If you don't, then leave it be.
– Kianii
Mar 8 at 10:50
Could you elaborate theunique and random?
– kelalaka
Mar 8 at 11:14
@Kianii hash don't encrypt, they hash. What the dictionary attack and rainbow is actually tries to find pre-image or secondary image the hash function which are hard to invert.
– kelalaka
Mar 8 at 11:16
@kelalaka What about deterministic encryption ?
– Kianii
Mar 8 at 13:08
random : no pattern can be identified, unique: for every r1 in the database, there exist no r2 such that r1 = r2
– Chaï Sarfati
Mar 9 at 17:18
what do you mean by unique and random ? Salt is just placed to prevent decryption. That's all it is. If you must protect that unique and random information, use salt. If you don't, then leave it be.
– Kianii
Mar 8 at 10:50
what do you mean by unique and random ? Salt is just placed to prevent decryption. That's all it is. If you must protect that unique and random information, use salt. If you don't, then leave it be.
– Kianii
Mar 8 at 10:50
Could you elaborate the
unique and random?– kelalaka
Mar 8 at 11:14
Could you elaborate the
unique and random?– kelalaka
Mar 8 at 11:14
@Kianii hash don't encrypt, they hash. What the dictionary attack and rainbow is actually tries to find pre-image or secondary image the hash function which are hard to invert.
– kelalaka
Mar 8 at 11:16
@Kianii hash don't encrypt, they hash. What the dictionary attack and rainbow is actually tries to find pre-image or secondary image the hash function which are hard to invert.
– kelalaka
Mar 8 at 11:16
@kelalaka What about deterministic encryption ?
– Kianii
Mar 8 at 13:08
@kelalaka What about deterministic encryption ?
– Kianii
Mar 8 at 13:08
random : no pattern can be identified, unique: for every r1 in the database, there exist no r2 such that r1 = r2
– Chaï Sarfati
Mar 9 at 17:18
random : no pattern can be identified, unique: for every r1 in the database, there exist no r2 such that r1 = r2
– Chaï Sarfati
Mar 9 at 17:18
add a comment |
2 Answers
2
active
oldest
votes
It depends on how confidential your information is and what are the consequences when this data is compromised. Is it a PII information like SSN or DOB?
You mentioned that your data is random and unique. Which means it is difficult to identify a pattern. If the pattern is random enough then Salting your data may not be required. if you go with salting, then you will have an added responsibility of protecting those salts as well.
I would recommend to use low privileged account, hardening of server, authentication, authorization to protect your data and minimize the surface of attack.
Again, you should come to the conclusion after classification of your data based on CIA principles.
answered Mar 8 at 13:10
Rasik JainRasik Jain
80159
1
If the size of the random and unique data is small then easy to find. The bitcoin miners reached ~2^90 hash in year.
– kelalaka
Mar 8 at 13:12
Agree with your comment, This was my generic response without knowing the specifics of data from the post. Based on data classification(High, Med, Low) and then we should come to decision wether to salt it or not. Otherwise, we can use other measures to protect the data.
– Rasik Jain
Mar 8 at 13:17
1
"then you will have an added responsibility of protecting those salts as well" What do you mean by this? A salt, but definition, is not sensitive information. If you have to protect the salt, then it's not a salt, it's a pepper and the handling of peppers is very different than the handling of salts (and also much weaker than salts).
– Rob Napier
Mar 8 at 14:57
add a comment |
This depends very heavily on the size of the search space. For example, we could pretend that social security numbers are both random and unique (they're not actually either, but for the purpose of this discussion we will pretend they are). If you're hashing SSNs, not only do you need a salt, but a salt isn't sufficient. Why? Because there are fewer than 10 billion SSNs in existence. Creating a rainbow table for those is trivial. Even with a salt, it isn't that hard to brute force, even if the values are unique and random.
So to protect a random and unique value that lives in a small search space we have to use a stretching algorithm like PBKDF2, not just a hash. The point of a stretching algorithm is to make computing the hash very slow.
Stretching algorithms always include a salt. But it doesn't have to be a random salt. It could be deterministic (some database identifier + the user id for example, "com.example.mygreatapp:alice"). But for a small search space, you still need it to be unique per user because there are so few items in the search space.
On the other hand, if your random and unique data represents a large search space (not less than 2^64, and ideally at least 2^80), and that search space is sparse (you only use a very small fraction of legal elements), then salting and stretching is likely not required.
answered Mar 8 at 15:16
Rob NapierRob Napier
205k28303431
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55059145%2fshould-we-salt-informations-that-are-unique-and-random%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
It depends on how confidential your information is and what are the consequences when this data is compromised. Is it a PII information like SSN or DOB?
You mentioned that your data is random and unique. Which means it is difficult to identify a pattern. If the pattern is random enough then Salting your data may not be required. if you go with salting, then you will have an added responsibility of protecting those salts as well.
I would recommend to use low privileged account, hardening of server, authentication, authorization to protect your data and minimize the surface of attack.
Again, you should come to the conclusion after classification of your data based on CIA principles.
answered Mar 8 at 13:10
Rasik JainRasik Jain
80159
1
If the size of the random and unique data is small then easy to find. The bitcoin miners reached ~2^90 hash in year.
– kelalaka
Mar 8 at 13:12
Agree with your comment, This was my generic response without knowing the specifics of data from the post. Based on data classification(High, Med, Low) and then we should come to decision wether to salt it or not. Otherwise, we can use other measures to protect the data.
– Rasik Jain
Mar 8 at 13:17
1
"then you will have an added responsibility of protecting those salts as well" What do you mean by this? A salt, but definition, is not sensitive information. If you have to protect the salt, then it's not a salt, it's a pepper and the handling of peppers is very different than the handling of salts (and also much weaker than salts).
– Rob Napier
Mar 8 at 14:57
add a comment |
It depends on how confidential your information is and what are the consequences when this data is compromised. Is it a PII information like SSN or DOB?
You mentioned that your data is random and unique. Which means it is difficult to identify a pattern. If the pattern is random enough then Salting your data may not be required. if you go with salting, then you will have an added responsibility of protecting those salts as well.
I would recommend to use low privileged account, hardening of server, authentication, authorization to protect your data and minimize the surface of attack.
Again, you should come to the conclusion after classification of your data based on CIA principles.
answered Mar 8 at 13:10
Rasik JainRasik Jain
80159
1
If the size of the random and unique data is small then easy to find. The bitcoin miners reached ~2^90 hash in year.
– kelalaka
Mar 8 at 13:12
Agree with your comment, This was my generic response without knowing the specifics of data from the post. Based on data classification(High, Med, Low) and then we should come to decision wether to salt it or not. Otherwise, we can use other measures to protect the data.
– Rasik Jain
Mar 8 at 13:17
1
"then you will have an added responsibility of protecting those salts as well" What do you mean by this? A salt, but definition, is not sensitive information. If you have to protect the salt, then it's not a salt, it's a pepper and the handling of peppers is very different than the handling of salts (and also much weaker than salts).
– Rob Napier
Mar 8 at 14:57
add a comment |
It depends on how confidential your information is and what are the consequences when this data is compromised. Is it a PII information like SSN or DOB?
You mentioned that your data is random and unique. Which means it is difficult to identify a pattern. If the pattern is random enough then Salting your data may not be required. if you go with salting, then you will have an added responsibility of protecting those salts as well.
I would recommend to use low privileged account, hardening of server, authentication, authorization to protect your data and minimize the surface of attack.
Again, you should come to the conclusion after classification of your data based on CIA principles.
answered Mar 8 at 13:10
Rasik JainRasik Jain
80159
It depends on how confidential your information is and what are the consequences when this data is compromised. Is it a PII information like SSN or DOB?
You mentioned that your data is random and unique. Which means it is difficult to identify a pattern. If the pattern is random enough then Salting your data may not be required. if you go with salting, then you will have an added responsibility of protecting those salts as well.
I would recommend to use low privileged account, hardening of server, authentication, authorization to protect your data and minimize the surface of attack.
Again, you should come to the conclusion after classification of your data based on CIA principles.
answered Mar 8 at 13:10
Rasik JainRasik Jain
80159
answered Mar 8 at 13:10
Rasik JainRasik Jain
80159
answered Mar 8 at 13:10
Rasik JainRasik Jain
80159
answered Mar 8 at 13:10
Rasik JainRasik Jain
80159
80159
1
If the size of the random and unique data is small then easy to find. The bitcoin miners reached ~2^90 hash in year.
– kelalaka
Mar 8 at 13:12
Agree with your comment, This was my generic response without knowing the specifics of data from the post. Based on data classification(High, Med, Low) and then we should come to decision wether to salt it or not. Otherwise, we can use other measures to protect the data.
– Rasik Jain
Mar 8 at 13:17
1
"then you will have an added responsibility of protecting those salts as well" What do you mean by this? A salt, but definition, is not sensitive information. If you have to protect the salt, then it's not a salt, it's a pepper and the handling of peppers is very different than the handling of salts (and also much weaker than salts).
– Rob Napier
Mar 8 at 14:57
add a comment |
1
If the size of the random and unique data is small then easy to find. The bitcoin miners reached ~2^90 hash in year.
– kelalaka
Mar 8 at 13:12
Agree with your comment, This was my generic response without knowing the specifics of data from the post. Based on data classification(High, Med, Low) and then we should come to decision wether to salt it or not. Otherwise, we can use other measures to protect the data.
– Rasik Jain
Mar 8 at 13:17
1
"then you will have an added responsibility of protecting those salts as well" What do you mean by this? A salt, but definition, is not sensitive information. If you have to protect the salt, then it's not a salt, it's a pepper and the handling of peppers is very different than the handling of salts (and also much weaker than salts).
– Rob Napier
Mar 8 at 14:57
1
1
If the size of the random and unique data is small then easy to find. The bitcoin miners reached ~2^90 hash in year.
– kelalaka
Mar 8 at 13:12
If the size of the random and unique data is small then easy to find. The bitcoin miners reached ~2^90 hash in year.
– kelalaka
Mar 8 at 13:12
Agree with your comment, This was my generic response without knowing the specifics of data from the post. Based on data classification(High, Med, Low) and then we should come to decision wether to salt it or not. Otherwise, we can use other measures to protect the data.
– Rasik Jain
Mar 8 at 13:17
Agree with your comment, This was my generic response without knowing the specifics of data from the post. Based on data classification(High, Med, Low) and then we should come to decision wether to salt it or not. Otherwise, we can use other measures to protect the data.
– Rasik Jain
Mar 8 at 13:17
1
1
"then you will have an added responsibility of protecting those salts as well" What do you mean by this? A salt, but definition, is not sensitive information. If you have to protect the salt, then it's not a salt, it's a pepper and the handling of peppers is very different than the handling of salts (and also much weaker than salts).
– Rob Napier
Mar 8 at 14:57
"then you will have an added responsibility of protecting those salts as well" What do you mean by this? A salt, but definition, is not sensitive information. If you have to protect the salt, then it's not a salt, it's a pepper and the handling of peppers is very different than the handling of salts (and also much weaker than salts).
– Rob Napier
Mar 8 at 14:57
add a comment |
This depends very heavily on the size of the search space. For example, we could pretend that social security numbers are both random and unique (they're not actually either, but for the purpose of this discussion we will pretend they are). If you're hashing SSNs, not only do you need a salt, but a salt isn't sufficient. Why? Because there are fewer than 10 billion SSNs in existence. Creating a rainbow table for those is trivial. Even with a salt, it isn't that hard to brute force, even if the values are unique and random.
So to protect a random and unique value that lives in a small search space we have to use a stretching algorithm like PBKDF2, not just a hash. The point of a stretching algorithm is to make computing the hash very slow.
Stretching algorithms always include a salt. But it doesn't have to be a random salt. It could be deterministic (some database identifier + the user id for example, "com.example.mygreatapp:alice"). But for a small search space, you still need it to be unique per user because there are so few items in the search space.
On the other hand, if your random and unique data represents a large search space (not less than 2^64, and ideally at least 2^80), and that search space is sparse (you only use a very small fraction of legal elements), then salting and stretching is likely not required.
answered Mar 8 at 15:16
Rob NapierRob Napier
205k28303431
add a comment |
This depends very heavily on the size of the search space. For example, we could pretend that social security numbers are both random and unique (they're not actually either, but for the purpose of this discussion we will pretend they are). If you're hashing SSNs, not only do you need a salt, but a salt isn't sufficient. Why? Because there are fewer than 10 billion SSNs in existence. Creating a rainbow table for those is trivial. Even with a salt, it isn't that hard to brute force, even if the values are unique and random.
So to protect a random and unique value that lives in a small search space we have to use a stretching algorithm like PBKDF2, not just a hash. The point of a stretching algorithm is to make computing the hash very slow.
Stretching algorithms always include a salt. But it doesn't have to be a random salt. It could be deterministic (some database identifier + the user id for example, "com.example.mygreatapp:alice"). But for a small search space, you still need it to be unique per user because there are so few items in the search space.
On the other hand, if your random and unique data represents a large search space (not less than 2^64, and ideally at least 2^80), and that search space is sparse (you only use a very small fraction of legal elements), then salting and stretching is likely not required.
answered Mar 8 at 15:16
Rob NapierRob Napier
205k28303431
add a comment |
This depends very heavily on the size of the search space. For example, we could pretend that social security numbers are both random and unique (they're not actually either, but for the purpose of this discussion we will pretend they are). If you're hashing SSNs, not only do you need a salt, but a salt isn't sufficient. Why? Because there are fewer than 10 billion SSNs in existence. Creating a rainbow table for those is trivial. Even with a salt, it isn't that hard to brute force, even if the values are unique and random.
So to protect a random and unique value that lives in a small search space we have to use a stretching algorithm like PBKDF2, not just a hash. The point of a stretching algorithm is to make computing the hash very slow.
Stretching algorithms always include a salt. But it doesn't have to be a random salt. It could be deterministic (some database identifier + the user id for example, "com.example.mygreatapp:alice"). But for a small search space, you still need it to be unique per user because there are so few items in the search space.
On the other hand, if your random and unique data represents a large search space (not less than 2^64, and ideally at least 2^80), and that search space is sparse (you only use a very small fraction of legal elements), then salting and stretching is likely not required.
answered Mar 8 at 15:16
Rob NapierRob Napier
205k28303431
This depends very heavily on the size of the search space. For example, we could pretend that social security numbers are both random and unique (they're not actually either, but for the purpose of this discussion we will pretend they are). If you're hashing SSNs, not only do you need a salt, but a salt isn't sufficient. Why? Because there are fewer than 10 billion SSNs in existence. Creating a rainbow table for those is trivial. Even with a salt, it isn't that hard to brute force, even if the values are unique and random.
So to protect a random and unique value that lives in a small search space we have to use a stretching algorithm like PBKDF2, not just a hash. The point of a stretching algorithm is to make computing the hash very slow.
Stretching algorithms always include a salt. But it doesn't have to be a random salt. It could be deterministic (some database identifier + the user id for example, "com.example.mygreatapp:alice"). But for a small search space, you still need it to be unique per user because there are so few items in the search space.
On the other hand, if your random and unique data represents a large search space (not less than 2^64, and ideally at least 2^80), and that search space is sparse (you only use a very small fraction of legal elements), then salting and stretching is likely not required.
answered Mar 8 at 15:16
Rob NapierRob Napier
205k28303431
answered Mar 8 at 15:16
Rob NapierRob Napier
205k28303431
answered Mar 8 at 15:16
Rob NapierRob Napier
205k28303431
answered Mar 8 at 15:16
Rob NapierRob Napier
205k28303431
205k28303431
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55059145%2fshould-we-salt-informations-that-are-unique-and-random%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
what do you mean by unique and random ? Salt is just placed to prevent decryption. That's all it is. If you must protect that unique and random information, use salt. If you don't, then leave it be.
– Kianii
Mar 8 at 10:50
Could you elaborate the
unique and random?– kelalaka
Mar 8 at 11:14
@Kianii hash don't encrypt, they hash. What the dictionary attack and rainbow is actually tries to find pre-image or secondary image the hash function which are hard to invert.
– kelalaka
Mar 8 at 11:16
@kelalaka What about deterministic encryption ?
– Kianii
Mar 8 at 13:08
random : no pattern can be identified, unique: for every r1 in the database, there exist no r2 such that r1 = r2
– Chaï Sarfati
Mar 9 at 17:18