I agree... it just plain scares me that so many large systems don't even bother with such trivial precautions as hashing. It's even more trivial than sql injections. Up until it happened, I would have _never_ guessed myspace & phpbb stored plaintext. It seems borderline incompetent.
I've implemented tons of little one-off account systems, for websites small enough they'll probably never even see a hacker. But before I even implemented the first one, I went through the trouble of finding the best password hash algorithm I could (http://people.redhat.com/drepper/SHA-crypt.txt)
Sure, I've had customers ask "why can't it just email me my password when I forget?" But you know what? Just a few minutes of quick explanation, and even people with NO math or cs background can understand why it's important.
So for the love of the gods, people, please take an hour out of your time to put in a hash alg (even md5-crypt is better than nothing)... it's just not that hard.
---
Just to go off on a rant here...
I've also noticed in some web applications there is the tendency to just pick a hash alg at random. Be warned: not all hash algorithms are created equal.
"Checksum" algorithms such as CRC32 are woefully insufficient: easy to reverse (for small strings), easy to find collisions. They're basically just one guessable step away from plaintext.
"Integrity" algorithms such as MD5 & SHA are a little better, since they're very hard to reverse, and difficult to find collisions.
The problem with using these types of hashes directly is that they will always hash a password to the _same_ string. While that's desirable for their purposes (file integrity, etc), that's not good at all for passwords: you can pre-build a table of known mappings beforehand, and use it to quickly guess many passwords in parallel (aka a rainbow table): Given a table of 10k user passwords hashed like this, and a pre-built table, the odds are very good you'll get a significant number of the passwords in a very short amount of time.
This is why a proper "Password" hash (eg bcrypt, md5-crypt, sha-crypt) includes a "salt" which is randomly generated each time the password is set (and not just the first time). This prevents the rainbow attacks which are possible on plain integrity hashes. But prepending (or appending) the salt is not enough, because since it's effect can be undone mathematically, at least enough so that it presents no real additional barrier.
Genuine password hashes, while using an integrity hash their basis, mix & blend the password and the salt in so many variable ways as to make this reversal impossible. And there are so many nuances here that _you should not roll your own_ (unless you're Bruce Schneier). Read bcrypt, sha-crypt or md5-crypt's specs for some details.
Note: don't use the old unix-crypt, while it is a password hash in the strict sense, it's so old and simple, it's barely stronger than crc32.
Note: sha-crypt adds additional flexibility via it's "rounds" system, allowing it to easily grow more complicated as computers grow more powerful. This is why I prefer it above all the others.
End rant: all this is why you should use sha-crypt or md5-crypt, and nothing lesser.