Thread: You're on SecurityFocus.com for the cleartext passwords.
Don't know if you know this already, but since april 23, you've been on SecurityFocus.com for the cleartext passwords in pg_shadow: http://www.securityfocus.com/bid/1139 I know it has been discussed at least a couple of times before, but in my opinion this is an issue that needs a solution. The problem with cleartext passwords is not just that root, postgres super user or anyone who has legally or illegally got access to the system can see the passwords a user uses to log in to PostgreSQL. The problem lies in the well known fact that we tend to use the same password several places, if not everywhere. With all the passwords needed these days, that is how it _has_ to be. The first PostgreSQL based site that gets cracked, will make headlines stating that passwords have got into the wrong hands. Do we (or you) want that? Sverre. -- <URL:mailto:sverrehu@online.no> <URL:http://home.sol.no/~sverrehu/> Echelon bait: semtex, bin Laden, plutonium,North Korea, nuclear bomb
On Sat, 6 May 2000, Sverre H. Huseby wrote: > Don't know if you know this already, but since april 23, you've been > on SecurityFocus.com for the cleartext passwords in pg_shadow: > > http://www.securityfocus.com/bid/1139 > > I know it has been discussed at least a couple of times before, but in > my opinion this is an issue that needs a solution. > > The problem with cleartext passwords is not just that root, postgres > super user or anyone who has legally or illegally got access to the > system can see the passwords a user uses to log in to PostgreSQL. The > problem lies in the well known fact that we tend to use the same > password several places, if not everywhere. With all the passwords > needed these days, that is how it _has_ to be. > > The first PostgreSQL based site that gets cracked, will make headlines > stating that passwords have got into the wrong hands. Do we (or you) > want that? You've lost me here ... the only person(s) that can get at those passwords are those that have compromised the system already. Even if the passwords *weren't* in cleartext, there is nothing that stops me from downloading the data/* directory down to my computer and running pg_upgrade to "make it my own", removing the passwords ... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Fri, 5 May 2000, The Hermit Hacker wrote: > You've lost me here ... the only person(s) that can get at those passwords > are those that have compromised the system already. Even if the passwords > *weren't* in cleartext, there is nothing that stops me from downloading > the data/* directory down to my computer and running pg_upgrade to "make > it my own", removing the passwords ... You don't get it. Its one of most basic things about security of the password databases: Cleartext must not be available for anyone, not even the administrators. The damage one can do with list of 10000 passwords far exceeds damage you can do to the database which contain these passwords. Why? Because people tend to use same password everywhere. (Yes, I know that they shouldn't, however, you must take good care of passwords users entrusted to you). There is no excuse for not storing it as a hash or at least in crypt(3) way. -alex
On Fri, 5 May 2000, The Hermit Hacker wrote: > On Sat, 6 May 2000, Sverre H. Huseby wrote: > > > Don't know if you know this already, but since april 23, you've been > > on SecurityFocus.com for the cleartext passwords in pg_shadow: > > > > http://www.securityfocus.com/bid/1139 > > > > I know it has been discussed at least a couple of times before, but in > > my opinion this is an issue that needs a solution. > > > > The problem with cleartext passwords is not just that root, postgres > > super user or anyone who has legally or illegally got access to the > > system can see the passwords a user uses to log in to PostgreSQL. The > > problem lies in the well known fact that we tend to use the same > > password several places, if not everywhere. With all the passwords > > needed these days, that is how it _has_ to be. > > > > The first PostgreSQL based site that gets cracked, will make headlines > > stating that passwords have got into the wrong hands. Do we (or you) > > want that? > > You've lost me here ... the only person(s) that can get at those passwords > are those that have compromised the system already. Even if the passwords > *weren't* in cleartext, there is nothing that stops me from downloading > the data/* directory down to my computer and running pg_upgrade to "make > it my own", removing the passwords ... Same defense I used when I responded to the BugTRAQ post. Even tho I understand the possible ramifications of cleartext passwords, I still stand by my previous comments, an admin needs to properly maintain and protect the systems they're entrusted to. However after reading about the www.apache.org compromise details earlier today I'm of the opinion now that we should look into encrypting the passwords. I'm also of the opinion that I should volunteer to at least help in the fixing of it. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> ... I'm of the opinion now that we should look into encrypting the
> passwords.
I think it'd be a reasonable thing to work on. I don't particularly
intend to be stampeded into doing something about it by "public
relations" pressure from people who would rather make inflated claims
than get their hands dirty by contributing a solution ;-). (And, yes,
these claims are inflated. If you don't trust your dbadmin, the
security of your password is the least of your worries --- the data
in your database may well be far more critical info than anything the
dbadmin could find in your personal account. The general opinion on
the pghackers list has been that password-based security is the least
desirable of the authentication options we offer, anyway. A security-
conscious site wouldn't even be using database passwords.)
The main potential hazard I see is portability. Is crypt(3) available
on *all* the platforms Postgres runs on? Does it give the same answers
on all those platforms? If not, what shall we use instead? Don't
forget that the frontend libraries have to have it too (or are you going
to keep transmitting passwords in cleartext?). So that means you'd
better have it for Win, Mac, BeOS, etc, not just for dozens of Unix
variants --- and they *must* all give the same results.
There are also lesser worries about patents and US export regulations.
If we include an encryption package in the distribution we could
eliminate the portability problem, only to find ourselves facing
headaches in those departments :-(
So, by all means let's look for a solution ... but I suspect that
the cost/benefit ratio of fixing this is a lot higher than is being
claimed in some quarters.
regards, tom lane
I wrote:
> The main potential hazard I see is portability. Is crypt(3) available
> on *all* the platforms Postgres runs on?
Waitasec, what am I saying? We already *do* have crypt password
support, at least on those platforms where crypt(3) is available.
As near as I can tell, the crypt option transmits an encrypted password
across the wire (good), but the comparison at the server end is done by
taking the cleartext password stored in pg_shadow, crypt()ing it on
the fly, and comparing that to what was sent by the client.
This does have the advantage that the same pg_shadow entry will support
both cleartext-password and crypted-password connections, but we could
get that another way. Assuming that the server has crypt(), the
password could be stored always encrypted instead of always not.
Cleartext-password connections would be handled just by crypting the
received password before comparing. (Before you ask, no I don't think
we should remove the option of cleartext-password connections. What of
clients running on platforms with neither crypt() nor anything better
like Kerberos? Should they be forced to drop down to no security at
all? I think not.)
This'd take some rejiggering in (at least) CREATE USER and ALTER USER,
but it seems doable. I withdraw the complaint about portability...
regards, tom lane
[Tom Lane] | If you don't trust your dbadmin, the security of your password is | the least of your worries --- the data in your database may well | be far more critical info than anything the dbadmin could find in | your personal account. It may, and then again, it may not. There are lots of databases out there that do not contain secret or critical data. All databases I have made fall into this category. But the password I use on my PostgreSQL account is (or used to be, until I discovered the cleartext passwords) the same password I use most other places. I don't care if anyone reads the data, as long as they don't start testing my password on all other sites they may guess I have access to. I have my PostgreSQL database on an ISP on the other side of the globe. Why should I trust those people more than, say, my neighbour? | The main potential hazard I see is portability. Is crypt(3) available | on *all* the platforms Postgres runs on? Does it give the same answers | on all those platforms? If not, what shall we use instead? I implemented MD5 in Java a couple of years ago. I'm sure me or someone else will be able to convert it to C. I'll make the license anything you want it to be if you care to use it. | There are also lesser worries about patents and US export regulations. | If we include an encryption package in the distribution we could | eliminate the portability problem, only to find ourselves facing | headaches in those departments :-( AFAIK, MD5 is not restricted, as it can't be used for encryption/decryption. It is a one way hashing function only. Please correct me if I am wrong, I never understood those stupid export regulations anyway. Sverre - who really do not want _anyone_ to know his passwords. -- <URL:mailto:sverrehu@online.no> <URL:http://home.sol.no/~sverrehu/> Echelon bait: semtex, bin Laden, plutonium,North Korea, nuclear bomb
> I wrote: > > The main potential hazard I see is portability. Is crypt(3) available > > on *all* the platforms Postgres runs on? > > Waitasec, what am I saying? We already *do* have crypt password > support, at least on those platforms where crypt(3) is available. > > As near as I can tell, the crypt option transmits an encrypted password > across the wire (good), but the comparison at the server end is done by > taking the cleartext password stored in pg_shadow, crypt()ing it on > the fly, and comparing that to what was sent by the client. > > This does have the advantage that the same pg_shadow entry will support > both cleartext-password and crypted-password connections, but we could > get that another way. Assuming that the server has crypt(), the > password could be stored always encrypted instead of always not. > Cleartext-password connections would be handled just by crypting the > received password before comparing. (Before you ask, no I don't think > we should remove the option of cleartext-password connections. What of > clients running on platforms with neither crypt() nor anything better > like Kerberos? Should they be forced to drop down to no security at > all? I think not.) > > This'd take some rejiggering in (at least) CREATE USER and ALTER USER, > but it seems doable. I withdraw the complaint about portability... Yes, agreed. Doing it in the backend only is the way to go. We already have wire crypting. I think the only problem is moving dumps from on machine to another. The crypt version may not exist or be different on different machines. However, I now remember there was a bigger issue. I think the actual password has to be crypted based on the salt used supplied to the client. We can't do that based on the crypted version because we don't know the client can generate that version. Now, at the time, we were looking at Unix-style crypting of the password, which is one-way. This will not work. We need something that we can uncrypt in the backend before applying the client-supplied salt to see if the passwords match. The goal here was to make wire sniffing unproductive, and because the server supplied the salt to be used by the client, you can't just re-use a sniffed password you saw on the wire. At least this is my recollection of the problem. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Sat, 6 May 2000, Bruce Momjian wrote: > > This'd take some rejiggering in (at least) CREATE USER and ALTER USER, > > but it seems doable. I withdraw the complaint about portability... > > Yes, agreed. Doing it in the backend only is the way to go. We already > have wire crypting. > > I think the only problem is moving dumps from on machine to another. > The crypt version may not exist or be different on different machines. > > However, I now remember there was a bigger issue. I think the actual > password has to be crypted based on the salt used supplied to the > client. We can't do that based on the crypted version because we don't > know the client can generate that version. > > Now, at the time, we were looking at Unix-style crypting of the > password, which is one-way. This will not work. We need something that > we can uncrypt in the backend before applying the client-supplied salt > to see if the passwords match. > > The goal here was to make wire sniffing unproductive, and because the > server supplied the salt to be used by the client, you can't just > re-use a sniffed password you saw on the wire. > > At least this is my recollection of the problem. > > We can do it with MD5. Sverre has offered up a java version of it that he wrote, I can convert it to C and make sure it at least runs on FreeBSD, IRIX, DOS/Windows, and HPUX 8-10. If it runs in unix then it should also run in OS/2. If we roll our own we should be safe. I can even include a simple test to make sure it works for all platforms we support. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> > The goal here was to make wire sniffing unproductive, and because the > > server supplied the salt to be used by the client, you can't just > > re-use a sniffed password you saw on the wire. > > > > At least this is my recollection of the problem. > > > > > > We can do it with MD5. Sverre has offered up a java version of it > that he wrote, I can convert it to C and make sure it at least runs > on FreeBSD, IRIX, DOS/Windows, and HPUX 8-10. If it runs in unix then > it should also run in OS/2. If we roll our own we should be safe. I > can even include a simple test to make sure it works for all platforms > we support. Yes, I seem to remember that was the issue. If we only did crypting on the server, and allowed passwords to come cleartext from clients, then we only needed crypting on the server. If we crypt in a one-way fashion on the client before coming to the server using a random salt, we have to do the other part of the crypting on the client too. In other words, it is the one-way nature of the password crypt we used on the client that caused us to need the _exact_ same input string to go into that crypt on the client and server, so we would need the same crypt process in both places. Now, let me ask another, better question: Right now the password receives a random salt from the server, it uses that salt to crypt the password, then send that back for comparison with the clear-text password we store in the system. What if we:store the password in pg_shadow like a unix-style password with saltpass the random salt and the salt from pg_shadowto the clientclient crypts the password twice through the routine: once using the pg_shadow salt another timeusing the random salt and passes that back to the server. The server can use the pg_shadow copy of the password, use the random salt make a new version, and compare the result. This has the huge advantage of not requiring any new crypting methods on the client. It only requires the crypt to happen twice using two different salts. Sounds like a winner. Comments? -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Sat, 6 May 2000, Bruce Momjian wrote: > > We can do it with MD5. Sverre has offered up a java version of it > > that he wrote, I can convert it to C and make sure it at least runs > > on FreeBSD, IRIX, DOS/Windows, and HPUX 8-10. If it runs in unix then > > it should also run in OS/2. If we roll our own we should be safe. I > > can even include a simple test to make sure it works for all platforms > > we support. > > Yes, I seem to remember that was the issue. If we only did crypting on > the server, and allowed passwords to come cleartext from clients, then > we only needed crypting on the server. If we crypt in a one-way fashion > on the client before coming to the server using a random salt, we have > to do the other part of the crypting on the client too. > > In other words, it is the one-way nature of the password crypt we used > on the client that caused us to need the _exact_ same input string to > go into that crypt on the client and server, so we would need the same > crypt process in both places. > > Now, let me ask another, better question: > > Right now the password receives a random salt from the server, it uses > that salt to crypt the password, then send that back for comparison with > the clear-text password we store in the system. > > What if we: > store the password in pg_shadow like a unix-style password with salt > pass the random salt and the salt from pg_shadow to the client > client crypts the password twice through the routine: > once using the pg_shadow salt > another time using the random salt > > and passes that back to the server. The server can use the pg_shadow > copy of the password, use the random salt make a new version, and > compare the result. > > This has the huge advantage of not requiring any new crypting methods on > the client. It only requires the crypt to happen twice using two > different salts. > > Sounds like a winner. Comments? Overlycomplicated? What was your objection to MD5 again? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> > This has the huge advantage of not requiring any new crypting methods on > > the client. It only requires the crypt to happen twice using two > > different salts. > > > > Sounds like a winner. Comments? > > Overlycomplicated? > > What was your objection to MD5 again? Not really. We are using our same unix crypt code, which works on all platforms. The change to each interface is minimal. Not much testing will be required. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > Sounds like a winner. Comments? > > Overlycomplicated? > > What was your objection to MD5 again? Also, MD5 is not ideal for passwords. Seems the standard unix-style password crypting is the standard, so it should be used to crypt our own passwords in pg_shadow. I am sure someone would find some problem with us using md5 for password storage. We already use the unix-style password crypt to send passwords over the wire. Why not use it for storage too? -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Sat, 6 May 2000, Bruce Momjian wrote: > > > Sounds like a winner. Comments? > > > > Overlycomplicated? > > > > What was your objection to MD5 again? > > Also, MD5 is not ideal for passwords. Seems the standard unix-style > password crypting is the standard, so it should be used to crypt our own > passwords in pg_shadow. I am sure someone would find some problem with > us using md5 for password storage. FreeBSD uses MD5 by default since at least ver 2.2, possibly earlier. > We already use the unix-style password crypt to send passwords over the > wire. Why not use it for storage too? Can ALL clients we support use it over the wire? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> On Sat, 6 May 2000, Bruce Momjian wrote: > > > > > Sounds like a winner. Comments? > > > > > > Overlycomplicated? > > > > > > What was your objection to MD5 again? > > > > Also, MD5 is not ideal for passwords. Seems the standard unix-style > > password crypting is the standard, so it should be used to crypt our own > > passwords in pg_shadow. I am sure someone would find some problem with > > us using md5 for password storage. > > FreeBSD uses MD5 by default since at least ver 2.2, possibly earlier. Oh, I didn't know that. Interesting. > > > We already use the unix-style password crypt to send passwords over the > > wire. Why not use it for storage too? > > Can ALL clients we support use it over the wire? That is an excellent question. Any client that can use passwords has to do this, so yes, I think they all do. I can say for sure Java has it, and that is usually the hardest. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > Also, MD5 is not ideal for passwords. Seems the standard unix-style > > password crypting is the standard, so it should be used to crypt our own > > passwords in pg_shadow. I am sure someone would find some problem with > > us using md5 for password storage. > > FreeBSD uses MD5 by default since at least ver 2.2, possibly earlier. > > > We already use the unix-style password crypt to send passwords over the > > wire. Why not use it for storage too? > > Can ALL clients we support use it over the wire? Yes, I think so. Java has its own, and the others use libpq do to it. The beauty of my suggesting is that all we have to do is pass the pg_shadow salt along with the random salt, and call the crypt code twice, first with the pg_shadow salt, then with the random salt. The server pass the pg_shadow version through the random salt crypt, and compares. Now, I we want to move all the stuff to use MD5 rather than the standard unix password crypt, that is another option, though I am not sure what value it would have. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
[Bruce Momjian] | store the password in pg_shadow like a unix-style password with salt | pass the random salt and the salt from pg_shadow to the client | client crypts the password twice through the routine: | once using the pg_shadow salt | another time using the random salt That's close to what I thought of a couple of days ago too, except I would have used MD5, since I already have that implemented. :) (It seems you already have crypt, so you wouldn't need MD5.) Does anyone here really _know_ (and I mean KNOW) security/cryptography? If so, could you please comment on this scheme? And while you're at it, whats better of MD5 and Unix crypt (triple DES ++, isn't it?) from a security perspective? Sverre. -- <URL:mailto:sverrehu@online.no> <URL:http://home.sol.no/~sverrehu/> Echelon bait: semtex, bin Laden, plutonium,North Korea, nuclear bomb
On Sat, 6 May 2000, Bruce Momjian wrote: > > > Also, MD5 is not ideal for passwords. Seems the standard unix-style > > > password crypting is the standard, so it should be used to crypt our own > > > passwords in pg_shadow. I am sure someone would find some problem with > > > us using md5 for password storage. > > > > FreeBSD uses MD5 by default since at least ver 2.2, possibly earlier. > > > > > We already use the unix-style password crypt to send passwords over the > > > wire. Why not use it for storage too? > > > > Can ALL clients we support use it over the wire? > > Yes, I think so. Java has its own, and the others use libpq do to it. > The beauty of my suggesting is that all we have to do is pass the > pg_shadow salt along with the random salt, and call the crypt code > twice, first with the pg_shadow salt, then with the random salt. > > The server pass the pg_shadow version through the random salt crypt, and > compares. > > Now, I we want to move all the stuff to use MD5 rather than the standard > unix password crypt, that is another option, though I am not sure what > value it would have. > > How about ODBC? This is from the ODBC driver source connection.c: self->errormsg = "Passwordcrypt authentication not supported"; Is that because of the platform it's running on or what it's talking to? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Re: You're on SecurityFocus.com for the cleartext passwords.
From
teg@redhat.com (Trond Eivind Glomsrød)
Date:
Vince Vielhaber <vev@michvhf.com> writes: > FreeBSD uses MD5 by default since at least ver 2.2, possibly > earlier. So does Red Hat Linux, and probably Linux distributions as well. -- Trond Eivind Glomsrød Red Hat, Inc.
> > Now, I we want to move all the stuff to use MD5 rather than the standard > > unix password crypt, that is another option, though I am not sure what > > value it would have. > > > > > > How about ODBC? This is from the ODBC driver source connection.c: > > self->errormsg = "Password crypt authentication not supported"; > > Is that because of the platform it's running on or what it's talking > to? Seems we don't have crypt support, so you can't send crypt passwords from an ODBC client. That is news to me. From looking there, and looking at pg_hba.conf, we have both 'password' and 'crypt' authentication in there. However, this is not a problem because we can still do backend-only crypting when comparing client-sent cleartext passwords to pg_shadow passwords. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Sat, 6 May 2000, Bruce Momjian wrote: > > > Now, I we want to move all the stuff to use MD5 rather than the standard > > > unix password crypt, that is another option, though I am not sure what > > > value it would have. > > > > > > > > > > How about ODBC? This is from the ODBC driver source connection.c: > > > > self->errormsg = "Password crypt authentication not supported"; > > > > Is that because of the platform it's running on or what it's talking > > to? > > Seems we don't have crypt support, so you can't send crypt passwords > from an ODBC client. That is news to me. > > >From looking there, and looking at pg_hba.conf, we have both 'password' > and 'crypt' authentication in there. > > However, this is not a problem because we can still do backend-only > crypting when comparing client-sent cleartext passwords to pg_shadow > passwords. But what I'm proposing will let ALL clients send an encrypted password over the wire and we can also store them encrypted. By comparing twice we can maintain backward compatibility. The backend would compare the password received with the stored md5 password and compare the received password after md5ing it in case it was sent clear-text. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
on 5/6/00 12:45 PM, Sverre H. Huseby at sverrehu@online.no wrote: > Does anyone here really _know_ (and I mean KNOW) > security/cryptography? If so, could you please comment on this > scheme? And while you're at it, whats better of MD5 and Unix crypt > (triple DES ++, isn't it?) from a security perspective? Finally something I can comment on with a tiny bit of authority :) The unix crypt command is a sneaky version of DES (I've never heard of Triple-DES being used for this). Your password is transformed into a DES key which is then used to encrypt a block of 0's. The result is what's stored in the password file. Poor Man's Hash, in a sense :) MD5 is quite standard (as hashing algs go) and much more secure. It allows for longer passwords, and it's quite fast (easily tens of thousands of MD5 hashes per second on today's midlevel processors). I strongly recommend you use that. | store the password in pg_shadow like a unix-style password with salt | pass the random salt and the salt from pg_shadow to the client | client crypts the password twice through the routine: | once using the pg_shadow salt | another time using the random salt My first impression of this scheme is that it's quite good. Use MD5 instead of crypt, and it's great. You've got a good challenge-response setup here, and with MD5 you can even make your salt much longer than the 2 bytes of unix crypt salt, thus much more secure. I like it! -Ben
> But what I'm proposing will let ALL clients send an encrypted password > over the wire and we can also store them encrypted. By comparing twice > we can maintain backward compatibility. The backend would compare the > password received with the stored md5 password and compare the received > password after md5ing it in case it was sent clear-text. But you can do that with our current system. Store them in pg_shadow using unix password format. If a cleartext password comes in, crypt it using the pg_shadow salt and compare them. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Sat, 6 May 2000, Bruce Momjian wrote: > > But what I'm proposing will let ALL clients send an encrypted password > > over the wire and we can also store them encrypted. By comparing twice > > we can maintain backward compatibility. The backend would compare the > > password received with the stored md5 password and compare the received > > password after md5ing it in case it was sent clear-text. > > But you can do that with our current system. Store them in pg_shadow > using unix password format. If a cleartext password comes in, crypt it > using the pg_shadow salt and compare them. You missed half of it. Platforms that don't have crypt would use our MD5 so eventually all of them would be sending encrypted passwords over the wire. I'm trying to accomplish two things here. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> on 5/6/00 12:45 PM, Sverre H. Huseby at sverrehu@online.no wrote: > > > Does anyone here really _know_ (and I mean KNOW) > > security/cryptography? If so, could you please comment on this > > scheme? And while you're at it, whats better of MD5 and Unix crypt > > (triple DES ++, isn't it?) from a security perspective? > > Finally something I can comment on with a tiny bit of authority :) > > The unix crypt command is a sneaky version of DES (I've never heard of > Triple-DES being used for this). Your password is transformed into a DES key > which is then used to encrypt a block of 0's. The result is what's stored in > the password file. Poor Man's Hash, in a sense :) > > MD5 is quite standard (as hashing algs go) and much more secure. It allows > for longer passwords, and it's quite fast (easily tens of thousands of MD5 > hashes per second on today's midlevel processors). I strongly recommend you > use that. > > | store the password in pg_shadow like a unix-style password with salt > | pass the random salt and the salt from pg_shadow to the client > | client crypts the password twice through the routine: > | once using the pg_shadow salt > | another time using the random salt > > My first impression of this scheme is that it's quite good. Use MD5 instead > of crypt, and it's great. You've got a good challenge-response setup here, > and with MD5 you can even make your salt much longer than the 2 bytes of > unix crypt salt, thus much more secure. > > I like it! > Good. I only recommend our current setup because we already have code in most interfaces to handle it. I have no problem moving to md5, but this should be done for _all_ crypting. I just see no reason to mix standard password crypt with md5 and try to keep two crypts working on all interfaces. The easy way would be to use our current crypt stuff to get it working, then move to md5 if we can get it working on all our interfaces. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>>> The goal here was to make wire sniffing unproductive, and because the
>>>> server supplied the salt to be used by the client, you can't just
>>>> re-use a sniffed password you saw on the wire.
Good point. Are we trying to make the password challenge proof against
wire sniffing? I think that might be an unreasonable goal. People who
are concerned about sniffing attacks ought to be using something like
SSL to encrypt the *entire* connection (and/or a better auth protocol
than passwords, in the first place...). I repeat my prior comment that
the data in the database is likely to be just as valuable as the
password.
> Right now the client receives a random salt from the server, it uses
> that salt to crypt the password, then send that back for comparison with
> the clear-text password we store in the system.
> What if we:
> store the password in pg_shadow like a unix-style password with salt
> pass the random salt and the salt from pg_shadow to the client
> client crypts the password twice through the routine:
> once using the pg_shadow salt
> another time using the random salt
> and passes that back to the server. The server can use the pg_shadow
> copy of the password, use the random salt make a new version, and
> compare the result.
Use the random salt to make a new version of what, exactly? If the
server doesn't have the cleartext password, it can't make a crypted
password that will correspond to any randomly chosen salt either.
> This has the huge advantage of not requiring any new crypting methods on
> the client. It only requires the crypt to happen twice using two
> different salts.
A serious objection to both this and the MD5 proposal is that it'd
create a cross-version incompatibility between clients and servers.
We were just fending off complaints about 6.5-to-7.0 incompatibilities
that were considerably less serious than being unable to connect at all,
so how well do you think this'd go over?
I think we should try to stick to the current protocol: one salt sent
by the server, one crypted password sent back. The costs of changing
the protocol will probably outweigh any real-world security gain.
We could get some of the benefits of a random salt if we were willing
to enlarge the pg_shadow entry a little bit. Suppose that we allow
N different salt values to be sent by the server (crypt(3) only allows
4096 possible salts anyway, but I'm thinking N in the range of 100).
When a password is set, crypt the password with each of these and store
*all* the results in pg_shadow. Then we have the right crypted password
available to compare to the client response, and an attacker still has
a relatively low probability of having sniffed the right password.
BTW, I hear "MD5" being chanted like a mantra, but someone will have
to explain to me what it does that avoids the sniffed-crypted-password
problem...
regards, tom lane
> On Sat, 6 May 2000, Bruce Momjian wrote: > > > > But what I'm proposing will let ALL clients send an encrypted password > > > over the wire and we can also store them encrypted. By comparing twice > > > we can maintain backward compatibility. The backend would compare the > > > password received with the stored md5 password and compare the received > > > password after md5ing it in case it was sent clear-text. > > > > But you can do that with our current system. Store them in pg_shadow > > using unix password format. If a cleartext password comes in, crypt it > > using the pg_shadow salt and compare them. > > You missed half of it. Platforms that don't have crypt would use our > MD5 so eventually all of them would be sending encrypted passwords > over the wire. I'm trying to accomplish two things here. That is fine: We need crypted passwords in pg_shadow, and MD5 is probably better than our current setup. But we have tons of interfaces, all of which use the old stuff. If you think you can do both at the same time, go ahead. MD5 has salt capability, so you can move it right into our current client dialog setup, and do double-MD5 as I suggested. You still need double-MD5 because you have to crypt the password based on the random salt passed to the client by the server. If you can make the salt larger than 2 bytes at the same time, so much the better. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
I said:
> I think we should try to stick to the current protocol: one salt sent
> by the server, one crypted password sent back. The costs of changing
> the protocol will probably outweigh any real-world security gain.
Actually, since libpq handles the authentication phase of connection
via a state-machine, it'd be possible for the postmaster to send two
successive authentication challenge packets with different salts, and
libpq would respond correctly to each one. This is a little bit shaky
because the current protocol document does not say that clients should
loop at the challenge point of the protocol, so there might be non-libpq
clients that wouldn't cope. But it's possible we could do it without
breaking compatibility with old clients.
However, I still fail to see what it buys us to challenge the frontend
with two salts. If the password is stored crypted, the *only* thing
we can validate is that password with the same salt it was stored
with. It doesn't sound like MD5 changes this at all.
regards, tom lane
on 5/6/00 2:14 PM, Tom Lane at tgl@sss.pgh.pa.us wrote: > However, I still fail to see what it buys us to challenge the frontend > with two salts. If the password is stored crypted, the *only* thing > we can validate is that password with the same salt it was stored > with. It doesn't sound like MD5 changes this at all. The MD5 definitely doesn't change anything except overall security strength of the algorithm. The additional random salt prevents someone from sniffing the communication between client and server and then simply log in by sending the known hash of the password. The challenge-response means that sniffing one login doesn't allow you to fake the next one. -Ben
On Sat, 06 May 2000, Trond Eivind Glomsr�d wrote: > Vince Vielhaber <vev@michvhf.com> writes: > > > FreeBSD uses MD5 by default since at least ver 2.2, possibly > > earlier. > > So does Red Hat Linux, and probably Linux distributions as well. > > -- > Trond Eivind Glomsr�d > Red Hat, Inc. There is some good information about crypt and MD5 at www.php.net in the documentation: String Functions/crypt http://www.php.net/manual/function.crypt.php It explains that many systems have updated crypt() to use MD5 and how to check what hash algorithm your system's crypt() actually uses. -- Robert B. Easter reaster@comptechnews.com
Benjamin Adida <ben@mit.edu> writes:
>> It doesn't sound like MD5 changes this at all.
> The MD5 definitely doesn't change anything except overall security strength
> of the algorithm.
OK, understood. So it seems that switching to MD5 would offer (a) more
portability to platforms without crypt(3), and (b) better security,
at the costs of (a) implementation effort and (b) cross-version
compatibility problems. We probably ought to keep that discussion
separate from the one about how the challenge protocol works.
> The additional random salt prevents someone from sniffing
> the communication between client and server and then simply log in by
> sending the known hash of the password. The challenge-response means that
> sniffing one login doesn't allow you to fake the next one.
How so? The server sends out one fixed salt (the one stored for that
user's password in pg_shadow) and one randomly-chosen salt. The client
sends back two crypted passwords. The server can check one of them.
What can it do with the other? Nothing that I can see, so where is the
security gain? A sniffer can still get in by sending back the same
pair of crypted passwords next time, no matter what random salt is
presented.
regards, tom lane
on 5/6/00 2:29 PM, Tom Lane at tgl@sss.pgh.pa.us wrote: > How so? The server sends out one fixed salt (the one stored for that > user's password in pg_shadow) and one randomly-chosen salt. The client > sends back two crypted passwords. The server can check one of them. > What can it do with the other? Nothing that I can see, so where is the > security gain? A sniffer can still get in by sending back the same > pair of crypted passwords next time, no matter what random salt is > presented. Okay, my understanding was that the protocol would work as follows: - client requests login - server sends stored salt c1, and random salt c2. - client performs hash_c2(hash_c1(password)) and sends result to server. - server performs hash_c2(stored_pg_shadow) and compares with client submission. - if there's a match, there's successful login. This protocol will truly create a challenge-response where the communication is different at each login, and where sniffing one hash_c2(hash_c1(password)) doesn't give you any way to log in with a different c2. -Ben
On Sat, 6 May 2000, Tom Lane wrote: > Benjamin Adida <ben@mit.edu> writes: > >> It doesn't sound like MD5 changes this at all. > > > The MD5 definitely doesn't change anything except overall security strength > > of the algorithm. > > OK, understood. So it seems that switching to MD5 would offer (a) more > portability to platforms without crypt(3), and (b) better security, > at the costs of (a) implementation effort and (b) cross-version > compatibility problems. We probably ought to keep that discussion > separate from the one about how the challenge protocol works. I agree. > > The additional random salt prevents someone from sniffing > > the communication between client and server and then simply log in by > > sending the known hash of the password. The challenge-response means that > > sniffing one login doesn't allow you to fake the next one. > > How so? The server sends out one fixed salt (the one stored for that > user's password in pg_shadow) and one randomly-chosen salt. The client > sends back two crypted passwords. The server can check one of them. > What can it do with the other? Nothing that I can see, so where is the > security gain? A sniffer can still get in by sending back the same > pair of crypted passwords next time, no matter what random salt is > presented. Off hand here is the only way I can see that this can work. 1) client gets password from user and md5's it. 2) upon connecting, the client receives a random salt from the server. 3) the client md5's the already md5'd password with this new salt. 4) the client sends the resulting hash to the server. 5) the server takes the md5'd password from pg_shadow and md5's it with the same random salt it sent to the client. 6) if it matches, the server sends yet another salt to the client. 7) repeat steps 3, 4 and 5. 8) if it matches the client's in. Why should this work? Because the next time the client tries to connect it will be given a different salt. But why twice? It seems that once would be enough since it's a random salt to begin with and the client should never be getting that salt twice. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
on 5/6/00 2:40 PM, Vince Vielhaber at vev@michvhf.com wrote: > Why should this work? Because the next time the client tries to connect > it will be given a different salt. But why twice? It seems that once > would be enough since it's a random salt to begin with and the client > should never be getting that salt twice. No, the reason why you would have "two" hashes is so that the server doesn't have to store the cleartext password. The server stores an already-hashed version of the password, so the client must hash the cleartext twice, once with a long-term salt, once with a random, one-time salt. -Ben
Benjamin Adida <ben@mit.edu> writes:
> Okay, my understanding was that the protocol would work as follows:
> - client requests login
> - server sends stored salt c1, and random salt c2.
> - client performs hash_c2(hash_c1(password)) and sends result to server.
> - server performs hash_c2(stored_pg_shadow) and compares with client
> submission.
> - if there's a match, there's successful login.
Oh, now I see. OK, that looks like it would work. It would definitely
mean a change of algorithm on the client side.
Probably the way to attack this would be to combine MD5 and this double
password-munging algorithm as a new authentication protocol type to add
to the ones we already support. That way old clients don't have to be
updated instantly.
OTOH, if the password stored in pg_shadow is MD5-encrypted, then we lose
the ability to support the old crypt-based auth method, don't we?
Old clients could be successfully authenticated with cleartext password
challenge (server MD5's the transmitted password and compares to
pg_shadow), but we couldn't do anything with a crypt()-encrypted
password. Is that enough reason to stay with crypt() as the underlying
hashing engine? Maybe not, but we gotta consider the tradeoffs...
regards, tom lane
> Okay, my understanding was that the protocol would work as follows: > > - client requests login > - server sends stored salt c1, and random salt c2. > - client performs hash_c2(hash_c1(password)) and sends result to server. > - server performs hash_c2(stored_pg_shadow) and compares with client > submission. > - if there's a match, there's successful login. > > This protocol will truly create a challenge-response where the communication > is different at each login, and where sniffing one > hash_c2(hash_c1(password)) doesn't give you any way to log in with a > different c2. Yes. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > The additional random salt prevents someone from sniffing > > the communication between client and server and then simply log in by > > sending the known hash of the password. The challenge-response means that > > sniffing one login doesn't allow you to fake the next one. > > How so? The server sends out one fixed salt (the one stored for that > user's password in pg_shadow) and one randomly-chosen salt. The client > sends back two crypted passwords. The server can check one of them. > What can it do with the other? Nothing that I can see, so where is the > security gain? A sniffer can still get in by sending back the same > pair of crypted passwords next time, no matter what random salt is > presented. No, you crypt the user-supplied password twice. 'fred' -> crypt with fixed -> crypt with random Server does: pg_shadow password -> crypt with random Then check to see they match. Does that help? -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Let me comment: > > How so? The server sends out one fixed salt (the one stored for that > > user's password in pg_shadow) and one randomly-chosen salt. The client > > sends back two crypted passwords. The server can check one of them. > > What can it do with the other? Nothing that I can see, so where is the > > security gain? A sniffer can still get in by sending back the same > > pair of crypted passwords next time, no matter what random salt is > > presented. > > Off hand here is the only way I can see that this can work. > > 1) client gets password from user and md5's it. No, no md5 yet. > 2) upon connecting, the client receives a random salt from the server. > 3) the client md5's the already md5'd password with this new salt. md5's plaintext password using pg_shadow salt, and random salt. > 4) the client sends the resulting hash to the server. > 5) the server takes the md5'd password from pg_shadow and md5's it > with the same random salt it sent to the client. Yes. > 6) if it matches, the server sends yet another salt to the client. > 7) repeat steps 3, 4 and 5. > 8) if it matches the client's in. > > Why should this work? Because the next time the client tries to connect > it will be given a different salt. But why twice? It seems that once > would be enough since it's a random salt to begin with and the client > should never be getting that salt twice. No, once with pg_shadow salt, then random salt. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> on 5/6/00 2:40 PM, Vince Vielhaber at vev@michvhf.com wrote: > > > Why should this work? Because the next time the client tries to connect > > it will be given a different salt. But why twice? It seems that once > > would be enough since it's a random salt to begin with and the client > > should never be getting that salt twice. > > No, the reason why you would have "two" hashes is so that the server doesn't > have to store the cleartext password. The server stores an already-hashed > version of the password, so the client must hash the cleartext twice, once > with a long-term salt, once with a random, one-time salt. > Yeah, right! -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Probably the way to attack this would be to combine MD5 and this double > password-munging algorithm as a new authentication protocol type to add > to the ones we already support. That way old clients don't have to be > updated instantly. Not sure that will work because once we use md5 on the server side for pg_shadow, we have to be able to do md5 on the client, I think, for crypting because the md5 has to be done _before_ the random salt crypt. > > OTOH, if the password stored in pg_shadow is MD5-encrypted, then we lose > the ability to support the old crypt-based auth method, don't we? Yes. > Old clients could be successfully authenticated with cleartext password > challenge (server MD5's the transmitted password and compares to > pg_shadow), but we couldn't do anything with a crypt()-encrypted > password. Is that enough reason to stay with crypt() as the underlying > hashing engine? Maybe not, but we gotta consider the tradeoffs... Not sure. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
"Robert B. Easter" <reaster@comptechnews.com> writes: > http://www.php.net/manual/function.crypt.php > It explains that many systems have updated crypt() to use MD5 and how to > check what hash algorithm your system's crypt() actually uses. Oh, that's interesting. If that's correct, we *already* have a cross- platform compatibility problem: a client compiled on a machine with DES-derived crypt() will be unable to authenticate itself under "crypt" protocol to a server using MD5-based crypt(), or vice versa, because the wrong hashed password will be sent. Can someone with access to two such machines check this? If that's true, it seriously weakens the backwards-compatibility argument for sticking with crypt(), IMHO. Old clients on another platform may already fail to talk to your server... regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Probably the way to attack this would be to combine MD5 and this double
>> password-munging algorithm as a new authentication protocol type to add
>> to the ones we already support. That way old clients don't have to be
>> updated instantly.
> Not sure that will work because once we use md5 on the server side for
> pg_shadow, we have to be able to do md5 on the client, I think, for
> crypting because the md5 has to be done _before_ the random salt crypt.
We can still support old clients under the cleartext-password protocol:
client sends password in clear, server MD5's it using salt from
pg_shadow and compares result. This is vulnerable to sniffing but no
more so than it was before. What we would lose is backwards
compatibility to the crypt-password protocol. We should still choose
a new Authentication typecode for the MD5/double-hash protocol, just to
make sure no one gets confused about which protocol is being requested.
If these reports are correct that some platforms already have MD5, not
DES, inside crypt(3) then I'm definitely leaning towards going with MD5.
The best reason to stick with crypt as the hash engine would be to
preserve support for the existing crypt-based protocol, but if that's
already broken cross-platform then the value of continuing to support it
looks pretty dubious. (After all, the clients on your own box are
probably getting updated at the same time as the server --- it's clients
on other boxes that you're really worried about backwards compatibility
for.)
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I think the only problem is moving dumps from on machine to another.
> The crypt version may not exist or be different on different machines.
This is something I was going to bring up, but I see Bruce already did.
How will dump/restore and upgrades cope with crypted passwords?
If we standardize on MD5 encryption then there shouldn't be a cross-
platform problem with incompatible hashes, but we've still got troubles.
Currently, pg_dumpall handles saving and loading of pg_shadow as a
simple table COPY operation. That'd work OK once you have the passwords
stored in MD5-encrypted form, but it will surely not work for upgrading
from 7.0 to 7.1 (assume 7.1 is when we'll have this stuff ready).
I've never cared for dumping pg_shadow that way anyway, since it makes
cross-version changes in the format of pg_shadow nearly impossible;
this password storage issue is just one case of a larger problem. What
pg_dumpall should really be doing is emitting CREATE USER commands to
reload the contents of pg_shadow.
To do it that way, we'd need two variants of CREATE USER:
CREATE USER ... WITH PASSWORD 'foo'
(the existing syntax). 'foo' is cleartext and it gets hashed on its
way into the table. The hashing step includes choosing a random salt.
CREATE USER ... WITH ENCRYPTED PASSWORD 'bar'
Here 'bar' is the already-encrypted password form (with salt value
embedded); it'd be dropped into pg_shadow unchanged, although the
command ought to do whatever it can to check the validity of the
encryption format.
pg_dumpall would generate this second form, inserting the crypted
password it had read from the pg_shadow table being dumped.
(Probably, there should be an ALTER USER SET ENCRYPTED PASSWORD as
well, for transferring already-crypted passwords, but that's not
essential for the purpose at hand.)
That solves our problem going forward, but we're still stuck for
how to get 7.0 password data into 7.1. One possible avenue is to make
sure that it is possible to distinguish whether an existing database
contains crypted or cleartext passwords (maybe this comes for free,
or maybe we have to change the name of the pg_shadow password column
or some such). Then pg_dumpall could be made to dump out either
WITH PASSWORD 'foo' or WITH ENCRYPTED PASSWORD 'foo' depending on
whether it sees that it is reading cleartext or crypted passwords
from the source database. Then we tell people that they have to
use 7.1's pg_dumpall to dump a 7.0 database in preparation for
updating to 7.1, or else expect to have to reset all their passwords.
Is there a better way?
regards, tom lane
Vince Vielhaber <vev@michvhf.com> writes:
> How about ODBC? This is from the ODBC driver source connection.c:
> self->errormsg = "Password crypt authentication not supported";
> Is that because of the platform it's running on or what it's talking
> to?
I think the ODBC authors didn't want to assume that libcrypt() is
available on the client side (which is probably right for Windows and
Mac at least). Standardizing on our own implementation of MD5 would
sidestep that problem quite neatly.
Depending on libcrypt is pretty painful even in Unix environments;
have you seen what we have to do to get it to work in shared-library
contexts, on machines where libcrypt is a separate shlib and not part of
libc? Yech. We could get rid of a bunch of cruft in the makefiles by
abandoning crypt() ...
regards, tom lane
> Depending on libcrypt is pretty painful even in Unix environments; > have you seen what we have to do to get it to work in shared-library > contexts, on machines where libcrypt is a separate shlib and not part of > libc? Yech. We could get rid of a bunch of cruft in the makefiles by > abandoning crypt() ... Agreed. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> Probably the way to attack this would be to combine MD5 and this double > >> password-munging algorithm as a new authentication protocol type to add > >> to the ones we already support. That way old clients don't have to be > >> updated instantly. > > > Not sure that will work because once we use md5 on the server side for > > pg_shadow, we have to be able to do md5 on the client, I think, for > > crypting because the md5 has to be done _before_ the random salt crypt. > > We can still support old clients under the cleartext-password protocol: > client sends password in clear, server MD5's it using salt from > pg_shadow and compares result. This is vulnerable to sniffing but no > more so than it was before. What we would lose is backwards > compatibility to the crypt-password protocol. We should still choose > a new Authentication typecode for the MD5/double-hash protocol, just to > make sure no one gets confused about which protocol is being requested. Yes, got it. I was confused. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I think the only problem is moving dumps from on machine to another. > > The crypt version may not exist or be different on different machines. > > This is something I was going to bring up, but I see Bruce already did. > How will dump/restore and upgrades cope with crypted passwords? > > If we standardize on MD5 encryption then there shouldn't be a cross- > platform problem with incompatible hashes, but we've still got troubles. > > Currently, pg_dumpall handles saving and loading of pg_shadow as a > simple table COPY operation. That'd work OK once you have the passwords > stored in MD5-encrypted form, but it will surely not work for upgrading > from 7.0 to 7.1 (assume 7.1 is when we'll have this stuff ready). > > I've never cared for dumping pg_shadow that way anyway, since it makes > cross-version changes in the format of pg_shadow nearly impossible; > this password storage issue is just one case of a larger problem. What > pg_dumpall should really be doing is emitting CREATE USER commands to > reload the contents of pg_shadow. Hey, pg_dumpall is only a shell script. It does what it can. :-) > > To do it that way, we'd need two variants of CREATE USER: > > CREATE USER ... WITH PASSWORD 'foo' > > (the existing syntax). 'foo' is cleartext and it gets hashed on its > way into the table. The hashing step includes choosing a random salt. > > CREATE USER ... WITH ENCRYPTED PASSWORD 'bar' > > Here 'bar' is the already-encrypted password form (with salt value > embedded); it'd be dropped into pg_shadow unchanged, although the > command ought to do whatever it can to check the validity of the > encryption format. > > pg_dumpall would generate this second form, inserting the crypted > password it had read from the pg_shadow table being dumped. > > (Probably, there should be an ALTER USER SET ENCRYPTED PASSWORD as > well, for transferring already-crypted passwords, but that's not > essential for the purpose at hand.) > > That solves our problem going forward, but we're still stuck for > how to get 7.0 password data into 7.1. One possible avenue is to make > sure that it is possible to distinguish whether an existing database > contains crypted or cleartext passwords (maybe this comes for free, > or maybe we have to change the name of the pg_shadow password column > or some such). Then pg_dumpall could be made to dump out either > WITH PASSWORD 'foo' or WITH ENCRYPTED PASSWORD 'foo' depending on > whether it sees that it is reading cleartext or crypted passwords > from the source database. Then we tell people that they have to > use 7.1's pg_dumpall to dump a 7.0 database in preparation for > updating to 7.1, or else expect to have to reset all their passwords. > > Is there a better way? If we add this WITH PASSWORD 'foo' to 7.0.X, then 7.1 can read that format, know it is in cleartext, hash it, and load it in. 7.1 can dump its table out as WITH ENCRYPTED PASSWORD 'foo'. With 6.5.X and earlier, we can just tell people they have to manually update them. We can emit a warning if the pg_shadow password field does contain an md5 format password. Another idea is to add code to 7.1 to convert non-md5 shadow password fields to md5 format. Since we already have special handling to do pg_pwd, we could do it there. Seems like a plan. MD5 format is all hex digits of a specific length. No way to get that confused with a real password. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote:
>
> Now, I we want to move all the stuff to use MD5 rather than the standard
> unix password crypt,
AFAIK, MD5 is one of "the standard password crypt"'s ;)
> that is another option, though I am not sure what
> value it would have.
One advantage would be passwords with more than 8 characters that
matter.
IMO the salt part in the "old" crypt code is there only to make it
harder for people to accidentally discover that other people have
the same password with them, which could easily be avoided by
including the username as kind of supersalt in the md5 string,
so the value passed over wire (and stored in DB would be
MD5('<username>:<passwd>').
If we want to make password hijacking real hard, we could store
the above but ask the client for
MD5(<server-supplied-salt>+MD5(<username>+':'+<passwd>))
and compare that
-------------
Hannu
Would public/private key pair authentication (like GPG) or SSL-like solutions work? If the backend could use SSL, it would have the ability to protect passwords and all data too from being seen on the network. Somekind of SSL ability would solve all security problems. Can't OpenSSL be used on top of the client/backend connection? This way, the backend/database could just store hashed passwords anyway it wants and the client only needs to support the SSL-like layer in the connection. I guess this would mean adding SSL into the libraries (libpq etc) for the functions that make the backend connection. It would be nice if after user authentication, that the protocol could optionally renegotiate back to an unencrypted connection for speed. A security option could be added to databases that allows the DBA to specify whether or not access to the database requires a secure connection to protect the sensitive info. I'm probably not understanding everything here, but if system crypt() is used, it looks like you have to go with the least common denominator algorithm that is on all platforms, which might be the old 2-byte salt DES. But if you embed all this in the libpq etc, then you use whatever you want. Also, isn't the salt the first x bytes of the hashed string, x depending on which algorithm used? Wouldn't things work like this: 1. Server sends the first 2 (or x bytes) of the hashed password (e.g., the salt used to make the hashed password. 2. The client hashes the password with the salt and sends it back to the server. 3. The server compares what the client sent with the hash it has stored. If they match the user is let in. I didn't think there was any need for this random salt and double hashing thats been discussed. If you have to implement something into the backend and the client libraries, why not go for an SSL type solution? (people might say, it sounds fine, why don't YOU do it :) Robert Easter
on 5/6/00 3:18 PM, Robert B. Easter at reaster@comptechnews.com wrote: > > Would public/private key pair authentication (like GPG) or SSL-like solutions > work? If the backend could use SSL, it would have the ability to protect > passwords and all data too from being seen on the network. Somekind of SSL > ability would solve all security problems. Can't OpenSSL be used on top of > the > client/backend connection? While SSL could probably be an option for people dealing with tremendously sensitive data that shouldn't go in the clear over their internal network (we're not talking about passwords here, just the SQL queries and responses), I think it's overkill to impose SSL for everything. The key exchange and constant encryption overhead would significantly affect performance, so this doesn't seem like something to impose on everyone. -Ben
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Another idea is to add code to 7.1 to convert non-md5 shadow password
> fields to md5 format. Since we already have special handling to do
> pg_pwd, we could do it there. Seems like a plan. MD5 format is all
> hex digits of a specific length. No way to get that confused with a
> real password.
Well, if you're willing to depend on that, then there's no need for the
WITH ENCRYPTED PASSWORD variant syntax: the existing syntax WITH
PASSWORD could do it all, just by checking to see if the supplied
password string looks like it's already been md5-ified.
The real trick would be to get this to happen during a COPY into
pg_shadow --- if we did that, then dumps generated by 7.0 pg_dumpall
would still work. Perhaps a trigger on pg_shadow insert/update is
the right place to check and md5-ify the password? (If that's in place
then neither CREATE nor ALTER USER would need to do anything special!)
regards, tom lane
"Robert B. Easter" <reaster@comptechnews.com> writes:
> Would public/private key pair authentication (like GPG) or SSL-like solutions
> work?
We already have SSL support --- that's why I wasn't especially excited
about making the password challenge itself be proof against sniffing.
Anybody who's afraid of sniffing attacks ought to be SSL-ifying his
entire database connection, not just trying to protect the password.
regards, tom lane
Benjamin Adida <ben@mit.edu> writes:
> I think it's overkill to impose SSL for everything.
Agreed, and in any case we are not going to require people to install
SSL before they can use Postgres. It's an appropriate tool for some
people to use depending on what their security situation is.
I think we are converging on a plan that involves switching from crypt
to MD5 as our password-hashing algorithm, so given that we are going to
need a client upgrade anyway, we can throw in the double hashing (two
salt) method you proposed without any extra pain. Might as well protect
the password against sniffing if we can...
regards, tom lane
On Sat, 06 May 2000, Benjamin Adida wrote: > While SSL could probably be an option for people dealing with tremendously > sensitive data that shouldn't go in the clear over their internal network > (we're not talking about passwords here, just the SQL queries and > responses), I think it's overkill to impose SSL for everything. > > The key exchange and constant encryption overhead would significantly affect > performance, so this doesn't seem like something to impose on everyone. > > -Ben I agree that it should not be active all the time. Just active for databases that have been setup to require it if the dba sets the option for it. My idea is that it would work like this: 1. Client connects to server. The initial connection is automatically SSL. 2. The user is authenticated. 3. The client and server renegotiate the connection to drop out of SSL and to a normal unencrpyted connection by default. However, if the database has been set to require a secure connection by the database owner, then the SSL connection will remain. This adds some overhead to connecting to the server, but when people need performance, they use persistent connections. The dba would have to set the database to require the SSL connection to remain by running commands something like: CREATE DATABASE mydb SECURE; -- creates it initially secure. ALTER DATABASE mydb ADD|DROP SECURE; -- alters the secure option. (some proposed Postgres extensions:) OpenSSL is under the BSD license (www.openssl.org). Its source code can be integrated into the PostgreSQL source code so that users need know nothing about it. It would just get used internal to Postgres and the client libraries. OpenSSL also contains an MD5 routine that can be used on the passwords. So far, no one is excited about this so I will not push it anymore. -- Robert B. Easter reaster@comptechnews.com
On Sat, 6 May 2000, Robert B. Easter wrote:
> OpenSSL is under the BSD license (www.openssl.org). Its source code can be
> integrated into the PostgreSQL source code so that users need know nothing
> about it. It would just get used internal to Postgres and the client
> libraries.
Please do not 'integrate' code from OpenSSL into the tree. Its huge (2M
compressed source tree).
Negotiating security protocols and reconnecting seems like a hassle, just
having autoconf detect presence of openssl libraries (automatically or
--with-openssl) is perfect. The best (as in, simplest and most
transparent) way to integrate SSL support is to do it like http/https:
provide another port on which connections will be only accepted using SSL
protocol. Security-minded administrators should have an option of
disabling non-encrypted port. On client side, use fairly simple (to my
memory, you use {tls|ssl}_connect instead of connect)
A flag for databases that would disallow their usage if the connection is
unencrypted would be nice though, for those people who wish to have both
encrypted and unencrypted connections.
> OpenSSL also contains an MD5 routine that can be used on the passwords.
MD5 is extremely simple, about 50 lines of code.
-alex
So we're in agreement on using MD5. Sverre, is the offer still open for the java MD5 you wrote? I'll translate it to C and make sure it will compile/run/give-correct-results on as many platforms as possible including DOS/Windows, hpux, FreeBSD and IRIX. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> OpenSSL is under the BSD license (www.openssl.org). Its source code can be > integrated into the PostgreSQL source code so that users need know nothing > about it. It would just get used internal to Postgres and the client > libraries. > > OpenSSL also contains an MD5 routine that can be used on the passwords. > > So far, no one is excited about this so I will not push it anymore. Seems like that could be a solution, but we are trying not to bloat the PostgreSQL tarball. Shipping SSH would certainly do that. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Benjamin Adida <ben@mit.edu> writes: > > I think it's overkill to impose SSL for everything. > > Agreed, and in any case we are not going to require people to install > SSL before they can use Postgres. It's an appropriate tool for some > people to use depending on what their security situation is. > > I think we are converging on a plan that involves switching from crypt > to MD5 as our password-hashing algorithm, so given that we are going to > need a client upgrade anyway, we can throw in the double hashing (two > salt) method you proposed without any extra pain. Might as well protect > the password against sniffing if we can... That was my logic. Pretty cheap to do it. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Another idea is to add code to 7.1 to convert non-md5 shadow password > > fields to md5 format. Since we already have special handling to do > > pg_pwd, we could do it there. Seems like a plan. MD5 format is all > > hex digits of a specific length. No way to get that confused with a > > real password. > > Well, if you're willing to depend on that, then there's no need for the > WITH ENCRYPTED PASSWORD variant syntax: the existing syntax WITH > PASSWORD could do it all, just by checking to see if the supplied > password string looks like it's already been md5-ified. Yes, I would like that. Our syntax for CREATE USER is already pretty large. Why not do it automatically? > The real trick would be to get this to happen during a COPY into > pg_shadow --- if we did that, then dumps generated by 7.0 pg_dumpall > would still work. Perhaps a trigger on pg_shadow insert/update is > the right place to check and md5-ify the password? (If that's in place > then neither CREATE nor ALTER USER would need to do anything special!) We already have a trigger for pg_shadow updates to recreate pg_pwd. Not sure if that happens from COPY however. I sure hope it does. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > So we're in agreement on using MD5. Sverre, is the offer still open > for the java MD5 you wrote? I'll translate it to C and make sure it > will compile/run/give-correct-results on as many platforms as possible > including DOS/Windows, hpux, FreeBSD and IRIX. Yes, MD5, double-crypt with pg_shadow salt and random salt. Sounds like a winner all around. And finally, we need a trigger to somehow update non-md5 strings in the pg_shadow password field. No one is sure how to do that yet. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
So, we're going to go with less security then is available on most Unix OSs? if we are going to do this, *please* just use the regular system crypt() function ... for those that are using MD5 for their passwords, at least as it is under FreeBSD, crypt() does either MD5 or DES depending on the system ... On Sat, 6 May 2000, Bruce Momjian wrote: > > > > So we're in agreement on using MD5. Sverre, is the offer still open > > for the java MD5 you wrote? I'll translate it to C and make sure it > > will compile/run/give-correct-results on as many platforms as possible > > including DOS/Windows, hpux, FreeBSD and IRIX. > > Yes, MD5, double-crypt with pg_shadow salt and random salt. Sounds like > a winner all around. > > And finally, we need a trigger to somehow update non-md5 strings in the > pg_shadow password field. No one is sure how to do that yet. > > -- > Bruce Momjian | http://www.op.net/~candle > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Sun, 7 May 2000, The Hermit Hacker wrote: > > So, we're going to go with less security then is available on most Unix > OSs? Whoever said MD5 is less secure than standard DES has handed you a line so long.... If you want the entire story, go back and reread the thread. If you want it in a nutshell, MD5 isn't reversable so it's not considered encryption as defined in the US Govt's eyes. DES has been broken more than once. I don't know what you're using on hub, but MD5 is the default in FreeBSD unless you actually choose DES. Also the FreeBSD folks feel that MD5 is the better choice. > if we are going to do this, *please* just use the regular system > crypt() function ... for those that are using MD5 for their passwords, at > least as it is under FreeBSD, crypt() does either MD5 or DES depending on > the system ... crypt() requires libcrypt which isn't available on all platforms. I think we all feel we can do better. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> > So, we're going to go with less security then is available on most Unix > OSs? > > if we are going to do this, *please* just use the regular system > crypt() function ... for those that are using MD5 for their passwords, at > least as it is under FreeBSD, crypt() does either MD5 or DES depending on > the system ... > We have to use MD5 with double-encription. We have to do that because all clients need MD5 too, and we can't assume they all have DES. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Sat, 06 May 2000, Benjamin Adida wrote: > on 5/6/00 2:14 PM, Tom Lane at tgl@sss.pgh.pa.us wrote: > > > However, I still fail to see what it buys us to challenge the frontend > > with two salts. If the password is stored crypted, the *only* thing > > we can validate is that password with the same salt it was stored > > with. It doesn't sound like MD5 changes this at all. > > The MD5 definitely doesn't change anything except overall security strength > of the algorithm. The additional random salt prevents someone from sniffing > the communication between client and server and then simply log in by > sending the known hash of the password. The challenge-response means that > sniffing one login doesn't allow you to fake the next one. > > -Ben I see. This protects the hash, which is an effective password, from being gotten by sniffers. But a cracker who has stolen the hashes out of Postgres can still get in no matter what until you change the passwords. I guess hashed password authentication is really not designed for use over an untrusted connection. You get the hash becomes effective password problem. Its very important that the hashed passwords stored in Postgres cannot be read by anyone except the Postgres superuser. I'm I getting this right? Crypto 101 - I'm learning. :) -- Robert B. Easter reaster@comptechnews.com
The Hermit Hacker <scrappy@hub.org> writes: > So, we're going to go with less security then is available on most Unix > OSs? What's your evidence for that assertion? Garfinkel & Spafford's _Practical Unix and Internet Security_ recommends MD5 as a *more* secure method for storing passwords than crypt() (page 720 in my copy). DES is almost 20 years older than MD5, so I'm not sure why you'd assume that it must be more secure. > if we are going to do this, *please* just use the regular system > crypt() function Half of the argument for touching the issue at all is that we have a lot of problems with crypt() --- not available on some platforms, inconsistent results across platforms (not proven yet, but seems likely) and a serious pain in the neck for our shared libraries to boot. If we have to stick with crypt I'm not sure it's worth doing anything. BTW, Vince, I see no need to reverse-engineer a Java implementation into C. The original spec includes a C implementation ... and it looks to have a reasonably BSDish license. See RFC 1321, eg at http://www.faqs.org/rfcs/rfc1321.html regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> So far, no one is excited about this so I will not push it anymore.
> Seems like that could be a solution, but we are trying not to bloat the
> PostgreSQL tarball. Shipping SSH would certainly do that.
We already have the ability to work with an externally provided SSL
library. Right at the moment I don't see the merit of folding SSL
into the Postgres distribution instead.
regards, tom lane
On Sun, 7 May 2000, Tom Lane wrote: > BTW, Vince, I see no need to reverse-engineer a Java implementation > into C. The original spec includes a C implementation ... and it > looks to have a reasonably BSDish license. See RFC 1321, eg at > http://www.faqs.org/rfcs/rfc1321.html Got it!! Thanks!! Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> I see. This protects the hash, which is an effective password, from being > gotten by sniffers. But a cracker who has stolen the hashes out of Postgres can > still get in no matter what until you change the passwords. > > I guess hashed password authentication is really not designed for use over an > untrusted connection. You get the hash becomes effective password problem. > Its very important that the hashed passwords stored in Postgres cannot be read > by anyone except the Postgres superuser. > > I'm I getting this right? Good point. Though they can't see the original password, they can have a pgsql client use it to connect to the database. Anyone have a fix for that one? -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
>> I see. This protects the hash, which is an effective password, from
>> being gotten by sniffers. But a cracker who has stolen the hashes
>> out of Postgres can still get in no matter what until you change the
>> passwords.
What's your point? Stealing a password is stealing a password,
whatever form it's represented in. More to the point, a cracker
who can get to the stored passwords in Postgres has already
thoroughly broken the database's security; he doesn't need any
more access to the db than he's already got.
>> Its very important that the hashed passwords stored in Postgres
>> cannot be read by anyone except the Postgres superuser.
No different from the current system, where the cleartext passwords
mustn't be readable by anyone except the superuser, either. That's
not the objective of this exercise. The objective is to ensure that
getting hold of the (hashed) Postgres passwords doesn't let you into
*other* systems that a database user might have used the same
(cleartext) password for. We're trying to provide some security
for other people's barns in the event that our own horses have already
been stolen.
regards, tom lane
On Sun, 07 May 2000, Tom Lane wrote: > not the objective of this exercise. The objective is to ensure that > getting hold of the (hashed) Postgres passwords doesn't let you into > *other* systems that a database user might have used the same > (cleartext) password for. We're trying to provide some security > for other people's barns in the event that our own horses have already > been stolen. Ok, now I feel like this discussion has gone full circle and it is all very clear to me. The objectives are satisfied by the MD5 double salt scheme. The password itself is protected. That doesn't protect the user. I guess my point is about protecting your login and keeping others from getting in there and doing things as you, in short, protecting the user. Sure, if the cracker got the hashes, he got everything, but the accountability/blame doesn't lie with one of the database users. The blame lies on the poor security of the postgres superuser only. When hashes alone are used for authentication, it should not matter if someone gets the hashes - the hashes alone shouldn't be enough let them in. Ordinarily, a cleartext password would go straight through to the other end over a path that isn't sniffable or isn't even over a network, like on a unix host when you login to a console. But in Postgres' case, you have the hash sent as an effective password from the client - it doesn't send the actual password. Anytime people really want a secure network login, they have to use ssh, ssl, or pgp (pub/private key) software. Those are the only things that really protect user and keeps in control of their login. Your password might be secure, but your login still isn't. Someone could get the hashes and you might not ever know it. They could login to the database system as you for a long long time stealing your information and doing things as you, but they'd never get your password. The user could end up getting blamed for some serious stuff that is not his fault. The user doesn't have control of his login. The dba might realize that he had a security breach and Bob's hash was stolen and used by a cracker to login as Bob and do serious damage. The db just shrugs it off and blames it on Bob, saying that Bob must have compromised his clear text password. I'd say under the scheme proposed, you really have to trust your dba and change your password frequently. Anyone with access to the hashes can login as you and make you look bad. -- Robert B. Easter reaster@comptechnews.com
"Robert B. Easter" <reaster@comptechnews.com> writes:
> I'd say under the scheme proposed, you really have to trust your dba
> and change your password frequently. Anyone with access to the hashes
> can login as you and make you look bad.
Again, what's your point? The dbadmin can do whatever he wants *inside
the database*, including altering data that you might nominally be
responsible for. He doesn't need your password for that, any more than
your local Unix sysadmin needs anything but root privileges to alter
your files.
The point of this change is to make sure that the dbadmin can't get
at your cleartext password, which might allow him to pose as you for
non-database purposes (if you are so foolish as to use that same
cleartext password for non-database purposes).
regards, tom lane
[Vince Vielhaber] | So we're in agreement on using MD5. Sverre, is the offer still open | for the java MD5 you wrote? Yes, of course! | I'll translate it to C and make sure it will | compile/run/give-correct-results on as many platforms as possible | including DOS/Windows, hpux, FreeBSD and IRIX. I started translating it yesterday. I'll do some commenting and testing today, if I get the time I need from my family. :) It's been three years since I last wrote a C program, so someone should probably peek thru it looking for pointer problems. :) If I don't finish it today, I'll send you the half finished stuff tonight (it's morning here now). OK? Sverre. -- <URL:mailto:sverrehu@online.no> <URL:http://home.sol.no/~sverrehu/> Echelon bait: semtex, bin Laden, plutonium,North Korea, nuclear bomb
On Sun, 7 May 2000, Sverre H. Huseby wrote: > [Vince Vielhaber] > > | So we're in agreement on using MD5. Sverre, is the offer still open > | for the java MD5 you wrote? > > Yes, of course! > > | I'll translate it to C and make sure it will > | compile/run/give-correct-results on as many platforms as possible > | including DOS/Windows, hpux, FreeBSD and IRIX. > > I started translating it yesterday. I'll do some commenting and > testing today, if I get the time I need from my family. :) It's been > three years since I last wrote a C program, so someone should probably > peek thru it looking for pointer problems. :) > > If I don't finish it today, I'll send you the half finished stuff > tonight (it's morning here now). OK? Works for me. BTW, you may want to look at your email configuration. The BCC was leaking thru. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Bruce Momjian wrote: > > Another idea is to add code to 7.1 to convert non-md5 shadow password > fields to md5 format. Since we already have special handling to do > pg_pwd, we could do it there. Seems like a plan. MD5 format is all > hex digits of a specific length. No way to get that confused with a > real password. One way to approach it in a semi-transparent way would be to add a column md5passwd to pg_shadow and set up a trigger to automatically update it whenever passwd is inserted/updated (and for security-concious people the same trigger would empty the passwd field itself, or set it to some special value that disables crypt/cleartext logins) the WITH ENCRYPTED PASSWORD would then update md5passwd directly, and reset the passwd field. I still think that the easiest way to get unique hashes would be to use the username as salt when generating the value for md5passwd . ---------------- Hannu
Bruce Momjian wrote: > > > > > So we're in agreement on using MD5. Sverre, is the offer still open > > for the java MD5 you wrote? I'll translate it to C and make sure it > > will compile/run/give-correct-results on as many platforms as possible > > including DOS/Windows, hpux, FreeBSD and IRIX. > > Yes, MD5, double-crypt with pg_shadow salt and random salt. Sounds like > a winner all around. why pg_shadow salt ? for md5 we will need to store it separately anyway. why not MD5(<server-supplied-random-salt> || MD5(<username> || <password>)) that way we would overcome the original need for salt (accidental discovery of similar passwords) and would have no need for storing the salt. actually we would probably need some kind of separator as well to avoid the scenario of <user>+<password> and <userpa>+<ssword> being the same and thus having the same md5 hash. so the escheme could be MD5(<server-supplied-random-salt> || '\n' || MD5(<username> || '\n' || <password>)) AFAIK there is no easy way to have a newline inside password. > And finally, we need a trigger to somehow update non-md5 strings in the > pg_shadow password field. No one is sure how to do that yet. see my separate mail which I was unable to send yesterday as my phone line went down ;( -------------- Hannu
The Hermit Hacker wrote: > > So, we're going to go with less security then is available on most Unix > OSs? No, the general consensus seems to be using MD5, not the weaker DES crypt. > if we are going to do this, *please* just use the regular system > crypt() function ... for those that are using MD5 for their passwords, at > least as it is under FreeBSD, crypt() does either MD5 or DES depending on > the system ... What does it do to portbility ? ----------- Hannu
[Vince Vielhaber] | Works for me. Ok, here's the source. Please note the following: * You should change the typedefs in md5.c. I guess the PostgreSQL source has types that are correct for various platforms. I've run this on Linux (x86) only. * I use the Artistic License. Feel free to replace it with the license used in the rest of PostgreSQL. * I tested my implementation (or rather, the translation to C) by generating MD5 sums for all files in my /usr/local/bin, and comparing the sums with those generated by GNU's md5sum program. You may want to do further tests. * Although I've written tens of thousands of lines of C code in the past, it is almost three years since the last time I did. Java programming has made me rather relaxed when it comes to memory handling, so you should look for pointer problems and failure to free allocated memory. :-) * Salting is left to the caller. You will probably want to build convenience functions on top of md5_hash. I really hope you will find the code useful, as it is my secret wish to contribute to PostgreSQL. :-) Please keep me informed on what you do with the code, even if you choose to throw it in /dev/null. Sverre. -- <URL:mailto:sverrehu@online.no> <URL:http://home.sol.no/~sverrehu/> Echelon bait: semtex, bin Laden, plutonium, North Korea, nuclear bomb
Attachment
> > Yes, MD5, double-crypt with pg_shadow salt and random salt. Sounds like > > a winner all around. > > why pg_shadow salt ? for md5 we will need to store it separately anyway. > why not MD5(<server-supplied-random-salt> || MD5(<username> || > <password>)) > that way we would overcome the original need for salt (accidental > discovery > of similar passwords) and would have no need for storing the salt. > > actually we would probably need some kind of separator as well to avoid > the scenario of <user>+<password> and <userpa>+<ssword> being the same > and thus having the same md5 hash. so the escheme could be > > MD5(<server-supplied-random-salt> || '\n' || MD5(<username> || '\n' || > <password>)) > > AFAIK there is no easy way to have a newline inside password. Well, unix passwords don't use the username as salt, so why should we? -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Sun, 07 May 2000, you wrote: > So, if someone can see those hashes, why don't they just create > themselves a new user, grant it full privileges to the database and > play? I know, they can do anything. But creating a new user is something very obvious that the admin will see. The breach of security would be detectable. If they can get in with the hashes, they can be very sneaky and it would take a long time to detect. The cracker shouldn't able to compromise a current users account without having to even change the password on it. Its better to force the cracker have to create an account than to let him do bad things as you whenever he wants. Would you like the feeling of never knowing that maybe someone has your hash and is able to get in without you knowing? Your password becomes useless. Really, sensitive information in the database could be insecure over a long period of time and it would never be detectable. You'd just have to change your password frequently to ensure that you are the only one that can get in. Its better to make a security system where the alarm will go off. If your competitor is able to get into the database as you, because he got your hash after hiring some cracker to get it, he can learn all your trade secrets and always find a way to have the advantage. You and your company might have a hard time figuring out whats going on because, so to speak, the security on the database has no alarm. I agree that the MD5 double hash solution fixes the immediate problem. Its just not going to be a complete security solution. -- Robert B. Easter reaster@comptechnews.com
Hannu Krosing <hannu@tm.ee> writes:
> One way to approach it in a semi-transparent way would be to add a
> column md5passwd to pg_shadow and set up a trigger to automatically
> update it whenever passwd is inserted/updated (and for
> security-concious people the same trigger would empty the passwd
> field itself, or set it to some special value that disables
> crypt/cleartext logins)
I don't think it's optional to get rid of the cleartext password;
kindly recall the original complaint we are trying to address
(see subject line of this thread ;-)). So there's little value in
storing two columns.
Also, by having just one password field we can deal with either
cleartext or pre-encrypted incoming passwords fairly easily.
The trigger either reformats the field, or not; no upstream code
needs to worry about whether the password is already encrypted.
So we don't need the "WITH ENCRYPTED PASSWORD" variant syntax,
which is a good thing IMHO.
> I still think that the easiest way to get unique hashes would be to use
> the username as salt when generating the value for md5passwd .
No, I don't think that's an improvement. Please recall that the
original reason for inventing salt was to make sure that it wouldn't be
obvious whether the same user was using the same password on multiple
machines.
Since MD5 can take an arbitrarily long input phrase, we could possibly
run the calculation as MD5(password || username || random salt), but
there *must* be some randomness in there.
I doubt that it'd be all that great an idea to include the username.
The biggest objection to it is that renaming a user would break his
password (nonobviously, too). The only reason in favor of it is that
it wouldn't be apparent when two different users share the same password
--- but the random salt covers that problem and does more too.
regards, tom lane
On Sun, 7 May 2000, Bruce Momjian wrote: > > > Yes, MD5, double-crypt with pg_shadow salt and random salt. Sounds like > > > a winner all around. > > > > why pg_shadow salt ? for md5 we will need to store it separately anyway. > > why not MD5(<server-supplied-random-salt> || MD5(<username> || > > <password>)) > > that way we would overcome the original need for salt (accidental > > discovery > > of similar passwords) and would have no need for storing the salt. > > > > actually we would probably need some kind of separator as well to avoid > > the scenario of <user>+<password> and <userpa>+<ssword> being the same > > and thus having the same md5 hash. so the escheme could be > > > > MD5(<server-supplied-random-salt> || '\n' || MD5(<username> || '\n' || > > <password>)) > > > > AFAIK there is no easy way to have a newline inside password. > > Well, unix passwords don't use the username as salt, so why should we? It could add a level of security. The client knows the username. If the client were to only send LOGIN or something like that to the server without sending the username and the server only replied with the random salt, the client would know that the username was the fixed salt and could use that with random salt received from the server. So it's really a hidden salt. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> It could add a level of security. The client knows the username. If
> the client were to only send LOGIN or something like that to the server
> without sending the username and the server only replied with the random
> salt, the client would know that the username was the fixed salt and could
> use that with random salt received from the server. So it's really a
> hidden salt.
Hidden from whom? The client *must* send the username to the server,
so a sniffer who is able to see both sides of the conversation will
still have all the same pieces. If the sniffer only sees one side of
the conversation, he's still in trouble: he'll get the random salt, or
the hashed password, but not both. So I still don't see what the
username is adding to the process that will make up for rendering it
much more difficult to rename users.
regards, tom lane
On Sun, 7 May 2000, Tom Lane wrote: > Vince Vielhaber <vev@michvhf.com> writes: > > It could add a level of security. The client knows the username. If > > the client were to only send LOGIN or something like that to the server > > without sending the username and the server only replied with the random > > salt, the client would know that the username was the fixed salt and could > > use that with random salt received from the server. So it's really a > > hidden salt. > > Hidden from whom? The client *must* send the username to the server, > so a sniffer who is able to see both sides of the conversation will > still have all the same pieces. If the sniffer only sees one side of > the conversation, he's still in trouble: he'll get the random salt, or > the hashed password, but not both. So I still don't see what the > username is adding to the process that will make up for rendering it > much more difficult to rename users. My intent was not to send the username, but let the server figure it out by the response. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> My intent was not to send the username, but let the server figure it
> out by the response.
That would be a neat trick. How will you do it? MD5 is not reversible.
Actually you could do it, but *not* by folding the username into the
password. Instead try this:
1. Client chooses random saltC, sends saltC and MD5(username, saltC)
to server in initial request.
2. Server runs through all available usernames, computing
MD5(thisusername, saltC) for each one and looking for a match.
3. Server chooses random saltS, sends it to client along with saltP
stored in pg_shadow entry for user.
4. Client computes MD5(MD5(password, saltP), saltS) and sends to server.
Server compares this against MD5(stored hashed password, saltS).
This would prevent a sniffer from finding out anything about the valid
usernames, which'd be a useful improvement, but I'm not convinced that
it's worth breaking the initial protocol for. (Not to mention the
additional postmaster CPU time --- step 2 above is not cheap if there
are lots of usernames.) So far we have just been talking about adding
a different type of authentication challenge to the set we already
support; that doesn't break old clients as long as they aren't
challenged that way. Modifying the initial connection request packet
is a different story.
I'm still of the opinion that anyone who is really concerned about
sniffing attacks ought to be using SSL, because protecting just their
password and not the data that will be exchanged later in the session is
unwise. So I'm not really excited about adding anti-sniffing frammishes
like this one. We've got a good scheme for the password; let's be
careful about adding "improvements" that won't carry their weight in
the real world. There's no such thing as a single security scheme that
addresses every possible vulnerability. Extending one part of your
security arsenal to partially solve problems that are better solved
by a different tool is just wasting time.
regards, tom lane
On Sun, 7 May 2000, Tom Lane wrote: > Vince Vielhaber <vev@michvhf.com> writes: > > My intent was not to send the username, but let the server figure it > > out by the response. > > That would be a neat trick. How will you do it? MD5 is not reversible. CLIENT: md5(salt_from_server + md5(username + md5(password))) SERVER: md5(salt_from_server + md5(username + stored_password)) The server runs thru all available usernames using the above algorithm. > I'm still of the opinion that anyone who is really concerned about > sniffing attacks ought to be using SSL, because protecting just their > password and not the data that will be exchanged later in the session is > unwise. So I'm not really excited about adding anti-sniffing frammishes > like this one. We've got a good scheme for the password; let's be > careful about adding "improvements" that won't carry their weight in > the real world. There's no such thing as a single security scheme that > addresses every possible vulnerability. Extending one part of your > security arsenal to partially solve problems that are better solved > by a different tool is just wasting time. Agreed. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
>>>> My intent was not to send the username, but let the server figure it
>>>> out by the response.
>>
>> That would be a neat trick. How will you do it? MD5 is not reversible.
> CLIENT: md5(salt_from_server + md5(username + md5(password)))
> SERVER: md5(salt_from_server + md5(username + stored_password))
> The server runs thru all available usernames using the above algorithm.
No, that doesn't work unless stored passwords contain no random salt
at all (you could use the username alone, but as I previously said
that's no substitute for random salt, and of dubious value anyway).
That'd be a distinct *loss* in security, not an improvement.
To have salt in the stored passwords, the server must receive the
username first so that it can look up the pg_shadow entry and find
which stored salt to send to the client (along with the randomly
generated per-transaction salt). You could cloak the username as
I suggested before, but there have to be two messages.
regards, tom lane
On Sun, 7 May 2000, Tom Lane wrote: > Vince Vielhaber <vev@michvhf.com> writes: > >>>> My intent was not to send the username, but let the server figure it > >>>> out by the response. > >> > >> That would be a neat trick. How will you do it? MD5 is not reversible. > > > CLIENT: md5(salt_from_server + md5(username + md5(password))) > > > SERVER: md5(salt_from_server + md5(username + stored_password)) > > > The server runs thru all available usernames using the above algorithm. > > No, that doesn't work unless stored passwords contain no random salt > at all (you could use the username alone, but as I previously said > that's no substitute for random salt, and of dubious value anyway). > That'd be a distinct *loss* in security, not an improvement. > > To have salt in the stored passwords, the server must receive the > username first so that it can look up the pg_shadow entry and find > which stored salt to send to the client (along with the randomly > generated per-transaction salt). You could cloak the username as > I suggested before, but there have to be two messages. You're right, it wouldn't work. It should've been like this: CLIENT: md5(salt_from_server + md5(username + password))) SERVER: md5(salt_from_server + stored_password) The "salt_from_server" is your random salt. The fixed salt is the username. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> You're right, it wouldn't work. It should've been like this:
> CLIENT: md5(salt_from_server + md5(username + password)))
> SERVER: md5(salt_from_server + stored_password)
> The "salt_from_server" is your random salt. The fixed salt is the
> username.
You're still not getting the point. I refer you to Ben Adida's
original, correct description of the way to do this:
> - client requests login
> - server sends stored salt c1, and random salt c2.
> - client performs hash_c2(hash_c1(password)) and sends result to server.
> - server performs hash_c2(stored_pg_shadow) and compares with client
> submission.
> - if there's a match, there's successful login.
There have to be *two* random salts involved, one chosen when the
password was set (and used to cloak the stored password against people
with access to pg_shadow) and one chosen for the duration of this
password challenge (and used to cloak the challenge transaction against
people sniffing the packet traffic). If you give up either one of those
bits of randomness then you lose a great deal.
Using the username instead of an independent random value to salt the
stored password is not a small change, it is a fundamental weakening of
the security system. If you don't see that this is so then you don't
understand anything about cryptography.
regards, tom lane
Tom Lane wrote:
>
> Hannu Krosing <hannu@tm.ee> writes:
> > One way to approach it in a semi-transparent way would be to add a
> > column md5passwd to pg_shadow and set up a trigger to automatically
> > update it whenever passwd is inserted/updated (and for
> > security-concious people the same trigger would empty the passwd
> > field itself, or set it to some special value that disables
> > crypt/cleartext logins)
>
> I don't think it's optional to get rid of the cleartext password;
> kindly recall the original complaint we are trying to address
> (see subject line of this thread ;-)). So there's little value in
> storing two columns.
there is some value in
A. a smooth transition path via dump/restore
B. backwards compatibility for those that need it more than security - we can still do DES-crypt authentication if we
chooseto
later (say in 7.2) we can drop password and have only md5password
> Also, by having just one password field we can deal with either
> cleartext or pre-encrypted incoming passwords fairly easily.
> The trigger either reformats the field, or not; no upstream code
> needs to worry about whether the password is already encrypted.
> So we don't need the "WITH ENCRYPTED PASSWORD" variant syntax,
> which is a good thing IMHO.
But how will you know if the data in the field is md5 hashed ?
I know no way to tell for sure if an arbitrary string is a md5
hash or not.
Of course we could choose a format like {MD5}:hashedstring
and disallow cleartext passwords which start with {MD5}: like Zope does
> > I still think that the easiest way to get unique hashes would be to use
> > the username as salt when generating the value for md5passwd .
>
> No, I don't think that's an improvement. Please recall that the
> original reason for inventing salt was to make sure that it wouldn't be
> obvious whether the same user was using the same password on multiple
> machines.
Ok. My previous impression was that it was in order to make sure that
two users on the same machine would not find out theat the other is
using the same passord as she is
> Since MD5 can take an arbitrarily long input phrase, we could possibly
> run the calculation as MD5(password || username || random salt), but
> there *must* be some randomness in there.
>
> I doubt that it'd be all that great an idea to include the username.
> The biggest objection to it is that renaming a user would break his
> password (nonobviously, too).
Can we really rename users ?
hannu=# create user foo;
CREATE USER
hannu=# alter user foo rename to bar;
ERROR: parser: parse error at or near "rename"
Why would one do it in the first place ?
> The only reason in favor of it is that
> it wouldn't be apparent when two different users share the same password
> --- but the random salt covers that problem and does more too.
True. I did not think of the one user/multiple computers scenario.
-----------
Hannu
On Sun, 07 May 2000, Hannu Krosing wrote: > > But how will you know if the data in the field is md5 hashed ? I think they begin with $1$ and that the salt in the hashed string is like this: $1$<salt>$ -- a total of 12 characters of salt if you include the $1$$ characters. <salt> is 9 characters. Someone can correct me if this is not true. I'm not an expert. :) Robert B. Easter reaster@comptechnews.com
Tom Lane wrote: > > Vince Vielhaber <vev@michvhf.com> writes: > > You're right, it wouldn't work. It should've been like this: > > > CLIENT: md5(salt_from_server + md5(username + password))) > > > SERVER: md5(salt_from_server + stored_password) > > > The "salt_from_server" is your random salt. The fixed salt is the > > username. > > You're still not getting the point. I refer you to Ben Adida's > original, correct description of the way to do this: > > > - client requests login > > - server sends stored salt c1, and random salt c2. > > - client performs hash_c2(hash_c1(password)) and sends result to server. > > - server performs hash_c2(stored_pg_shadow) and compares with client > > submission. > > - if there's a match, there's successful login. > > There have to be *two* random salts involved, one chosen when the > password was set (and used to cloak the stored password against people > with access to pg_shadow) and one chosen for the duration of this > password challenge (and used to cloak the challenge transaction against > people sniffing the packet traffic). If you give up either one of those > bits of randomness then you lose a great deal. > > Using the username instead of an independent random value to salt the > stored password is not a small change, it is a fundamental weakening of > the security system. It allows one of the salts to never be sent, thereby strengthening that part against _anyone_sniffing_the_traffic_ (just a little) as he sees only one hash, different each time. It allows _a_user_with_access_to_ pg_shadow _on_two_or_more_machines_ see the fact that a user has the same password on both of them (which info he can then useto guess the password in two tries, as often seen in movies ;) > If you don't see that this is so then you don't understand anything > about cryptography. It is too easy to think that you do ;). BTW, I don't claim to "understand cryptography" . What I said above is just plain common sense ;) And you will never get good security by cryptography only, not even by using SSL or SSH which are the right way to go if you want to protect against sniffing. The current thread started from a simple the need to hide passwords from PG superusers and system ROOT's. For that we have two schemes: store MD5(username+passwd)- hidden from sniffing but easily guessable salt (as most users are called 'bob') store MD5(random_salt+password) , or more likely random_salt+MD5(random_salt+passord) or we will never find out the salt again ;)- both salts are known to sniffer who isstill unable to do anything with them the difference between the two in mainly the fact that in first case the user already knows the salt and in the second case it must be transferred to her over fire - this makes the first one stronger, at least in case when the username is chosen as creatively as the password ;) otoh, in the second case three things should match username, salt and hash which of course makes the second case stronger. If you understand which one is stronger you are smarter than I am ;) -------------- Hannu
Hannu Krosing <hannu@tm.ee> writes:
> Tom Lane wrote:
>> I don't think it's optional to get rid of the cleartext password;
>> kindly recall the original complaint we are trying to address
>> (see subject line of this thread ;-)). So there's little value in
>> storing two columns.
> there is some value in
> A. a smooth transition path via dump/restore
True, but if we set up the translation to occur in a trigger that
checks for already-hashed data, then we've got that licked.
> B. backwards compatibility for those that need it more than security -
> we can still do DES-crypt authentication if we choose to
That is a definite loss, but on the other hand I now realize that the
crypt-based authentication has its own compatibility problems: it may
fail with a client running on another machine already! Not to mention
that some popular client platforms and/or interfaces (think ODBC) never
have supported crypt authentication. So it's questionable that there
are very many people using it in cross-platform situations where
backwards compatibility with old clients is critical. Furthermore,
it's not like the people who do get burnt have no option at all: they
can switch to cleartext password authentication or one of the other
already-supported methods until they can bring their clients up to
speed. On the whole, I think the advantages of moving to MD5 clearly
outweigh this single disadvantage.
>> Also, by having just one password field we can deal with either
>> cleartext or pre-encrypted incoming passwords fairly easily.
>> The trigger either reformats the field, or not; no upstream code
>> needs to worry about whether the password is already encrypted.
>> So we don't need the "WITH ENCRYPTED PASSWORD" variant syntax,
>> which is a good thing IMHO.
> But how will you know if the data in the field is md5 hashed ?
Easily. We will need, say, 32 bits of random salt plus the 128-bit
MD5 hash value. Represent these in a string that consists of, say,
8 hex digits, a '/' sign, and 32 more hex digits; use only uppercase
A-F, not lowercase, as hex digits. Now, are you going to say that23B3C990/652B8383A48348CDEF57298289A882DD
is plausible as a cleartext password? I don't agree...
>> No, I don't think that's an improvement. Please recall that the
>> original reason for inventing salt was to make sure that it wouldn't be
>> obvious whether the same user was using the same password on multiple
>> machines.
> Ok. My previous impression was that it was in order to make sure that
> two users on the same machine would not find out theat the other is
> using the same passord as she is
It does that too. But remember that the point of not storing cleartext
passwords is to prevent using a password stolen from User A to break
into User A's other accounts, not User B's accounts. So same username,
different machine is definitely a case we should consider.
> Can we really rename users ?
update pg_shadow set usename = 'bar' where usename = 'foo';
An ALTER USER syntax would be handier, but you don't really need it...
regards, tom lane
Tom Lane writes: > How will dump/restore and upgrades cope with crypted passwords? We could distribute a sed or awk script that you have to run on the dumped file to convert the copy to create user commands. Shouldn't be hard to write, it's just a question of whether people want to put up with it. It seems cleaner than any of the "magic hooks" that have been proposed. Actually, I have some ideas in the pipe that would indeed change the layout of pg_shadow slightly, so this might have to happen anyway. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
"Robert B. Easter" wrote:
>
> On Sun, 07 May 2000, Hannu Krosing wrote:
> >
> > But how will you know if the data in the field is md5 hashed ?
>
> I think they begin with $1$ and that the salt in the hashed string is like this:
how do you distinguish it from a plaintext password thet starts with $1$
?
> $1$<salt>$ -- a total of 12 characters of salt if you include the $1$$
> characters. <salt> is 9 characters. Someone can correct me if this is not
> true. I'm not an expert. :)
Well in Zope they begin with {MD5} for MD5 hash. The md5 hash itself
knows
nothing about salt - it is just fed to the function before the password.
And the digest can begin with anything, possibly even \0 if not
{uu|base64}encoded
------------
Hannu
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> How will dump/restore and upgrades cope with crypted passwords?
> We could distribute a sed or awk script that you have to run on the dumped
> file to convert the copy to create user commands. Shouldn't be hard to
> write, it's just a question of whether people want to put up with it. It
> seems cleaner than any of the "magic hooks" that have been proposed.
To my mind the real advantage of doing it in a trigger is that
CREATE USER WITH PASSWORD and ALTER USER SET PASSWORD can accept
*either* cleartext or already-hashed password data. That seems
nicer than forcing the user to deal with two syntaxes, upgrade
scripts, etc.
> Actually, I have some ideas in the pipe that would indeed change the
> layout of pg_shadow slightly, so this might have to happen anyway.
How far down the pipe? It'd be nice if we could fix pg_dumpall to
dump CREATE USER commands a version before we actually need it ;-).
I'd like to change the script for 7.1 (or maybe even 7.0.1) but keep
backwards compatibility for the old-style dump scripts until 7.2.
(At the moment I'm kind of kicking myself for not having fixed the
problem when I saw it, but there was no talk of pg_shadow changes
in the air at the time.)
regards, tom lane
On Sun, 7 May 2000, Tom Lane wrote: > Using the username instead of an independent random value to salt the > stored password is not a small change, it is a fundamental weakening of > the security system. That's what I was doing, substituting the original random salt for the username. > If you don't see that this is so then you don't > understand anything about cryptography. Was this smartass comment really necessary, Tom? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
>> If you don't see that this is so then you don't
>> understand anything about cryptography.
> Was this smartass comment really necessary, Tom?
Probably not. My sincerest apologies.
regards, tom lane
At 15:34 7/05/00 -0400, Tom Lane wrote: > >You're still not getting the point. I refer you to Ben Adida's >original, correct description of the way to do this: > >> - client requests login >> - server sends stored salt c1, and random salt c2. >> - client performs hash_c2(hash_c1(password)) and sends result to server. >> - server performs hash_c2(stored_pg_shadow) and compares with client >> submission. >> - if there's a match, there's successful login. > I may well have missed something here, but it seems to me that the above scheme is also not particularly secure since someone who has managed to get access to the pg_shadow file will be able to fake a login by using a custom client. ie: - client requests login- server sends stored salt c1, and random salt c2.- client ignores c1 and performs hash_c2(some_hash_from_the_file)and sends result to server.- server performs hash_c2(stored_pg_shadow) and compares with client submission. Have I missed somehting here? Obviously it depends on getting a copy of pg_shadow. It seems that there are at least two problems to solve in the whole password & authentication problem: 1. How to store passwords so they can't be decrypted. 2. How to perform a secure handshake with a client. You have already solved (1) by using MD5 (or even SHA, which is faster to compute). To solve (2) it seems to me that a slightly more complex interaction must be undertaken using a public key algorithm: - Client sends [username] to server- Server sends [public key] to client- Client sends [enc(public key, password)] to server.- server uses dec(secret key,enc) and computes MD5 hash of password, comparing it to pg_shadow. This would require a decent large integer library (which certainly exist). For speed, a key pair would need to be stored on the server, since key generation is quite slow. In order for a man-in-the-middle attack to work, the attacker would also need the secret key off the server. The risk could be reduced, at the expense of computation, by generating a new key pair for each client, although that would be *very* expensive. Additionally, it may be good to allow the entire client/server comms to be done as an encrypted interaction, since a man-in-the-middle may not be able to read the password, but they will be able to read the data... FWIW, I'd be willing to write the password and handshaking code, if no-one else were interested. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: +61-03-5367 7422 | _________ \ Fax: +61-03-5367 7430 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
on 5/8/00 11:38 AM, Philip Warner at pjw@rhyme.com.au wrote: > I may well have missed something here, but it seems to me that the above > scheme is also not particularly secure since someone who has managed to get > access to the pg_shadow file will be able to fake a login by using a custom > client. ie: Yes, absolutely, but someone who gets the pg_shadow file can also alter the database however he/she wants. The protocol defined prevents any knowledge gained from sniffing, and prevents discovery of plaintext passwords from looking at pg_shadow. However, it does not prevent logins, as you mention, because once you have the pg_shadow file, you've got everything anyways. -Ben
Philip Warner <pjw@rhyme.com.au> writes:
> To solve (2) it seems to me that a slightly more complex interaction must
> be undertaken using a public key algorithm:
> - Client sends [username] to server
> - Server sends [public key] to client
> - Client sends [enc(public key, password)] to server.
> - server uses dec(secret key,enc) and computes MD5 hash of password,
> comparing it to pg_shadow.
Hmm. The main problem with this is that once we get into having actual
encryption/decryption code in Postgres, we are going to run afoul of US
export regulations and other headaches. MD5 doesn't pose that problem
because it's only a hashing algorithm not an encryptor. I see your
point though, that requiring the client to send something one step
upstream from what's stored in pg_shadow would make it harder to do
anything useful by stealing pg_shadow. Can we get the same result with
just MD5 operations?
One possibility that comes to mind is that we store MD5(MD5(password))
in pg_shadow, and expect the client to transmit MD5(password).
Of course that needs a cloaking scheme if you want to protect against
password sniffing, but offhand it seems that the same scheme Ben Adida
proposed should still work...
> Additionally, it may be good to allow the entire client/server comms to be
> done as an encrypted interaction, since a man-in-the-middle may not be able
> to read the password, but they will be able to read the data...
We have SSL capability already. I don't feel an urge to reinvent SSL.
regards, tom lane
At 12:02 8/05/00 -0400, Tom Lane wrote: >Philip Warner <pjw@rhyme.com.au> writes: > >Hmm. The main problem with this is that once we get into having actual >encryption/decryption code in Postgres, we are going to run afoul of US >export regulations and other headaches. I thought that they had been relaxed recently, but I take the point: it's probably not been relaxed enough. Then again, maybe 48 bit (or 56 or 112 or whatever) is sufficient. >One possibility that comes to mind is that we store MD5(MD5(password)) >in pg_shadow, and expect the client to transmit MD5(password). >Of course that needs a cloaking scheme if you want to protect against >password sniffing, but offhand it seems that the same scheme Ben Adida >proposed should still work... Yes. This seems like a much simpler solution - getting the pg_shadow file is almost useless, as long as the effectiveness of dictionary attacks is reduced by a sufficiently large salt. It still does not protect against a man-in-the-middle attack, since the new 'password' is just a 160 bit value, rather than clear text. Unless SSL is used, of course. > >We have SSL capability already. I don't feel an urge to reinvent SSL. > Sounds pretty reasonable to me. But if SSL is already there, don't you have import/export problems? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: +61-03-5367 7422 | _________ \ Fax: +61-03-5367 7430 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Philip Warner <pjw@rhyme.com.au> writes:
>> We have SSL capability already. I don't feel an urge to reinvent SSL.
> Sounds pretty reasonable to me. But if SSL is already there, don't you have
> import/export problems?
No, because we don't include SSL in the distribution. There are just
hooks to call it.
(At one time there were export regs against even having hooks for crypto
:-(, but I believe they finally agreed that was pretty silly...)
regards, tom lane
On Tue, 9 May 2000, Philip Warner wrote: > At 12:02 8/05/00 -0400, Tom Lane wrote: > >Philip Warner <pjw@rhyme.com.au> writes: > > > >Hmm. The main problem with this is that once we get into having actual > >encryption/decryption code in Postgres, we are going to run afoul of US > >export regulations and other headaches. > > I thought that they had been relaxed recently, but I take the point: it's > probably not been relaxed enough. Then again, maybe 48 bit (or 56 or 112 or > whatever) is sufficient. Being a Canadian based project, like OpenBSD, I do not believe that these issues apply ... even FreeBSD, based in California, appears to be getting around them now ... something about making you download rsaref seperately, they can now ship with OpenSSH included as part of the system?
The Hermit Hacker <scrappy@hub.org> writes:
> Being a Canadian based project, like OpenBSD, I do not believe that these
> issues apply ...
If we had to do it that way we could, but I'd just as soon not create
any questions for US mirror sites.
> even FreeBSD, based in California, appears to be getting
> around them now ... something about making you download rsaref seperately,
Yes, I think this is the cleanest current answer: you can connect to a
separately-distributed crypto engine and then it's not your problem.
MD5 (or SHA1 if people like that better) isn't a crypto engine according
to the rules, so including that in our distribution is a non-issue,
but a reversible encryptor might be an issue.
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> We already have the ability to work with an externally provided SSL
>> library.
> Does it actually work? Has anybody tried it? Is it documented anywhere?
Picky, picky ;-)
It looks like you compile with USE_SSL (which ought to be listed as an
available option in config.h.in, but isn't; someday it should be a
configure option, perhaps) and then add "-l" to the postmaster switches.
At least "-l" is documented.
There are some interactions between SSL-client-and-non-SSL-server, etc,
which you can read about in the pghackers archives from last year, if
not in the docs. Also, I thought there was supposed to be a postmaster
option to refuse non-SSL connections, but I don't see it now...
As for whether it works, damifino; I don't have SSL installed here.
I do have a note in my todo list that speculates that the recent changes
for non-blocking connect in libpq may have broken its SSL support, and I
asked the pghackers list about that in January. But I didn't get around
to looking at it, and no one else picked up on it either.
regards, tom lane
Tom Lane writes: > We already have the ability to work with an externally provided SSL > library. Does it actually work? Has anybody tried it? Is it documented anywhere? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Tom Lane wrote: > One possibility that comes to mind is that we store MD5(MD5(password)) > in pg_shadow, and expect the client to transmit MD5(password). > Of course that needs a cloaking scheme if you want to protect against > password sniffing, but offhand it seems that the same scheme Ben Adida > proposed should still work... That would be pretty close to the RFC 2617 Digest Authentication. Why don't we use that? Using a existing, widespread standard is good in terms of portability, and saves on validating the principal algorithm. Sevo -- sevo@ip23.net
Tom Lane writes: > > Actually, I have some ideas in the pipe that would indeed change the > > layout of pg_shadow slightly, so this might have to happen anyway. > > How far down the pipe? It would have to do with the access control work which I had planned to look at. With the summer and all coming up and the hopefully shorter release cycle I'm not sure whether I'm going to get to it. The configuration and build clean-up should happen first anyway. > It'd be nice if we could fix pg_dumpall to dump CREATE USER commands a > version before we actually need it ;-). The problem is that CREATE USER doesn't cover all fields of pg_shadow, in particular usecatupd. Though perhaps this field is obscure enough to not bother. Also this will be pretty tricky to get to work for groups. (That pg_group table really needs a redesign.) -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
>> It'd be nice if we could fix pg_dumpall to dump CREATE USER commands a
>> version before we actually need it ;-).
> The problem is that CREATE USER doesn't cover all fields of pg_shadow, in
> particular usecatupd. Though perhaps this field is obscure enough to not
> bother.
Well, we'd also want to make sure that CREATE and/or ALTER USER can be
used to set everything in pg_shadow. A few more optional clauses
shouldn't be a big deal ...
> Also this will be pretty tricky to get to work for groups. (That
> pg_group table really needs a redesign.)
True. I'm inclined to think that should be looked at in the context
of the schema support that people have been muttering about --- maybe
groups can be replaced by schemas somehow? (Just a thought, maybe a
half-baked one.)
regards, tom lane
If I understand the original objection it's that passwords are stored in cleartext on the postmaster machine. That's not much of an objection since you have to have your secrets available in the clear on both ends of a connection if you want the traffic on the connection secured. Both the Solaris and NetBSD ppp implementations have this characteristic. Kerberos IV encrypts the passwords on the server, but the master password for that encryption is still stored in "/.k" so it's the same in principle. If I understand the current password implementation the postmaster chooses the salt, sends it to the client which does a unix crypt and returns the encrypted password for verification. This is a nice, simple system which provides what I would consider a reasonable minimum of security. But it's not *really* secure. For one thing a bad guy could intercept the encrypted password and feed it to one of the password-guessing programs, like crack. It's not very robust to man-in-the-middle attacks, either. Do we know how predictable the salt-choosing algorithm is? What if a counterfeit server requested authentication with a carefully-chosen salt (like 0)? We are not in the business of creating security protocols. IMHO we should leave that to the people who are. If we want something better than the password scheme we have then we should adopt an existing standard. Chap, as used with ppp, comes to mind. It might be a good substitute for the password protocol. Remember that we already support kerberos. Also there is no reason you can't run the connection over an ssh tunnel. That solution would protect the data as well as the passwords. There are applications where the important information is not what's in the database, but what information did someone want from it and when did they ask. Out of curiosity does SecurityFocus.com also criticise pppd for the same "problem"? The problem is not us storing the passwords in the clear, but rather are we careful about the access permissions on the file that contains them, and are we careful about how they get passed around. Signature failed Preliminary Design Review. Feasibility of a new signature is currently being evaluated. h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
> But it's not *really* secure. For one thing a bad guy could
> intercept the encrypted password and feed it to one of the
> password-guessing programs, like crack. It's not very robust to
> man-in-the-middle attacks, either. Do we know how predictable the
> salt-choosing algorithm is? What if a counterfeit server requested
> authentication with a carefully-chosen salt (like 0)?
I doubt the latter is a problem; AFAIK there are no weak salt values
in crypt() --- remember the salt is not a key.
However, the relatively small number of legal salt values (4096 IIRC)
is a weakness; an attacker who'd sniffed one encrypted password could
hope to get in by repeatedly connecting until he's challenged with
that same salt, and then he just gives the captured encrypted password.
If the salt-choosing code has any predictability then it might take
much less than ~4K tries, but that number is too small anyway.
I thought one of the major reasons for switching to a new protocol
is that we could include much wider random salt values in it, so
as to render that sort of attack impractical.
As for man-in-the-middle attacks, stealing passwords is the least
of our worries in that scenario --- the attacker could just wait
for login to complete and then insert his own queries into the
conversation. I think we have to rely on end-to-end encryption
like SSH or SSL to defend against that sort of thing.
> We are not in the business of creating security protocols. IMHO we
> should leave that to the people who are. If we want something better
> than the password scheme we have then we should adopt an existing
> standard.
Aw, that's no fun :-). But you're right, we should look to see if there
are existing standards that meet all the criteria we are looking for.
> Out of curiosity does SecurityFocus.com also criticise pppd for the
> same "problem"?
I checked and in fact there is nothing official about this "criticism";
it's just one message posted on a web bbs by someone with no obvious
credentials. Still, given the other headaches that reliance on crypt()
causes us, it seems to make sense to work on a replacement password
scheme that deals with more problems than just cleartext password
storage.
regards, tom lane
Tom Lane wrote: >> Also this will be pretty tricky to get to work for groups. (That >> pg_group table really needs a redesign.)> >True. I'm inclined to think that should be looked at in the context >of the schema support that people havebeen muttering about --- maybe >groups can be replaced by schemas somehow? (Just a thought, maybe a >half-baked one.) Please don't lose group support; it is a separate issue from schemas. If schemas were available, I would use them to separate or subdivide projects. For example, a financial accounting system would logically divide into modules, some of which would be universally required (general ledger, base support, etc.) and some of which would be of interest to smaller groups of customers (sales ledger, order processing, inventory control, payroll). Each of these modules would contain a logically separable set of data elements (tables, views, etc.). However, add-on modules are very likely to need to access data from other modules. I would use schemas to implement these modules and they could cross-refer to each other with the specification `schema.table.column'. It should be possible for separate schemas to be housed on different machines, linked by networking. Different sets of users need to access different parts of the data, in different ways. This is not necessarily related to the separation of modules. For example, the directors of a company might have private loan accounts in the general ledger module, and their pay would be handled by the payroll module; it is likely that access to their records would be heavily restricted. This is more easily done by group privileges, by giving restricted access to a "directors" group, than by trying to split the database schema down further. Similarly, where there is extensive separation of duties, one group may have write access for payments but not for invoices. Finally, use of groups makes it far easier to handle the privileges of new employees. It is much easier to make a new employee a member of the "buyers" group than to grant access rights individually to each of a number of tables, spread across several schemas. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID32B8FAA1 ======================================== "Therefore, my beloved brethren, be ye stedfast, unmoveable, always abounding in the work of the Lord, forasmuch as ye know that your labour is not in vain in the Lord." I Corinthians 15:58