What differentiates a password hash from a cryptographic hash besides speed? I understand that password hashes like bcrypt have the principal property of taking a long time to run, but I'm wondering what if anything about password hashes make them superior to merely running a fast cryptographic has a bunch of times.

In particular, why does bcrypt exist when I can just run SHA-256 100000 times? Furthermore, it seems relatively extensible to adapt to increases in computing power. When computers get 100000 times as fast as they are today, I can just reapply the hash to my password hashes 100000 times and at verification time run SHA-256 100000*100000 times to validate a password attempt. Are there flaws in this naive approach. Are there other properties of password hashes that make them particularly suited to hashing passwords? Lack of parallelizability, space complexity, something else?

My question comes about when analyzing a prominent response to the June 2012 incident in which 6 million password hashes were stolen from LinkedIn. In the article, the author emphasizes the value of using a password hash instead of a fast cryptographic hash in validating user passwords. I understood the basic argument for having a hash that's slow but failed to glean from it particular advantages of "password" hashes that made them distinct.
To the best of my knowledge there is no formal distinction, since "password hashes" aren't formally defined.

That said, if you look at this presentation from the author of scrypt you'll see that he wanted:


Password hashing to be CPU hard (i.e. to require significant amounts of CPU processing, in a manner that cannot be optimized away).
Password hashing to be memory hard, i.e. to require large amounts of RAM capacity and RAM I/O bandwidth.


Being CPU hard helps delay offline brute force password breaking, as you note. Being memory hard helps guard against getting dramatic speedups from using a different type of hardware. 

Simple SHA hashes require minimal internal state, and can as such be massively accelerated by running hashing in parallel on the 256+ cores of a modern graphics card. An even larger speedup could be had by creating a bunch of FPGA / ASIC chips dedicated to running SHA operations in parallel.

Being memory-hard gives a measure of protection against this, because currently there is no cheap technology to scale memory-I/O. FPGA's are comparatively 'cheap' to make; but large amounts of low-latency memory isn't.



To your questions:


  I can just run SHA-256 100000 times?


If you loop through the same hash function many times, then there might be a small loss of entropy each time, if the hash function isn't ideal. See "Why does PBKDF2 xor the iterations ..". If you improve your own suggestion, for example by mixing in the salt at each iteration, then you get close to the design of PBKDF2. In that case you should use PBKDF2 instead, because PBKDF2 is a mature and peer reviewed design.


  Furthermore, it seems relatively extensible to adapt to increases in computing power. [...] I can just reapply the hash to my password hashes 100000 times and at verification time run SHA-256 100000*100000


That works. At verification time the end user gives you his password in plain text. So you could also verify the password against the old hash using the old hashing function, and create a new hash from the plaintext, using the new hashing function.



For more, see the scrypt presentation as well as the hash + password tag on Crypto, as well as the past discussions here.

Please note: It's great that you learn about this for your own interest and understanding. When it comes to building production software, you should not create your own password hashing implementation -- you should use an appropriate higher-level library, one that has seen extensive security scrutiny.