Although I've never tried this personally, it seems like the following would be a good solution: First, set up two different database users: The first one, script_user, has read-access to only the users table (no access to other tables), which can look like this:

users:
+----------+----------------+
| username | crypt_pw       |
+----------+----------------+
| joe      | x47s$EWn47#fdb |
| jane     | p98uyDNR93@$w5 |
| ...
[download]

while priv_user has read-write access to all tables.

Now the trick is in the crypt_pw column. This is not the hash of the users' passwords, as you may expect -- it is instead the result of a symmetric cipher of priv_user's database password, with each user's password as the key. Obviously generating these columns this must be done beforehand or by some otherwise privileged and "safe" script -- otherwise priv_user's password would have to be hard-coded into some script, making it vulnerable to attacks listed above. You get the point.

So the authentication process will look like this:

1. User enters username joe and password in $joe_pw using some authentication scheme (*).
2. The script logs into DB using unprivileged script_user and hard-coded password. Since we have read-only access, we are pretty safe hard-coding this password.
3. The script gets the crypt_pw value for joe, and deciphers it using his $joe_pw as the cipher key -- this deciphered value is stored in $priv_pw.
4. Attempt to relogin to the DB using login priv_user, password $priv_pw. If successful, then $joe_pw was indeed correct as joe's password.
5. undef $priv_pw, $joe_pw; to be extra-safe ;)

(*) You can use many methods to achieve step 1. For instance, mod_perl will let you get the password from a HTTP basic authentication request, or you can use a CGI script over SSL, etc. depending on your paranoia level.

Of course, this whole scheme hinges on being able to get 2 DB users, one with with nonstandard permissions -- which isn't always possible at many ISPs. It also makes resetting priv_user's password hard without also resetting the other users' passwords.

Are there any knowledgeable security expert monks out there with critiques of this method? The only hard-coded password would be a "safe" one that is only allows read-only access to a single table. With a strong cipher, you will not be able to determine the password for priv_user without knowing one of the allowed users' passwords. Please share any insights, as my curiosity is piqued by this method.

I hope this helps, and good luck.

blokhead