Re: How to allow users to log on only from my application not from pgadmin - Mailing list pgsql-general
From | Mark Walker |
---|---|
Subject | Re: How to allow users to log on only from my application not from pgadmin |
Date | |
Msg-id | 45C2842F.7040501@omnicode.com Whole thread Raw |
In response to | Re: How to allow users to log on only from my application not from pgadmin (Paul Lambert <paul.lambert@autoledgers.com.au>) |
Responses |
Re: How to allow users to log on only from my application
not from pgadmin
|
List | pgsql-general |
OK, I've thought about this a bit more and have come to the conclusion that storing the password locally in any way is completely insecure. Here are simple ways of hacking it: 1. If you use libpq in a shared lib(dll, etc). Replace PQconnectdb with your own version, rebuild and use your new dll to snatch the password. 2. If you use libpq in a static lib. Search for the PQconnectdb's image and do the same as #1. 3. If you don't use libpq. Search for strings that contain things like "host = ", "user = ", "password = ", etc and hack in your own code. I think there are really only 2 ways to securely deal with this: 1. Each user has a postgresql role in a way that I mentioned in a previous thread concerning the limit on number of users. You'd also have to secure your database via stored procedures and individual table role based access. 2. Proxy server method. Storing passwords locally would be anywhere from trivial to moderately difficult to hack. Paul Lambert wrote: > Mark Walker wrote: >> I'm curious. How do you feel about having a scrambling algorithm >> embedded in your application, but having the scrambled password >> publicly readable in a config file? Does that seem secure? This is >> what you have to do if you want your users to connect to different >> databases choosing their own password. > > I never said anything about a readable config file. > > If your users are specifying their own password and you want to store > passwords in a local config file on the users system then nothing is > stopping you doing so. If this was the case I would put only what the > user specifies in said config file, then when the password is > retrieved from the file on application startup, perform your > hashing/adding secret words etc. Anything I've done I do this way (in > most cases though I use the registry rather then a config file since I > deal primarily with weenblows. > > >> How would you deal with open source applications where the >> scrambling/unscrambling algorithms would presumably be public? Are >> there methodologies for developing custom algorithms that could be >> triggered during builds? >> > > Open source applications are a different situation altogether. The > kind of security that Andrus appears to be looking for would give the > impression that it is not an open source application he is dealing > with. I could be wrong though. > Having said that, yes if you are using an open source application any > scrambling algorithms would be public, as would any passwords embedded > within your source. > > In this case, then perhaps a 'proxy' application running on your own > server would be the best option (I think someone else suggested this > earlier in the thread) for serving the database requests. > >
pgsql-general by date: