* If you use the underlying hash as a black-box, each HMAC invocation compresses 4 blocks. An optimized implementation will only require 2. Many implementations (e.g. the .NET one) don't include that optimization and thus suffer from a 2x slowdown compared to the attacker's implementation.
It xors together the outputs of different iteration numbers. This can interfere with the feed-forward of certain hash constructions. As far as I can tell this does not cause security issues, but it's still very dirty.
---
Personally I'd go so far as to say that it's worse than PBKDF1 with a sufficiently wide underlying hash.
* If you use the underlying hash as a black-box, each HMAC invocation compresses 4 blocks. An optimized implementation will only require 2. Many implementations (e.g. the .NET one) don't include that optimization and thus suffer from a 2x slowdown compared to the attacker's implementation.
* If you use HMAC naively, it'll hash the whole password on each iteration, opening a DoS attack. Django made this mistake (see http://arstechnica.com/security/2013/09/long-passwords-are-g... )
It abuses the underlying hash:
It xors together the outputs of different iteration numbers. This can interfere with the feed-forward of certain hash constructions. As far as I can tell this does not cause security issues, but it's still very dirty.
---
Personally I'd go so far as to say that it's worse than PBKDF1 with a sufficiently wide underlying hash.