# Tag Info

0

If you store the encrypted digests in one location, the key in another, and send the new digest and encrypted one from the first location to the second --- you probably have much better chance to have your communications intercepted with both plaintext and ciphertext revealed compared to the chance that your encrypted database is leaked. If you still ...

0

Either is safe, but I would prefer encryption for two reasons: As noted in the comments, you can change the key without needing to know the original password. Encryption doesn't add to collisions, while HMAC can. The probability is tiny, but it adds to the probability that the password hash caused a collision. Not worth worrying about, but since it's ...

2

The question is well answered by ninefingers, but the question exposes fundamental confusion on the part of Mitchell. The NT Hash is not salted, and it IS PASSWORD EQUIVALENT. There is no need to use the hash to get the password, just use the hash to access the resource! Second, the password must be greater than 14 characters to avoid the LM hash, see MS ...

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

3

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

Top 50 recent answers are included