Tag Info

New answers tagged

1

Salt is not really about entropy. What salts must achieve is uniqueness: as much as possible, you must try never to reuse a salt value (even if changing the password for the same user). GUID are nice for that. Randomness is a nice method to achieve that kind of uniqueness with overwhelming probability (it is "nice" because it does not need any kind of ...


4

Simply put, you want to maximize the amount of entropy for a given length of data, when doing most cryptographic tasks. You have (at most) 16 bytes of entropy in your GUID - probably less (some of the bits are deterministic), but we can ignore that detail for the current discussion. When using the GUID's byte[] representation as a salt, you have 16 bytes of ...


0

Here is the answer to related question which should resolve all of your confusion: How to securely hash passwords? EDIT: To question 1. As was said by other answerers, you can't prevent brute force by salting your passwords. Other techniques exists for this task, usually it's throttling of some kind and limiting number of attempts. Gradual throttling with ...


7

Simple version : Salts don't stop brute force attacks against a single user's password. What they stop is is you being able to do a brute force attack against all of the users' passwords at the same time.


21

From your initial understandings: A rainbow table is, for a given hash algorithm, an exhaustive map from hash outputs to inputs. Given that the table must cover the entire output range, and that a good hash algorithm makes it difficult to predict input from desired output, and expensive to compute the output, it should be very expensive to generate. As ...


0

Your first point is easily answer. There is nothing that prevents that. Salt are not a mean to avoid brute-force attacks anyway. Your second and third point are more relevant. Salts are here to avoid having one rainbow table to rule them all. That is to say, for each user, you have a different salt. This means that if you want to attack multiple users, you ...


2

Salt don't help against brute force attacks, as the attacker is firing all passwords known to men, he will eventually get lucky and guess it right. Salts become helpful when the stored passwords have been stolen, to find the password that belongs to the hash (I wouldn't use MD5) you can take a random password, hash it, and check it against the hash you ...


1

I think the way to go about this problem is to separate, as much as possible, authentication and confidentiality. The ideal way to do this would be to have two passwords, one for authentication and a completely independent one for confidentiality. The problem is, users are not ideal. Likely they would make the password the same or add some very predictable ...


0

If I store it in the server, it must be retrieved before authentication [...] It would be retrieved at the same time as authentication, like select salt, pw_hash from users where name = '@name' You would use both salt and pw_hash to validate the password that the user entered. You still might want to be careful about leaking information about ...


1

The required property of a salt is to be unique, cause it make impossible to use dictionary table for reverse hash of all user with the same table. The other usefull property is to be impredictable so attacker can't pre calculate dictionary table before obtening the salt.(scenario where this is usefull : the attacker detect a security problem he can use to ...


1

Initialization vectors aren't meant to be private. The goal of an IV isn't to strengthen the key but to make sure that no two identical (or similar) clear text will result in the same (or similar) cipher text. It works like this: AES (along with most - but not all - modern crypto algorithm) is a block cipher. It only operate on a fixed amount of data (in ...


1

Simply changing the representation of the message shouldn't reduce the entropy given the underlying meaning of the data shouldn't be altered. So for example, you could encode it into Base64 or ASCII without issue. However, to answer this question generally: How much can a function (such as the one below) modify an initially random string before that ...


1

No. Every hash would have to be recalculated, essentially reproducing the work that was needed to create the original rainbow table. Hashing is basically a mathematical formula. You have a formula (hashing algorithm) of X + 5 = Y, where X is the password and Y is the hash. You use a rainbow table to store all possible values of X with their Y results. ...



Top 50 recent answers are included