Why is SHA-256 not good for passwords?
It's all about reducing the overall risk of loss. A good hash algorithm makes it impossible to reverse the hash value to compute the original text. However, passwords are very, very short. By making a guess at a password, the attacker can compare the output of his SHA-256 against the SHA-256 that he finds in the database. And because passwords are so short, testing many password guesses this way is easy for a computer. For a few thousand dollars you can buy a small supercomputer dedicated to SHA-256 testing (used for bitcoin mining), which enables an attacker to test 16 trillion different password guesses per second. That is much more effective than trying to break SHA-256.
Hashing passwords is not about trying to prevent the cracking of any one single password. Web site owners are much more concerned because they have a database of a million users, and when attackers break in, they frequently steal a copy of the database of passwords. They want to make it hard for the attacker to break all of the passwords in their database.
With the dedicated hardware (or an array of botnet zombies) an attacker can easily break the vast majority of passwords in a typical database where they are only protected by a single iteration of SHA-256. And breaking passwords on one site enables attackers to take advantage of people who reuse their passwords on multiple sites. This is a precursor to performing Account Take Over (ATO) attacks, where they reuse the stolen passwords to access bank accounts or gift cards, and steal actual money.
To defend against this, a purpose-built password protecting algorithm is built as a time-waster. For example, PBKDF2 executes a hash algorithm hundreds, thousands, or millions of times, depending on how you configure it. This increases the amount of work that an attacker needs to do to execute a single test by that large factor. If you set PBKDF2 to execute a million iterations, that would reduce the effectiveness of the box above to testing only 16 million password guesses per second. An attacker would only be able to break a millionth of the passwords in the database when compared to cracking a database where they were stored as single SHA-256. That's the risk reduction.
In addition to John's excellent answer, there's another important thing to consider.
When checking a password, a lot of time is spent in actions like looking up the stored account information (username, password) in a database.
If you have a fast hashing algorithm, that lookup now takes up a significant portion of your password validation. This makes it relatively easy for an intruder to do an attack where he just fires off random names and passwords and determines which names rather than passwords don't exist by timing the responses.
By slow hashing the incoming password before sending it to the database for comparison with the stored password, you're taking the duration of the database lookup and password comparison themselves out of the time needed for checking passwords. Result is that a failed lookup now takes the same time (within margin for network latency etc.) as a successful one.
Of course this assumes you hash the incoming password before trying to retrieve the user information. If you don't, a fail for a non-existent user would be a lot faster than a fail for an existing user with a bad password, giving the person doing an attack on your system potential information about which of the attempts he made contained actual usernames, even if he didn't know those were actual usernames to begin with.
Does this happen in practice? No idea. But that was one reason for slow hashing mechanisms our pentest team told us several years ago.