# Tag Info

1

Is there a vastly simpler way? I think so. Let the server send a reset token in the following form: (deadline, HMAC(server key, id_user || S || deadline)) That is, the server calculates an authenticator that allows id_user to change their secret from S before deadline. The key used should be only known by the server and can be changed often, since ...

0

$\;\;\;$ Probably as long as you compare securely, although you're applying $\;\;\;$ a pbkdf to what should be a uniformly random long secret key. $\;\;\;$ Don't bother computing S'; let S be a uniformly random secret key and use it instead. $\;\;\;$ To construct a reset token for a user U, set h = HMAC(S, 0 || (id,U,e) ), $\;\;\;$ set H = HMAC(S,1||h), ...

6

PBKDF2 (as defined by RFC 2898) is a function of the form $$DK = \text{PBKDF2}(\text{PRF}, Password, Salt, c, dkLen)$$ In most practical use cases, the $\text{PRF}$ is $\text{HMAC}$ instantiated with a Merkle-Damgård hash function such as $\text{SHA-1}$. The time to compute $\text{PBKDF2}$ is roughly linear with the iteration parameter $c$, all other ...

5

Firstly, How much time will it take to crack PBKDF2 while using a 9 character password? and how do I calculate the cost? I'm not specifying any specific system or platform. If a brute force attack is made using the best ever super computer around how much time will it take to crack it? Unless the underlying PRF is broken, brute force and dictionary ...

1

The multiplier parameter $k$ is different between SRP 6 and 6a. You can see that RFC 5054 calculates it using a hash of the domain parameters (modulus $N$ and generator $g$), so it is using SRP 6a, as opposed to SRP 6 where $k$ is constant. Likewise, in section 6.2.1 of IEC 11770-4 – the October 2005 draft at least – the equivalent value $c$ is defined as a ...

1

By that statement, does that mean adding a random character to a random position in a Diceware word adds 10 bits to each word? No. The ten bit estimate is for adding a random symbol from the 36-item table to a random position in the passphrase. The entropy in the character choice is about five bits and the entropy in the choice of position is another ...

5

If you add a truly random character into a truly random position of a word (uniformly chosen), you get "entropy of position" + "entropy of character" as addition to the entropy of the word. (Not exactly, it's a bit less). The entropy of character is the size of the possible characters. 64 possible characters would be $log2(64) = 6$ bits of entropy. Entropy ...

3

I'm pretty sure that they store only the hash. They can detect that you didn't change enough characters in the following way: When you provide a new password, the system generates several passwords that similar to the new password, by changing some characters. Then it calculates the hash of each similar password and compares it to the last stored hash (or ...

2

When using PBKDF2, is there a practical upper limit to the iteration count above which we lose security? No. There is a limit above which you gain no security, but it isn't practical. It's on the order of $2^{128}$ iterations for PBKDF2-HMAC-SHA-2, or $2^{80}$ if you use SHA-1 as the HMAC hash. For an explanation, see the questions mikeazo linked in ...

8

When only using one-way hashing, is it possible to tell the number of characters changed between the old and new password? No. If the hash function is strong, even a single bit change will give a completely different hash. The only way to tell how many characters differ between a particular unknown hash value and a known password would be an exhaustive ...

0

Do databases store the hash of the password or not? Yes, they do. And if they do so, can the thing I wrote above happen? Perhaps it could, but it's unlikely. It is usually easier to find the original password rather than a collision. With a strong hash function, it is difficult to find another string with the same hash as the string 'hello', but ...

2

Best practice is to use a slow hashing function like PBKDF2 or Scrypt as brute-forcing the hash of a typical password is trivial. The resulting hash is stored in the database. When a user logs in, their password is fed through the aforementioned function and the output compared with the hash stored in the database. Assuming a salt is used, the work factor ...

3

Databases generally store hashed passwords (as they should), but some store it plaintext (just remember this!). If someone were to find a hash collision that matched the stored, unsalted, and hashed password, then yes, they would be able to use that collision to login, because the client would send the password to the server, the server would calculate the ...

2

Is it subject to some class of attacks or is it just a really bad crypto nightmare which is only subject to brute-force attacks? You are calculating PBKDF2 twice, which takes twice as long. An attacker doing a brute force or dictionary attack only needs to calculate one of them to verify his guesses. That means you are making attacks twice as easy as ...

Top 50 recent answers are included