SHA2 just got even faster, so it illustrates rather well that you wouldn't want to use it for password storage -- of course that was always true, but the improvement drives that point home.
Even if the ARM processor on a cycle-by-cycle basis keeps up with already-existing GPU SHA2 crackers (which I do not know), it will not keep up with the parallelism in the GPUs, which is easy for anybody to get through hashcat: https://hashcat.net/wiki/
SHA2 has not gotten faster. It was already blisteringly, unbelievably fast.
If you're using any hash directly for password storage you're doing it wrong, regardless of the specifics.
PBKDF2-SHA2 with a reasonably high amount of rounds (>100000) is still okay-ish, although you should have transited to bcrypt years ago. And hopefully we'll see argon2 stabilizing and getting adoption soon™.
It's fine to use a SHA2 variant HMAC in PBKDF2 with an obscene, ever-increasing number of rounds, but the scrypt paper [1] provides a detailed justification why you may want to switch to a dedicated password hashing function regardless. To quote their website [2]:
"We estimate that on [circa-2009] hardware, if 5 seconds are spent computing a derived key, the cost of a hardware brute-force attack against scrypt is roughly 4000 times greater than the cost of a similar attack against bcrypt (to find the same password), and 20000 times greater than a similar attack against PBKDF2."
Specifically, PBKDF2 is a tool to produce mostly-okay password storage hash from crypto primitives that are totally unfit for it, while bcrypt, scrypt, Argon2 are purpose-designed to make certain kinds of attacks difficult, like time-memory tradeoffs, parallelized custom hardware attacks, etc.
Almost right. bcrypt is not designed to be secure against ASICs; it requires a fixed circuit size. In fact, given that CPU acceleration is available for SHA2, I suspect that PBKDF2-SHA256 is now stronger than bcrypt based on the "if my server spends X seconds hashing this password, how much money will someone need to spend to crack it" metric.
I waffle about with this metric. If it's cheap to buy a server with some feature, it's obviously cheap for an attacker to buy the same. Widespread SHA2 hardware means that SHA2 cracking hardware is also available to even the poorest of crackers. I think there's a sliding scale, where the ratio changes for some attackers but not for all.
Right, sophisticated attackers have had custom SHA256 circuits for a long time; less sophisticated attackers are only gaining them now that they are present in CPUs. But if you're defending against such less sophisticated attackers, you're still not losing anything; worst case, SHA256 instructions in CPUs give them the same speedup as you're getting so their cost remains fixed.
The problem with using iterated SHA2 for passwords is that GPU/FPGA/ASIC are orders of magnitude faster than the CPU-based "normal" usage. So while increasing the number of rounds makes it more difficult for an attacker, they already have an edge by being able to use faster technologies.
Ideally you'd use something like Argon2 or any of the other finalists from the Password Hashing Competition[1].
I don't know what you mean by this. I understand that
SHA2 is poor for some things, but I'm not sure how this
illustrates that.
You want password hashes to be very slow, (and to use a lot of RAM) to make brute force attacks difficult. SHA2 is fast, and having hardware support makes it even faster. This makes it a bad choice for a password hash.
> Also, this is another really good reason never to use a sha2 as your hashing algo for password storage.
I don't know what you mean by this. I understand that SHA2 is poor for some things, but I'm not sure how this illustrates that.