Thread: ODBC problem
Hi! I'm using postgres 7.0.2 running in Linux. I tried to install Postgres ODBC driver in my Windows95 PC just to test if i can connect to my Postgres database using ODBC. I also downloaded ZEOS database explorer to test if this will work. After configuring User DSN and Zeos Databse Explorer Logon, i got this message: Password Authentication failed for user 'user' I tried other users and still the same problem. My Postgres is already running with -i parameter (compiled with '--with-odbc') and i don't have any problem accessing my database from another linux machine. I checked Postgres log file and it shows the same message. By the way, my Postgres server is configured to "crypt" authentication type. I'm planning to develop VB application that will use Postgres as my database server. Please advise. Thanks George
> By the way, my Postgres server is configured to "crypt" authentication > type. That's the reason... My understanding is that there is no libcrypt for win32 so the windows ODBC driver doesn't support crypt passwords. Allow passwords in the clear (change 'crypt' to 'password' in pg_hba.conf) and it should work fine. Of course this could be a security hole so be careful what you do. Be sure to limit the IPs that are allowed to connect. Alternatively, you could do something I've thought about but never done myself.. set up a ssh tunnel from the client to the server. I think this can be done. Even if the ODBC driver did support crypt passwords, the sql queries and responses could be picked up just as easily so there wouldn't really be much of a security gain. If you're in an environment where non-crypt passwords are a security risk, then ssh (or some other encryption) is probably the way to go. Thoughts?? -Cedar
On Sat, 7 Oct 2000, Cedar Cox wrote: > > By the way, my Postgres server is configured to "crypt" authentication > > type. > > That's the reason... My understanding is that there is no libcrypt for > win32 so the windows ODBC driver doesn't support crypt passwords. Allow > passwords in the clear (change 'crypt' to 'password' in pg_hba.conf) and > it should work fine. Of course this could be a security hole so be > careful what you do. Be sure to limit the IPs that are allowed to > connect. Except for the fact that crypt provides little if no security increase. Even though only a crypted password is sent over the wire, that crypted password can still be captured off the wire and replayed to get access. Plus crypt is a rather fast algorithm, making it easy to brute-force. Of course, this is all pretty typical for databases. Most databases transmit passwords in the clear. Some try a lame scramble, which is trivial to unscramble and worse than crypt in that it is easy to reverse. Even databases that don't transmit the password in the clear can by easily broken by a replay attack, or if driver source is available, simply patch the driver to accept already encrypted passwords. Tom
Tom Samplonius writes: > Except for the fact that crypt provides little if no security increase. > Even though only a crypted password is sent over the wire, that crypted > password can still be captured off the wire and replayed to get access. Only if you happen to get the same salt from the server every time, which is rather unlikely. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Samplonius writes:
>> Except for the fact that crypt provides little if no security increase.
>> Even though only a crypted password is sent over the wire, that crypted
>> password can still be captured off the wire and replayed to get access.
> Only if you happen to get the same salt from the server every time, which
> is rather unlikely.
However, the standard crypt algorithm only has a small number of
distinct salt values, so an attacker who's sniffed one login transaction
can connect repeatedly until challenged with the same salt he saw used
before.
We have talked about adding a higher-security login protocol --- you can
find past threads about this in the pghackers archive. IIRC a fairly
complete design was worked out, but no one's got round to implementing
it yet. There might still have been some unresolved objections, too.
regards, tom lane
Hi, Does anyone knows where I can find a 16-bits ODBC driver for PostgreSQL 7.0? I want to migrate the backoffice from Access to PostgreSQL but one of the users uses a 16-bits ODBC connection to the database. Any help?? gr, Willem
On Mon, 9 Oct 2000, Tom Lane wrote: .. > We have talked about adding a higher-security login protocol --- you can > find past threads about this in the pghackers archive. IIRC a fairly > complete design was worked out, but no one's got round to implementing > it yet. There might still have been some unresolved objections, too. > > regards, tom lane Perhaps I didn't make my point clear: The only point of a password is to protect something. If that something is transmitted in the clear, then from a hackers point of view there's almost no point in having a password. Of course this only applies to fetching data.. updates are a different story. So. If working with sensitive data, shouldn't the data be encrypted as well, not just the login sequence? Is ssh a good way to go (assuming you have an account on the PG machine), and is what I proposed possible? -Cedar
Cedar Cox <cedarc@visionforisrael.com> writes:
> So. If working with sensitive data, shouldn't the data be encrypted as
> well, not just the login sequence?
Yup; see SSL.
IIRC this was one of the reasons why a sniff-proof password security
protocol didn't seem like a critical issue.
regards, tom lane
On Mon, 9 Oct 2000, Tom Lane wrote: > > Yup; see SSL. > > IIRC this was one of the reasons why a sniff-proof password security > protocol didn't seem like a critical issue. Ooooh-K. Sounds good, but I know next to nothing about SSL. Where is a good place to start? Had a look at the PG source, from the looks of it, a SSL link is established before any other data is sent (including username/password), correct? Are there any special libraries required for compiling PG with SSL support? Also, what about use of SSL inside/outside the US? Now for the big question: Does the ODBC driver support SSL connections? -Cedar
Cedar Cox <cedarc@visionforisrael.com> writes:
> SSL link is established before any other data is sent (including
> username/password), correct?
Right. BTW, I believe the SSL support is actually broken in 7.0.* :-(
(the lack of complaints doesn't say much for the number of people
worried about comsec for PG). It's allegedly fixed in current sources
but I haven't tried it. I'd suggest experimenting with a current
snapshot.
> Are there any special libraries required for
> compiling PG with SSL support? Also, what about use of SSL inside/outside
> the US?
You need SSL which is a separate package. Beyond that I haven't a clue;
you'll have to go look for info about SSL.
> Now for the big question: Does the ODBC driver support SSL connections?
[... grep ...] Apparently not. libpq (and therefore anything built
atop libpq) does, but ODBC doesn't use libpq. ODBC needs some other
updates too --- for instance, it still thinks there's a limit on query
string length.
Right now I don't think anyone is actively maintaining ODBC, but it
badly needs someone to care for it. Any volunteers out there?
regards, tom lane
In article <19102.971191714@sss.pgh.pa.us>, Tom Lane <tgl@sss.pgh.pa.us> writes >Right now I don't think anyone is actively maintaining ODBC, but it >badly needs someone to care for it. Any volunteers out there? Does anyone know if it's possible to compile it using freely available tools? I'm thinking the win32 cross-compiler, mingw32 or something. I do have an old copy of VisualC++ (4.2), but try to avoid using it. Do I need and ODBC driver SDK or something? I don't know enough about ODBC to maintain the driver properly, but if I can get it to build in a reasonable way, I'll take all the available patches and make binaries available... -- Jamie Walker "While there are no known bugs in it, it might jamie@sagaxis.co.uk destroy your filesystems, eat your data and http://www.sagaxis.co.uk/ start World War III. You have been warned."