Using PBKDF2 twice with different argument order

I'm pretty sure this is a really bad approach (in theory), but one of my clients is doing this and I was wondering… How bad it is to perform in this way (with 2000 iterations)?

a = PBKDF2(x, y)
b = PBKDF2(y, x)

y is the password (salt in pbkdf2)
2000 iterations


a is then used for some authentication in the system and "b" is used for encryption.
a and x are also stored and therefore known.

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?

EDIT 1:

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.

EDIT 2:

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

-
At best, you're in a situation where you're using the algorithm in a way which hasn't been nearly as thoroughly cryptanalyzed. Better would be to use two separate cryptographically random salts, one for each usage purpose. –  Stephen Touset Jun 17 '14 at 22:26
Alternatively, use the password and salt as intended, and ask PBKDF2 to generate a bytestring that is long as the authentication and encryption keys concatenated. –  poncho Jun 17 '14 at 22:28
Also depends on the implementation. For example, if it takes password as a null-terminated string but salt as a byte array, random nulls in salt could lead to truncation. (Google turned up some implementations that do that.) –  otus Jun 18 '14 at 6:19
@StephenTouset and Poncho: bad ideas, both require the PBKDF2 to be used for separate number of iterations. This means an attacker has to do less rounds than the user of PBKDF2. Better to use a KBKDF (such as HKDF) on the output of PBKDF2, once for the encryption key and one for the auth key. –  Maarten Bodewes Jun 18 '14 at 22:51
XCore: if a and b are keys, then what do you mean with "a and b are also stored"? –  Maarten Bodewes Jun 18 '14 at 22:52

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.

-

If the password ever collides with salt (for some reason), then $a=b$, which can be quite disastrous.

Such event may be, for example, caused by a bug in the software implementation, which could reuse password as salt (or vice versa) if the latter input is not generated properly or is missing. Another example would be predicable salt; then an adversary could choose password equal to the future salt and cause $a=b$.

If this happens, whoever eavesdrops the authentication procedure can encrypt/decrypt (and vice versa). Without further details it is hard to estimate the consequences, but for safety I'd recommend using something like $$a = PBKDF2(0,x,y);\\ b = PBKDF2(1,y,x).$$ which is very close to the original but does not have the weakness.

-
Can it? By what property? –  Stephen Touset Jun 18 '14 at 0:31
poor password restriction policy and poor salt generation? –  Richie Frame Jun 18 '14 at 9:49
I would appreciate it if you could add a little heads-up (a short example or something alike) that shows under what conditions such a collision might happen, and how that introduces the disastrous impact you’re hinting at. Could you elaborate a bit on that? Thanks… –  e-sushi Jun 19 '14 at 15:43
You appear to have edited the response, but still only assert that $a = b$ is disastrous. How can an adversary subversively choosing their own password lead to the compromise of other parties' keys, as you claim? –  Stephen Touset Jun 25 '14 at 16:20