You're on SecurityFocus.com for the cleartext passwords.

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.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at 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/&gt; 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, Pennsylvania 19026

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.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at 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 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?

-- 
  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

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.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at 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, Pennsylvania 19026

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, Pennsylvania 19026

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.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at 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, Pennsylvania 19026

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, Pennsylvania 19026

[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/&gt; 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 = "Password crypt 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.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

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, Pennsylvania 19026

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.