It's more common to get access to the database through sql-injection rather than hacking the server. So having the encryption key on disk is more secure than plain text in a database but not much more.

It's also possible for the encrypted passwords to be stored in a separate server that only provides a simple web service with two operations: update_password(email, password), mail_password(email) and store passwords hashed in the main database for authentication.

That said, it is far more dangerous to store passwords in a reversible manner than in an irreversible one. I was just noting it was possible to have modestly secure two-way storage.

Personally, I don't even want to deal with storing user passwords so I prefer using OpenID.

(a) You don't have to "hack the server" to read a config file that the web app can also read.

(b) Independent of all the other flaws that will get you arbitrary file read, if you don't know what the cases are where SQLI gets you arbitrary file read, you're probably not qualified to design your own password storage. I really mean that with all due respect.

Yikes, I didn't realize databases included the ability to edit the filesystem.

I don't ever intend to get into the area of writing my own password storage until I learn a lot more in the area of security. I am only aware of how little I don't know about what I don't know.

Yep.

    CREATE TABLE foo ( x TEXT );
    LOAD DATA INFILE "/etc/whatever" INTO TABLE foo ; 
    SELECT x FROM foo;

Did you know about INTO DUMPFILE in SELECT statements? =)