Has scrypt been broken, finally?

The short answer is : no. That is not what I said, nor what I implied.

Using the tradeoff that I identified and talked about, you can trade memory for CPU time. So yes, you can reduce a particular derivation from 16MiB to 8KiB (approximately). However doing so will require several orders of magnitude more logic to be executed by the CPU. Some efficiency is gained by cache locality, but in general, it should be much slower. (on average, about 8,000 times slower than the 16MiB version, but as much as 16,000 times slower, depending on the exact random distributions of the algorithm).

There is a more interesting alternative though. My attack was an all-or-nothing bais. Basically, completely eliminate the V array, at the cost of increasing complexity. But you can make a more nuanced tradeoff. You can cut the array in half, and re-compute every-other value. Or cut it to every third value. Trading off storage space for CPU space. But at a varied degree. This is commonly referred to as a TMTO defeater (Time-Memory-TradeOff Defeater).

I did a more thorough analysis, including a proposed fix on this thread. It's worth noting that at least one of the proposals for the Password Hashing Competition uses my augmented algorithm.

So no, scrypt is still incredibly strong. And for its primary use case (as a KDF), it's quite a bit better than the alternatives.,

The point I was trying to make with my post, is that when not tuned optimally (used with improper settings) or with very fast settings, it can be significantly weaker than existing algorithms. Specifically for password storage. Where you know the result, and are looking for the source material (password).

Note that scrypt is vulnerable to Timing Attacks: Issue #18 · pbhogan/scrypt, which means that an attacker who has some access to the host you're hashing passwords on has some additional ways to figure the passwords out. So it isn't broken, but has disadvantages compared to e.g. bcrypt.