> Say that your application offers a way for each user to set/change > his own password. > > When I (using your application) change my password, you could > combine my new password with a secret value and then send the > result to the PG server (so now the PG server thinks that my > password is my_password+your_secret). This is a special case of (2,2) secret sharing: http://en.wikipedia.org/wiki/Secret_sharing Here the secret is the actual password, a+b, shared into two parts, a and b. The above scheme suffers from the problem that the user now knows quite a lot about the secret.
Hmmm... how would the user know anything about the secret unless he could somehow get to the resulting combined password?
For example, if my password is "chocolate" and the application secret is "fudge", I can't recover any part of the combination "chocolate-fudge" unless I can:
a) see "chocolate-fudge" in the network data stream (assume that I can't because Andrus is smart enough to avoid sending cleartext passwords over the net)
b) see "chocolate-fudge" in the PG password table (again, Andrus is smart enough to use MD5 authentication so "chocolate-fudge" is never stored on the server)
If this is an issue, there are more sophisticated combining schemes that give the user no advantage over someone who knows neither half of the secret.
Absolutely, but I wanted to get the basic idea across. Andrus' application knows the correct password for each user (or, more precisely, his application knows how to derive the correct password from the user-supplied password - Andrus doesn't have to store each password on the client side or anything like that) so his application can log in, but the users don't know any valid passwords so they can't get into the database with a tool like PgAdmin.
So, in your opinion, this isn't a crazy idea? It should work? But it could be made more secure if Andrus is particularly paranoid.
-- Korry
P.S. Thanks for the feedback.
