I'm always amazed whenever I hear about some security fiasco where a whole bunch of user information, including passwords, is obtained from some unprotected database.
I mean, I may not be a security expert, but even I know that you don't need to store the actual password in a database to allow users to login in securely.
My standard approach is to store the MD5 checksum of the password, rather than the password itself. In fact, I go further; I build a string combining the user's login id and their password and generate and MD5 from that. This has the advantage that different users with the same password will have a different value stored in the database, making it that much more difficult to gain wider access, even if some other security flaw gives the black hats read access. It doesn't even give up the size of the password, since md5 checksum are always the same length, regardless of the number of bytes in the stream used to build the checksum.
This is still a naive approach; you can do more, including adding additional "salt" to the alogiritm (such as a random number, stored only on the server, that is also factored into the checksum). However, at the core of this approach is the desire to never store a password as plain text. Encrypt it, hash it, obscure it. All you need to do is prove that the user knows the password and you don't need to store the password in plain text to do that.
As I remember, this is the way that Unix has traditionally stored password data, so I continue to wonder whenever I see a design that stores passwords out in the open, waiting to be harvested by the black hats.