Better yet, don't store passwords at all. Use something like Digest::MD5 to store a digest of the password and when the user enters a username and password, create a new digest of their password and compare that against what is in the database. It's not fullproof (nothing ever is), but at the very least, it's considerably more difficult for someone getting a copy of the password digests to determine what those passwords actually are.

Also, you mentioned "security by obscurity". This has a tendency to induce a knee-jerk "if it's reasonably secure, you don't have to obscure it" reaction. However, if it's secure, obscurity can add to security by increasing the difficult of getting information useful for an attack. For example, if your code is secure, having use CGI::Carp 'fatalsToBrowser' in your code will theoretically not reduce the security. In reality, unanticipated bugs might trigger that and give information that might encourage the cracker. In other words, so long as true security is a top priority, obscurity is not such a bad thing.

Also, though it's peripheral to your question, you might find the LiveJournal login rather interesting. They use JavaScript to create a digest out of the password, remove the plaintext password from the form and then they submit. They don't transmit the plaintext at all. This increases security over a non-encrypted request.

Update: Oh, you meant database passwords. Sigh.