Return to Answer

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 they would be if you used PBKDF2 only once with twice the iterations, then used e.g. HKDF to quickly derive two keys.

Actually, if you use 128-bit keys and SHA-256 in PBKDF2, you can just split the output.

More specifically: a is used as key to retrieve user data from the DB (thus, a is sent to server), data is returned and partially encrypted. You need b to decrypt what you get.

If $a$ is sent in the clear, an eavesdropper can use it for a brute force or dictionary attack, which would also find $b$. 2000 iterations of PBKDF2 doesn't make a password invulnerable to such attacks, although it obviously helps.

Let's say that an attacker gets access to the database where these hashes are stored. What kind of attacks could he perpetrate?

Brute force and dictionary attacks, probably no easier than if only $b$ was known, but like I wrote above, twice as easy as if a better key derivation system was used.

Like the other answer mentions, if someone used their username as a password, that would be immediately visible as $a=b$, so no searching would be needed. However, that would be one of the first guesses in any case, so it probably isn't a big deal.

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 they would be if you used PBKDF2 only once with twice the iterations, then used e.g. HKDF to quickly derive two keys.

Actually, if you use 128-bit keys and SHA-256 in PBKDF2, you can just split the output.

More specifically: a is used as key to retrieve user data from the DB (thus, a is sent to server), data is returned and partially encrypted. You need b to decrypt what you get.

If $a$ is sent in the clear, an eavesdropper can use it for a brute force or dictionary attack, which would also find $b$. 2000 iterations of PBKDF2 doesn't make a password invulnerable to such attacks, although it obviously helps.

Let's say that an attacker gets access to the database where these hashes are stored. What kind of attacks could he perpetrate?

Brute force and dictionary attacks, probably no easier than if only $b$ was known, but like I wrote above, twice as easy as if a better key derivation system was used.

Like the other answer mentions, if someone used their username as a password, that would be immediately visible as $a=b$, so no searching would be needed. However, that would be one of the first guesses in any case, so it probably isn't a big deal.

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 they would be if you used PBKDF2 only once with twice the iterations, then used e.g. HKDF to quickly derive two keys.

Actually, if you use 128-bit keys and SHA-256 in PBKDF2, you can just split the output.

More specifically: a is used as key to retrieve user data from the DB (thus, a is sent to server), data is returned and partially encrypted. You need b to decrypt what you get.

If $a$ is sent in the clear, an eavesdropper can use it for a brute force or dictionary attack, which would also find $b$. 2000 iterations of PBKDF2 doesn't make a password invulnerable to such attacks, although it obviously helps.

Let's say that an attacker gets access to the database where these hashes are stored. What kind of attacks could he perpetrate?

Brute force and dictionary attacks, probably no easier than if only $b$ was known, but like I wrote above, twice as easy as if a better key derivation system was used.

Like the other answer mentions, if someone used their username as a password, that would be immediately visible as $a=b$, so no searching would be needed. However, that would be one of the first guesses in any case, so it probably isn't a big deal.

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 they would be if you used PBKDF2 only once with twice the iterations, then used e.g. HKDF to quickly derive two keys.

Actually, if you use 128-bit keys and SHA-256 in PBKDF2, you can just split the output.

More specifically: a is used as key to retrieve user data from the DB (thus, a is sent to server), data is returned and partially encrypted. You need b to decrypt what you get.

If $a$ is sent in the clear, an eavesdropper can use it for a brute force or dictionary attack, which would also find $b$. 2000 iterations of PBKDF2 doesn't make a password invulnerable to such attacks, although it obviously helps.

Let's say that an attacker gets access to the database where these hashes are stored. What kind of attacks could he perpetrate?

Brute force and dictionary attacks, probably no easier than if only $b$ was known, but like I wrote above, twice as easy as if a better key derivation system was used.

Like the other answer mentions, if someone used their username as a password, that would be immediately visible as $a=b$, so no searching would be needed. However, that would be one of the first guesses in any case, so it probably isn't a big deal.

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 they would be if you used PBKDF2 only once with twice the iterations, then used e.g. HKDF to quickly derive two keys.

More specifically: a is used as key to retrieve user data from the DB (thus, a is sent to server), data is returned and partially encrypted. You need b to decrypt what you get.

If $a$ is sent in the clear, an eavesdropper can use it for a brute force or dictionary attack, which would also find $b$. 2000 iterations of PBKDF2 doesn't make a password invulnerable to such attacks, although it obviously helps.

Let's say that an attacker gets access to the database where these hashes are stored. What kind of attacks could he perpetrate?

Brute force and dictionary attacks, probably no easier than if only $b$ was known, but like I wrote above, twice as easy as if a better key derivation system was used.

Like the other answer mentions, if someone used their username as a password, that would be immediately visible as $a=b$, so no searching would be needed. However, that would be one of the first guesses in any case, so it probably isn't a big deal.

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 they would be if you used PBKDF2 only once with twice the iterations, then used e.g. HKDF to quickly derive two keys.

Actually, if you use 128-bit keys and SHA-256 in PBKDF2, you can just split the output.

More specifically: a is used as key to retrieve user data from the DB (thus, a is sent to server), data is returned and partially encrypted. You need b to decrypt what you get.

If $a$ is sent in the clear, an eavesdropper can use it for a brute force or dictionary attack, which would also find $b$. 2000 iterations of PBKDF2 doesn't make a password invulnerable to such attacks, although it obviously helps.

Let's say that an attacker gets access to the database where these hashes are stored. What kind of attacks could he perpetrate?

Brute force and dictionary attacks, probably no easier than if only $b$ was known, but like I wrote above, twice as easy as if a better key derivation system was used.

Like the other answer mentions, if someone used their username as a password, that would be immediately visible as $a=b$, so no searching would be needed. However, that would be one of the first guesses in any case, so it probably isn't a big deal.