Tag Info

New answers tagged

0

You want to use bcrypt for storage on the server side: that's good. You have to remember why you do that: it is because you fear that the server's storage area may be plundered in some way, and you want an extra layer of protection. The point of bcrypt (or any other similar password hashing function) is to make dictionary attacks more expensive: there is a ...


0

What you're proposing is still unsafe: since the salt is always the same for a given account, an attacker who listen to the traffic can simply record the value returned by your client and reuse it afterward (this is call "passing the hash"). There are ways to help mitigate that issue but they all end up with the same problem in the end: you might secure the ...


4

UUID of type "v4" are supposed to be generated with 122 random bits: o Set all the other bits to randomly (or pseudo-randomly) chosen values. However, it is not said that the said bits must come from a cryptographically secure PRNG (section 4.5 recommends it but does not mandates it). IF the 122 bits indeed come from a secure PRNG, then they are ...


1

Assuming you mean an attacker has 100 copies of the same password hashed with 100 different salts, then no, that doesn't provide any advantage to them in findings the plaintext password. The benefit of using different salts means that cracking attempts aimed at any one of the hashes must be done independently of the computational work used for the others. ...


0

No, it would not help the attacker. Salts, are in fact, specifically designed to make it impossible for an attacker to know that two passwords are the same, as well as to make it computationally impossible for an attacker to precompute password hashes (see rainbow tables). It sounds like your hashing algorithm is up to the state-of-the-art by using bcrypt ...



Top 50 recent answers are included