Tag Info

New answers tagged

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. ...


1

User names are predictable. I would prefer using random value as a salt. An attacker could begin the generation of precumputed hash table targeting one user (admin?) even before obtaining the hash&salt to crack. So, you should NOT. Edit: The main purpose of having a salt is that rainbow tables are useless. From my point of view, using a guessable ...


0

The real danger is not structured guessing I think. Guessing takes to long for 30+ passwords or passphrases on average. But on average also implies they might have some luck on day 1, and you don't want your password to be the lucky one. The real danger are existing lists with millions of known passwords. Hashing them one by one and comparing the hash with ...


1

No, a 30+ random character password is safe If your password is 30+ random characters, the number of possible passwords is well beyond 95^30, which is 2.14e59. The Oclhashcrack page gives a sample crack rate for SHA256 of 16,904 Mh/s. So lets assume the "budget equal to the world GDP" would allow for a million of these computers to perform the cracking. ...


6

A salt does not make brute-forcing a single password any harder, as you correctly pointed out. Without a salt, an attacker could build one single rainbow-table, and (s)he would get all passwords at once. With a salt, the attacker has to build a rainbow-table for exactly this salt, so he cannot reuse already existing rainbow-tables. When you use a different ...


9

Salt doesn't have to be secret. However, it MUST be unique for each password. Consider this : if all your passwords are hashed with the same salt, then an attacker who gets access to your database "only" has to compute H(pwd+salt) for each possible pwd value and he gets all your passwords. If the salt is unique however, the same operation will only get him ...


2

You're right. Salting really makes password hacking more difficult for non-trivial passwords, but if some users use common passwords, can still hack the password by brute force a few thousands times. If the salt is public/stored together, like your case, it is just used to prevent pre-computed password hashes lookup, i.e. rainbow table. Thus, if for ...


0

It makes a dictionary attack a lot more difficult, if the salt is created in a smart way. For example, bcrypt uses a 128 bit salt. A salt is usually generated randomly. If it was derived only from the password or the password hash, it would indeed not add much security. If it is generated in a way that cannot be predicted by the attacker, it significantly ...


4

Hashing the password with a salt makes it much harder for an attacker to use a precomputed list of hashes (aka rainbow tables) to run the discovered hash against. It will force him to compute the hashes again for any salted password hash he wants to crack.



Top 50 recent answers are included