does my co-worker code is actually really necessary, for the sake of arguments lets ignore server performance, and focus on this snippet.

added comment on the side of the parameters

No idea.
It probably wraps an underlaying native lib for efficency. So it just a crypto spec.

But if it does lots of 10k iterations pbkdf calls in JS code.... then consider nukeing it.

Hashing hashes and adding them together would not probably add much security. He could have just rehashed the salted password hash several times instead

I don't get the reason of doing three calls to PBKDF2 and the different password pre-hashings.

Still, it does not look slower than just doing the OWASP recommended 120 000 rounds (https://cheatsheetseries.owasp.org/...) - and login attempts are rate limited, aren't they?

The only issue i can see is generating 3 different salts if a salt is not given. Which may/will be problematic to verify on the hash

what @iiii said.

that's the standard way I've seen. just loop the hash a couple of times.

makes it essentially impossible (impractical) to use pre-computed hashes and slows down online cracking N fold

@Hazarth the key is to use salt at every iteration, afaik

@iiii I could be wrong or mixing apples and oranges here. but with bcrypt you just use one salt despite multiple iterations. The reason is that you'd need to keep each salt stored somewhere in plaintext anyway, otherwise you can't reproduce the hash-chain and verify the password. And I think it would be pointless anyway, as long as you use different salt for every user hash, your entire database is safe from being cracked easily...

I mean really, even if you use different salt at each iteration, would that really help with anything? if your database leaks, the salts are already plaintext probably (unless encrypted, but if you can decrypt one you have the all too) and it doesn't delay the cracking any further to use 3 salts for 3 iterations except for 1 salt for all 3 iterations.

like a standard bcrypt format I've seen in the wild is just the $alg$iters$salt$hashedResult format. single salted but 10 iters is already extremely slow to bruteforce

@Hazarth I did not mean different salt every time. Just adding the same upon each iteration.

@iiii ah yes, then I just misunderstood what you meant. I think you're correct then. Sorry!

@Hazarth bcrypt uses 2^"cost" rounds (https://usenix.org/legacy/events/...)

@iiii PBKDF1 only does hash(hash(... hash(password | salt))). The problem with this construct is not the use of the salt, but rather the use of the password. Ignoring a potential length extension attack, the flaw is the repeated hash of only hashes - for some reasons hashes converge in a certain direction if just simply repeated (https://stackoverflow.com/a/...). The salt still does its job to generate different hashes for the same password (the convergence is irrelevant here). Therefore PBKDF2 does (https://ietf.org/rfc/rfc2898.html/...) more or less PRF(password, PRF(password, ... PRF(password, salt))).

@sbiewald That stackoverflow link is a stellar explanation, thanks!