Using PBKDF2 twice with different argument order

Question

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 pbkdf-2 in this way (with 2000 iterations)?

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

x is the username (password in pbkdf2)
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?

Answer 1

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.

Answer 2

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.