New answers tagged

0

The 72-character limit is caused by Blowfish cipher, which is used internally for Bcrypt. You can limit the length of the password in your application, truncate it, or (may not be the brightest idea) hash it and pass the output of the hash function to Bcrypt. Either way, it is not possible to beat the Bcrypt cipher's internal limit.


3

When an attacker knows only the hash and not the salt, then they have to not just test every possible password but every possible password with every possible salt. With long and random salt values this is practically impossible. However, this is not a realistic scenario. When an attacker compromises a system, you have to assume that they compromised the ...


5

I think you've misunderstood the purpose of a salt, because if you understood what it is designed to achieve you perhaps wouldn't be asking this question. The only purpose is to provide a level of uniqueness to each password in order to prevent precomputed tables ("rainbow tables") being an effective form of attack. As a result, it's not designed to be "...


2

A salt is a stored next to the password. There is no rule that says it MUST be like that, but it is a logical result of the intended purpose of a salt. Building a rainbow table is no trivial task. The point of the salt is that the attacker would need a separate rainbow table for each salted password (in which case it is easier to directly attack each ...


1

The short answer is NO. NEVER EVER MAKE YOUR OWN HASHING ALGORITHM! Home cooking algorithms for hashing are never ever secure and therefore a very bad idea. It's also a bad idea to mix two algorithms together as it can make things even more insecure. There are many other algorithms out there that you could use. You can use Bcrypt, Scrypt, sha2, sha512 , ...


5

If you're using a constant salt, then it's not bcrypt: An important requirement of any bcrypt implementation is that it exploit the full 128-bit salt space. — A Future-Adaptable Password Scheme Because bcrypt generates a different salt every time, the hash is always different meaning I can no longer use the generated hash to identify the user's ...


5

Disclaimar: Please note that this answer was written before more details were added to the question. Some points therefore no longer applies, while others still do. Problems with your approach [...] of the password they used to encrypt the data. Are you using passwords as encryption keys? That is not a good idea, since passwords picked by users have ...


2

You shouldn't use either! Using a constant salt defeats the purpose of using bcrypt. Use a variable salt! Just like SHA1, it's easily cracked. It's like asking - what's more secure, a wooden box or a thermite-proof triple-reinforced steel box with a wooden door? Excellent explanation by Tom Scott. IMHO your code is probably vulnerable to SQL injection ...



Top 50 recent answers are included