Thread: ODBC and crypted passwords
Hi, I'm playing with the ODBC driver (which works fine) but I like passwords to travel encrypted, which is not supported at the moment. Is there any work being done on this? The TODO says (in 1998) that the priority is low. Why is that? I can't believe nobody ever needed this. If I'm not mistaken the only way to use ODBC right now is to simply trust a host or accept plain passwords. Is there something which makes a 'crypt' implementation hard? Regards, +-----------------------------------------------------------------------+ | Henk van Lingen, Systems Administrator, <henkvl@cs.uu.nl> | | Dept. of Computer Science, Utrecht University. phone: +31-30-2535278 | +----------------- http://www.cs.uu.nl/people/henkvl/ ------------------+
> -----Mensaje original----- > De: pgsql-interfaces-owner@hub.org > [mailto:pgsql-interfaces-owner@hub.org]En nombre de Henk van Lingen > Enviado el: sábado, 08 de abril de 2000 16:35 > Para: pgsql-interfaces@postgresql.org > Asunto: [INTERFACES] ODBC and crypted passwords > > > Hi, > > I'm playing with the ODBC driver (which works fine) but I like passwords > to travel encrypted, which is not supported at the moment. > > Is there any work being done on this? The TODO says (in 1998) that the > priority is low. Why is that? I can't believe nobody ever needed this. > If I'm not mistaken the only way to use ODBC right now is to simply trust > a host or accept plain passwords. Is there something which makes a 'crypt' > implementation hard? I'm really interested in this feature too. Actually I must trust every IP, so my only security is in passwords. An anybody with a sniffer in my ISP can see the passwords. Thank you.
Henk van Lingen <henkvl@cs.uu.nl> writes:
> I'm playing with the ODBC driver (which works fine) but I like passwords
> to travel encrypted, which is not supported at the moment.
> Is there any work being done on this? The TODO says (in 1998) that the
> priority is low. Why is that?
I think that just means that Bryan doesn't care about it very much ;-).
If you do, step right up and submit a patch. The way things work around
here is that tasks get done when someone is motivated enough to do them.
> Is there something which makes a 'crypt' implementation hard?
I imagine the problem is that he doesn't want to depend on the 'crypt'
library, which is standard on Unixen but not (AFAIK) on Windows.
Otherwise it'd be easy to transpose libpq's code into the odbc driver.
(OTOH, I believe there are ports of libpq for Windows, so maybe crypt()
is available there? Anyone know?)
regards, tom lane
> > Is there something which makes a 'crypt' implementation hard? > > I imagine the problem is that he doesn't want to depend on the 'crypt' > library, which is standard on Unixen but not (AFAIK) on Windows. > Otherwise it'd be easy to transpose libpq's code into the odbc driver. > (OTOH, I believe there are ports of libpq for Windows, so > maybe crypt() > is available there? Anyone know?) Actually, the crypt()ed authentication is not supported on libpq for Win32. I meant to do this, but I had completely forgotten... //Magnus
Magnus Hagander <mha@sollentuna.net> writes:
>>>> Is there something which makes a 'crypt' implementation hard?
>>
>> I imagine the problem is that he doesn't want to depend on the 'crypt'
>> library, which is standard on Unixen but not (AFAIK) on Windows.
>> Otherwise it'd be easy to transpose libpq's code into the odbc driver.
>> (OTOH, I believe there are ports of libpq for Windows, so
>> maybe crypt() is available there? Anyone know?)
> Actually, the crypt()ed authentication is not supported on libpq for Win32.
> I meant to do this, but I had completely forgotten...
Hmm. Can we find a freely-distributable version of libcrypt anywhere?
(Actually, now that I think about it, I'm not entirely sure that crypt()
implements exactly the same transformation on every Unix platform.
It may be that you have to have a version of crypt() that matches the
one on your server's platform. That would be a pain in the neck ...
but if we did find an open-source libcrypt, maybe we could standardize
on using it in preference to vendor crypts...)
regards, tom lane
Tom Lane wrote: > Hmm. Can we find a freely-distributable version of libcrypt anywhere? > > (Actually, now that I think about it, I'm not entirely sure that crypt() > implements exactly the same transformation on every Unix platform. > It may be that you have to have a version of crypt() that matches the > one on your server's platform. That would be a pain in the neck ... > but if we did find an open-source libcrypt, maybe we could standardize > on using it in preference to vendor crypts...) I have no problem running the PostgreSQL server on Solaris and using a FreeBSD client with crypt authentication. Both systemsuse DES. Problems arise when systems try to work around the US export restrictions and supply MD5 or other weak encryption. For the same reason, you cannot make strong authentication code available on your website. The best you cando is provide a pointer to some DES implementation outside the US and instruct users to download and use this one if theirsystems do not work together. Another alternative is to include MD5 in the distribution, but use the system crypt bydefault, with a configuration option to switch to MD5. =alex
I believe that the US export restrictions have been lifted. cheers, Stephen Davies. Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <mha@sollentuna.net> writes: > >>>> Is there something which makes a 'crypt' implementation hard? > >> > >> I imagine the problem is that he doesn't want to depend on the 'crypt' > >> library, which is standard on Unixen but not (AFAIK) on Windows. > >> Otherwise it'd be easy to transpose libpq's code into the odbc driver. > >> (OTOH, I believe there are ports of libpq for Windows, so > >> maybe crypt() is available there? Anyone know?) > > > Actually, the crypt()ed authentication is not supported on libpq for Win32. > > I meant to do this, but I had completely forgotten... > > Hmm. Can we find a freely-distributable version of libcrypt anywhere? > > (Actually, now that I think about it, I'm not entirely sure that crypt() > implements exactly the same transformation on every Unix platform. > It may be that you have to have a version of crypt() that matches the > one on your server's platform. That would be a pain in the neck ... > but if we did find an open-source libcrypt, maybe we could standardize > on using it in preference to vendor crypts...) > > regards, tom lane ======================================================================== Stephen Davies Consulting scldad@sdc.com.au Adelaide, South Australia. Voice: 08-8177 1595 Computing & Network solutions. Fax: 08-8177 0133
On Sun, Apr 09, 2000 at 04:22:58PM -0400, Alex Verstak wrote: > > Tom Lane wrote: > > Hmm. Can we find a freely-distributable version of libcrypt anywhere? > > > > (Actually, now that I think about it, I'm not entirely sure that crypt() > > implements exactly the same transformation on every Unix platform. > > It may be that you have to have a version of crypt() that matches the > > one on your server's platform. That would be a pain in the neck ... > > but if we did find an open-source libcrypt, maybe we could standardize > > on using it in preference to vendor crypts...) > > I have no problem running the PostgreSQL server on Solaris and > using a FreeBSD client with crypt authentication. Both systems > use DES. Problems arise when systems try to work around the US > export restrictions and supply MD5 or other weak encryption. > > For the same reason, you cannot make strong authentication code > available on your website. The best you can do is provide > a pointer to some DES implementation outside the US and instruct > users to download and use this one if their systems do not work > together. Another alternative is to include MD5 in the distribution, > but use the system crypt by default, with a configuration option > to switch to MD5. I wonder whether SASL http://asg.web.cmu.edu/sasl/ is worth considering. AFAICT postgresql would say authenticate userid,password,mechanism, and sasl replies yes or no, and different mechanisms seem to plug in reasonably cleanly. Cheers, Patrick
> Magnus Hagander <mha@sollentuna.net> writes: > >>>> Is there something which makes a 'crypt' implementation hard? > >> > >> I imagine the problem is that he doesn't want to depend on > the 'crypt' > >> library, which is standard on Unixen but not (AFAIK) on Windows. > >> Otherwise it'd be easy to transpose libpq's code into the > odbc driver. > >> (OTOH, I believe there are ports of libpq for Windows, so > >> maybe crypt() is available there? Anyone know?) > > > Actually, the crypt()ed authentication is not supported on > libpq for Win32. > > I meant to do this, but I had completely forgotten... > > Hmm. Can we find a freely-distributable version of libcrypt anywhere? > > (Actually, now that I think about it, I'm not entirely sure > that crypt() > implements exactly the same transformation on every Unix platform. > It may be that you have to have a version of crypt() that matches the > one on your server's platform. That would be a pain in the neck ... > but if we did find an open-source libcrypt, maybe we could standardize > on using it in preference to vendor crypts...) There is one in FreeBSD at least (since we want BSD license, right?) I don't know how portable it is - but it shuold be Ok if it's in FreeBSD. And I beleive it's not the same on different platforms, so we'd probably want to include it (at least optionally) in the server. It's in the FreeBSD CVS (I found it through the cvsweb interface) in /src/secure/lib/libcrypt/crypt-des.c, I think. //Magnus
I did say this some time ago when someone asked about implementing crypt() in the ODBC driver, the JDBC driver implements crypt() itself (based on some code I found in Australia, getting round the export problems). As for the transformation being different on a few/every Unix platform, no one has emailed me saying that crypt doesn't work, and I've heared of people using JDBC with backends on Solaris, Linux, and some must be using others... Peter -- Peter Mount Enterprise Support Maidstone Borough Council Any views stated are my own, and not those of Maidstone Borough Council. -----Original Message----- From: Alex Verstak [mailto:averstak@vt.edu] Sent: Sunday, April 09, 2000 9:23 PM To: pgsql-interfaces@postgresql.org Subject: Re: [INTERFACES] ODBC and crypted passwords Tom Lane wrote: > Hmm. Can we find a freely-distributable version of libcrypt anywhere? > > (Actually, now that I think about it, I'm not entirely sure that crypt() > implements exactly the same transformation on every Unix platform. > It may be that you have to have a version of crypt() that matches the > one on your server's platform. That would be a pain in the neck ... > but if we did find an open-source libcrypt, maybe we could standardize > on using it in preference to vendor crypts...) I have no problem running the PostgreSQL server on Solaris and using a FreeBSD client with crypt authentication. Both systemsuse DES. Problems arise when systems try to work around the US export restrictions and supply MD5 or other weak encryption. For the same reason, you cannot make strong authentication code available on your website. The best you cando is provide a pointer to some DES implementation outside the US and instruct users to download and use this one if theirsystems do not work together. Another alternative is to include MD5 in the distribution, but use the system crypt bydefault, with a configuration option to switch to MD5. =alex
On Sat, 8 Apr 2000, Tom Lane wrote: > Henk van Lingen <henkvl@cs.uu.nl> writes: > > I'm playing with the ODBC driver (which works fine) but I like passwords> > to travel encrypted, which is not supported at the moment. > > > Is there any work being done on this? TheTODO says (in 1998) that the > > priority is low. Why is that? > > I think that just means that Bryan doesn't care aboutit very much ;-). > If you do, step right up and submit a patch. The way things work around > here is that tasks getdone when someone is motivated enough to do them. I know, but I like to know what others know first :-) Anyway, I looked around and... > > Is there something which makes a 'crypt' implementation hard? > > I imagine the problem is that he doesn't want todepend on the 'crypt' > library, which is standard on Unixen but not (AFAIK) on Windows. > Otherwise it'd be easy to transposelibpq's code into the odbc driver. didn't find a libcrypt but did find an ANSI C implementation of crypt(3) here: http://www.cs.ucsb.edu/~mdipper/ I included this in connection.c, installed visual C++, changed a few lines and it works for me. If anyone is interested, you can find my connection.c and new DLL here: http://www.cs.uu.nl/~henkvl/psqlodbc/ Regards, +-----------------------------------------------------------------------+ | Henk van Lingen, Systems Administrator, <henkvl@cs.uu.nl> | | Dept. of Computer Science, Utrecht University. phone: +31-30-2535278 | +----------------- http://www.cs.uu.nl/people/henkvl/ ------------------+
> If anyone is interested, you can find my connection.c and new DLL here: > http://www.cs.uu.nl/~henkvl/psqlodbc/ Is the change done in a way that does not *require* crypt? If so, would you consider submitting this as a feature to the main code tree? - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
On Wed, 12 Apr 2000, Thomas Lockhart wrote: > > If anyone is interested, you can find my connection.c and new DLL here: > > http://www.cs.uu.nl/~henkvl/psqlodbc/ > > Is the change done in a way that does not *require* crypt? If so, If I understand what you mean: I think so. I just included the crypt function in connection.c so that file is all you need. > would you consider submitting this as a feature to the main code tree? Yes, but I have to lookup how that should be done first... Anyways, I have a related question. Watching the debug-logfile, I was puzzled by that fact that the backend gave the odbc frontend another salt every try. Looking at the backend sources I found out that this is just the way it works. The server stores just the passwords ( in binary), not encrypted passwords. This must be the reason there is no 'map option' in pg_hba.conf for crypted passwords and no way to use the normal UNIX password file as you can do with unencrypted authentication. But maybe nobody wants that. Just curious... Regards, -- +-----------------------------------------------------------------------+ | Henk van Lingen, Systems Administrator, <henkvl@cs.uu.nl> | | Dept. of Computer Science, Utrecht University. phone: +31-30-2535278 | +----------------- http://www.cs.uu.nl/people/henkvl/ ------------------+
One thing that may be useful, is not to check against the unix password file, but to use PAM. That way, you could even authenticate against the dreadded NT accounts, unix password file, dbm file etc... Anyhow, this is something to think about for the future ;-) Peter -- Peter Mount Enterprise Support Maidstone Borough Council Any views stated are my own, and not those of Maidstone Borough Council. -----Original Message----- From: Henk van Lingen [mailto:henkvl@cs.uu.nl] Sent: Wednesday, April 12, 2000 10:47 AM To: pgsql-interfaces@postgresql.org Subject: Re: [INTERFACES] ODBC and crypted passwords [snip] Anyways, I have a related question. Watching the debug-logfile, I was puzzled by that fact that the backend gave the odbc frontend another salt every try. Looking at the backend sources I found out that this is just the way it works. The server stores just the passwords ( in binary), not encrypted passwords. This must be the reason there is no 'map option' in pg_hba.conf for crypted passwords and no way to use the normal UNIX password file as you can do with unencrypted authentication. But maybe nobody wants that. Just curious... Regards, -- +----------------------------------------------------------------------- + | Henk van Lingen, Systems Administrator, <henkvl@cs.uu.nl> | | Dept. of Computer Science, Utrecht University. phone: +31-30-2535278 | +----------------- http://www.cs.uu.nl/people/henkvl/ ------------------+
Peter Mount wrote: > > One thing that may be useful, is not to check against the unix password > file, but to use PAM. That way, you could even authenticate against the > dreadded NT accounts, unix password file, dbm file etc... > > Anyhow, this is something to think about for the future ;-) IMHO this defeats the purpose of crypt - not to send plaintext passwords over the net. OTOH, it could be done over a secure (SSL/TLS) channel of course. ----------- Hannu
Thats why I said its for the future :-) I always use crypt if it's going outside the server, so some form of encrypted transport is required. Anyhow, the main reason I mentioned PAM, is that not every platform would have a password file (NT for example, although you can configure one in cygwin). Peter -- Peter Mount Enterprise Support Maidstone Borough Council Any views stated are my own, and not those of Maidstone Borough Council. -----Original Message----- From: Hannu Krosing [mailto:hannu@tm.ee] Sent: Wednesday, April 12, 2000 10:47 AM To: Peter Mount Cc: 'Henk van Lingen'; pgsql-interfaces@postgresql.org Subject: Re: [INTERFACES] ODBC and crypted passwords Peter Mount wrote: > > One thing that may be useful, is not to check against the unix password > file, but to use PAM. That way, you could even authenticate against the > dreadded NT accounts, unix password file, dbm file etc... > > Anyhow, this is something to think about for the future ;-) IMHO this defeats the purpose of crypt - not to send plaintext passwords over the net. OTOH, it could be done over a secure (SSL/TLS) channel of course. ----------- Hannu
cf http://asg.web.cmu.edu/sasl/ ? On Wed, Apr 12, 2000 at 11:59:19AM +0100, Peter Mount wrote: > Thats why I said its for the future :-) > > I always use crypt if it's going outside the server, so some form of > encrypted transport is required. Anyhow, the main reason I mentioned > PAM, is that not every platform would have a password file (NT for > example, although you can configure one in cygwin). > > Peter > > -- > Peter Mount > Enterprise Support > Maidstone Borough Council > Any views stated are my own, and not those of Maidstone Borough Council. > > > > -----Original Message----- > From: Hannu Krosing [mailto:hannu@tm.ee] > Sent: Wednesday, April 12, 2000 10:47 AM > To: Peter Mount > Cc: 'Henk van Lingen'; pgsql-interfaces@postgresql.org > Subject: Re: [INTERFACES] ODBC and crypted passwords > > > Peter Mount wrote: > > > > One thing that may be useful, is not to check against the unix > password > > file, but to use PAM. That way, you could even authenticate against > the > > dreadded NT accounts, unix password file, dbm file etc... > > > > Anyhow, this is something to think about for the future ;-) > > IMHO this defeats the purpose of crypt - not to send plaintext passwords > > over the net. > > OTOH, it could be done over a secure (SSL/TLS) channel of course. > > ----------- > Hannu