Horton

Thread

  1. Solution to the pg_user passwd problem !?? (c)

    Zeugswetter Andreas <andreas.zeugswetter@telecom.at> — 1998-02-19T13:59:48Z

    Hi all,

What about:
grant select on pg_user to public;
create rule pg_user_hide_pw as on
select to pg_user.passwd
do instead select '********' as passwd;

Then if I do:
select * from pg_user;
usename |usesysid|usecreatedb|usetrace|usesuper|usecatupd|passwd  |valuntil
--------+--------+-----------+--------+--------+---------+--------+---------
-------------------
postgres|       6|t          |t       |t       |t        |********|Sat Jan
31 07:00:00 2037 NFT
zeus    |      60|t          |t       |f       |t        |********|
(2 rows)

Also the \d works for all users !

Only "disadvantage" is that noone can read passwd without first dropping the
rule pg_user_hide_pw,
I consider this a feature though ;-)

Since the userauthentication bypasses the rewrite mechanism the logins,
alter user .. and others do work !

Can all of you try to crack this ?

(c) Andreas Zeugswetter

Copyright by Andreas Zeugswetter 1998 contributed to the postgresql project
;-)
Wow, I am actually proud of this (so far, and hope it holds what I think it
does)

  2. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Marc G. Fournier <scrappy@hub.org> — 1998-02-19T14:14:36Z

    I like it!!!  I'm going to do a fresh buildl and try this out, and see if
Julie/I can get that ODBC driver working with this...*cross fingers*

Bruce...do see anyting particularly bad about this?



On Thu, 19 Feb 1998, Zeugswetter Andreas SARZ wrote:

> Hi all,
> 
> What about:
> grant select on pg_user to public;
> create rule pg_user_hide_pw as on
> select to pg_user.passwd
> do instead select '********' as passwd;
> 
> Then if I do:
> select * from pg_user;
> usename |usesysid|usecreatedb|usetrace|usesuper|usecatupd|passwd  |valuntil
> --------+--------+-----------+--------+--------+---------+--------+---------
> -------------------
> postgres|       6|t          |t       |t       |t        |********|Sat Jan
> 31 07:00:00 2037 NFT
> zeus    |      60|t          |t       |f       |t        |********|
> (2 rows)
> 
> Also the \d works for all users !
> 
> Only "disadvantage" is that noone can read passwd without first dropping the
> rule pg_user_hide_pw,
> I consider this a feature though ;-)
> 
> Since the userauthentication bypasses the rewrite mechanism the logins,
> alter user .. and others do work !
> 
> Can all of you try to crack this ?
> 
> (c) Andreas Zeugswetter
> 
> Copyright by Andreas Zeugswetter 1998 contributed to the postgresql project
> ;-)
> Wow, I am actually proud of this (so far, and hope it holds what I think it
> does)
> 
>

  3. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T14:50:32Z

    > 
> Hi all,
> 
> What about:
> grant select on pg_user to public;
> create rule pg_user_hide_pw as on
> select to pg_user.passwd
> do instead select '********' as passwd;

When I see this, the word 'genius' comes to mind.  What a brilliantly
elegant solution to the problem.

> 
> Then if I do:
> select * from pg_user;
> usename |usesysid|usecreatedb|usetrace|usesuper|usecatupd|passwd  |valuntil
> --------+--------+-----------+--------+--------+---------+--------+---------
> -------------------
> postgres|       6|t          |t       |t       |t        |********|Sat Jan
> 31 07:00:00 2037 NFT
> zeus    |      60|t          |t       |f       |t        |********|
> (2 rows)
> 
> Also the \d works for all users !
> 
> Only "disadvantage" is that noone can read passwd without first dropping the
> rule pg_user_hide_pw,
> I consider this a feature though ;-)
> 
> Since the userauthentication bypasses the rewrite mechanism the logins,
> alter user .. and others do work !
> 
> Can all of you try to crack this ?
> 
> (c) Andreas Zeugswetter
> 
> Copyright by Andreas Zeugswetter 1998 contributed to the postgresql project
> ;-)
> Wow, I am actually proud of this (so far, and hope it holds what I think it
> does)
> 
> 
> 


-- 
Bruce Momjian
maillist@candle.pha.pa.us

  4. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Jan Wieck <jwieck@debis.com> — 1998-02-19T14:55:07Z

    >
> Hi all,
>
> What about:
> grant select on pg_user to public;
> create rule pg_user_hide_pw as on
> select to pg_user.passwd
> do instead select '********' as passwd;
>
> Then if I do:
> select * from pg_user;
> usename |usesysid|usecreatedb|usetrace|usesuper|usecatupd|passwd  |valuntil
> --------+--------+-----------+--------+--------+---------+--------+---------
> -------------------
> postgres|       6|t          |t       |t       |t        |********|Sat Jan
> 31 07:00:00 2037 NFT
> zeus    |      60|t          |t       |f       |t        |********|
> (2 rows)
>
> Also the \d works for all users !
>
> Only "disadvantage" is that noone can read passwd without first dropping the
> rule pg_user_hide_pw,
> I consider this a feature though ;-)
>
> Since the userauthentication bypasses the rewrite mechanism the logins,
> alter user .. and others do work !
>
> Can all of you try to crack this ?

    Cracked!

    create table get_passwds (usename name, passwd text);
    insert into get_passwds select usename, passwd from pg_user;
    select * from get_passwds;
    usename|passwd
    -------+------
    pgsql  |
    wieck  |test
    (2 rows)



Sorry, Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #

  5. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Marc G. Fournier <scrappy@hub.org> — 1998-02-19T14:58:53Z

    On Thu, 19 Feb 1998, Jan Wieck wrote:

> >
> > Hi all,
> >
> > What about:
> > grant select on pg_user to public;
> > create rule pg_user_hide_pw as on
> > select to pg_user.passwd
> > do instead select '********' as passwd;
> >
> > Then if I do:
> > select * from pg_user;
> > usename |usesysid|usecreatedb|usetrace|usesuper|usecatupd|passwd  |valuntil
> > --------+--------+-----------+--------+--------+---------+--------+---------
> > -------------------
> > postgres|       6|t          |t       |t       |t        |********|Sat Jan
> > 31 07:00:00 2037 NFT
> > zeus    |      60|t          |t       |f       |t        |********|
> > (2 rows)
> >
> > Also the \d works for all users !
> >
> > Only "disadvantage" is that noone can read passwd without first dropping the
> > rule pg_user_hide_pw,
> > I consider this a feature though ;-)
> >
> > Since the userauthentication bypasses the rewrite mechanism the logins,
> > alter user .. and others do work !
> >
> > Can all of you try to crack this ?
> 
>     Cracked!
> 
>     create table get_passwds (usename name, passwd text);
>     insert into get_passwds select usename, passwd from pg_user;
>     select * from get_passwds;
>     usename|passwd
>     -------+------
>     pgsql  |
>     wieck  |test
>     (2 rows)

Okay, its moving in the right direction though...is there a flaw in the
rules system that allows this to get around this in this manner?  Nice
thing about this is that it doesn't require any 'front end' rewrites,
which is a good thing...

IMHO, this is an acceptable solution to the problem for v6.3s
release...better then ripping out the code altogether...

  6. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Brett McCormick <brett@work.chicken.org> — 1998-02-19T17:47:47Z

    Have we considering using the unix crypt function for passwords?  That
way it wouldn't matter (as much) if people saw the password, and would
still be (somewhat less) secure.

On Thu, 19 February 1998, at 15:55:07, Jan Wieck wrote:

>     Cracked!
> 
>     create table get_passwds (usename name, passwd text);
>     insert into get_passwds select usename, passwd from pg_user;
>     select * from get_passwds;
>     usename|passwd
>     -------+------
>     pgsql  |
>     wieck  |test
>     (2 rows)
> 
> 
> 
> Sorry, Jan
> 
> --
> 
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me.                                  #
> #======================================== jwieck@debis.com (Jan Wieck) #
> 
>

  7. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    D'Arcy Cain <darcy@druid.net> — 1998-02-19T17:55:45Z

    Thus spake Brett McCormick
> Have we considering using the unix crypt function for passwords?  That
> way it wouldn't matter (as much) if people saw the password, and would
> still be (somewhat less) secure.

That's what I do.  I have both a Tcl and a Python function to encrypt
the password and that's how I store them.  You still want to protect
them somewhat but it isn't quite as critical as plain tex passwords.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

  8. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T18:16:23Z

    > 
> 
> Have we considering using the unix crypt function for passwords?  That
> way it wouldn't matter (as much) if people saw the password, and would
> still be (somewhat less) secure.
> 
> On Thu, 19 February 1998, at 15:55:07, Jan Wieck wrote:

I don't know what the problem with using crypt was.  It may be because
he passes a random salt to the user, and the user makes the password
packet with the given salt and returns it to the backend.  If we use
crypt, we have to send a plaintext password over the network, don't we?


-- 
Bruce Momjian
maillist@candle.pha.pa.us

  9. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Marc G. Fournier <scrappy@hub.org> — 1998-02-19T18:34:01Z

    On Thu, 19 Feb 1998, Bruce Momjian wrote:

> > 
> > 
> > Have we considering using the unix crypt function for passwords?  That
> > way it wouldn't matter (as much) if people saw the password, and would
> > still be (somewhat less) secure.
> > 
> > On Thu, 19 February 1998, at 15:55:07, Jan Wieck wrote:
> 
> I don't know what the problem with using crypt was.  It may be because
> he passes a random salt to the user, and the user makes the password
> packet with the given salt and returns it to the backend.  If we use
> crypt, we have to send a plaintext password over the network, don't we?

	But, aren't we doing that now?

  10. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T18:56:18Z

    > 
> On Thu, 19 Feb 1998, Bruce Momjian wrote:
> 
> > > 
> > > 
> > > Have we considering using the unix crypt function for passwords?  That
> > > way it wouldn't matter (as much) if people saw the password, and would
> > > still be (somewhat less) secure.
> > > 
> > > On Thu, 19 February 1998, at 15:55:07, Jan Wieck wrote:
> > 
> > I don't know what the problem with using crypt was.  It may be because
> > he passes a random salt to the user, and the user makes the password
> > packet with the given salt and returns it to the backend.  If we use
> > crypt, we have to send a plaintext password over the network, don't we?
> 
> 	But, aren't we doing that now? 

Yes, we are using crypt.  We are picking a random salt, using crypt to
encrypt the cleartext password, then sending the salt to the frontend,
and asking them to supply a password crypted with our requested salt.

Anyway to do this while storing encrypted passwords?

-- 
Bruce Momjian
maillist@candle.pha.pa.us

  11. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Phil Thompson <phil@river-bank.demon.co.uk> — 1998-02-19T22:47:59Z

    Bruce Momjian wrote:
> 
> >
> > On Thu, 19 Feb 1998, Bruce Momjian wrote:
> >
> > > >
> > > >
> > > > Have we considering using the unix crypt function for passwords?  That
> > > > way it wouldn't matter (as much) if people saw the password, and would
> > > > still be (somewhat less) secure.
> > > >
> > > > On Thu, 19 February 1998, at 15:55:07, Jan Wieck wrote:
> > >
> > > I don't know what the problem with using crypt was.  It may be because
> > > he passes a random salt to the user, and the user makes the password
> > > packet with the given salt and returns it to the backend.  If we use
> > > crypt, we have to send a plaintext password over the network, don't we?
> >
> >       But, aren't we doing that now?
> 
> Yes, we are using crypt.  We are picking a random salt, using crypt to
> encrypt the cleartext password, then sending the salt to the frontend,
> and asking them to supply a password crypted with our requested salt.

A benefit of this approach (which I think is valuable) is that, as far
as sniffing the network is concerned, one-time passwords are used.

> Anyway to do this while storing encrypted passwords?

How UNIX specific is crypt()? At the moment the same password can be
used with clients that support crypt(), and send the password encrypted,
and those that don't, and send the password in clear.

If you want to store encrypted passwords then the encryption method used
must be supported by all types of client - or be included as part of the
PostgreSQL distribution.

Phil

  12. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    ocie@paracel.com — 1998-02-19T23:25:56Z

    Bruce Momjian wrote:
> 
> > 
> > On Thu, 19 Feb 1998, Bruce Momjian wrote:
> > 
> > > > 
> > > > 
> > > > Have we considering using the unix crypt function for passwords?  That
> > > > way it wouldn't matter (as much) if people saw the password, and would
> > > > still be (somewhat less) secure.
> > > > 
> > > > On Thu, 19 February 1998, at 15:55:07, Jan Wieck wrote:
> > > 
> > > I don't know what the problem with using crypt was.  It may be because
> > > he passes a random salt to the user, and the user makes the password
> > > packet with the given salt and returns it to the backend.  If we use
> > > crypt, we have to send a plaintext password over the network, don't we?
> > 
> > 	But, aren't we doing that now? 
> 
> Yes, we are using crypt.  We are picking a random salt, using crypt to
> encrypt the cleartext password, then sending the salt to the frontend,
> and asking them to supply a password crypted with our requested salt.
> 
> Anyway to do this while storing encrypted passwords?

Standard salt is two characters, so an adversary might be able to
watch and record which salts produced which replies.  Even with a
single login, a brute force attack might still be able to get the
user's password.  A stronger challenge-response system might be more
secure.  It should be possible for the server to authenticate a user
without having to store the user's password.

Then again, this is all starting to sound like Kerberos, so if
Postgres had Kerberos authentication (which I think it does), then
this could be used for the ultra-high security authentication system.

Ocie Mitchell

  13. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Brett McCormick <brett@work.chicken.org> — 1998-02-20T03:03:55Z

    What about a public/private key mechanism, like ssh?

On Thu, 19 February 1998, at 15:25:56, ocie@paracel.com wrote:

> Standard salt is two characters, so an adversary might be able to
> watch and record which salts produced which replies.  Even with a
> single login, a brute force attack might still be able to get the
> user's password.  A stronger challenge-response system might be more
> secure.  It should be possible for the server to authenticate a user
> without having to store the user's password.
> 
> Then again, this is all starting to sound like Kerberos, so if
> Postgres had Kerberos authentication (which I think it does), then
> this could be used for the ultra-high security authentication system.
> 
> Ocie Mitchell

  14. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Peter T Mount <psqlhack@maidast.demon.co.uk> — 1998-02-21T10:40:24Z

    On Thu, 19 Feb 1998, Phil Thompson wrote:

> How UNIX specific is crypt()? At the moment the same password can be
> used with clients that support crypt(), and send the password encrypted,
> and those that don't, and send the password in clear.
> 
> If you want to store encrypted passwords then the encryption method used
> must be supported by all types of client - or be included as part of the
> PostgreSQL distribution.

To implement the current crypt authentication in the JDBC driver, we had
to supply a crypt class.

	src/interfaces/jdbc/postgresql/util/UnixCrypt.java

> 
> Phil
> 

-- 
Peter T Mount  petermount@earthling.net or pmount@maidast.demon.co.uk
Main Homepage: http://www.demon.co.uk/finder
Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk

  15. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Goran Thyni <goran@bildbasen.se> — 1998-02-26T16:35:18Z

    >   What about a public/private key mechanism, like ssh?

Yes, just use ssh as-is and run psql etc in a ssh tunnel
when running over insecure nets.

Making cryptography part of pgsql is not good idea for two reasons:
1. It is bloat
2. It make us targets of legal-problems (US-export-control etc).

IMHO, even Kerberous should be removed.

info about ssh is available at:

http://www.cs.hut.fi/ssh/ free version
http://www.ssh.fi/ commercial (+mac/windows) versions

      regards,
-- 
---------------------------------------------
Gran Thyni, sysadm, JMS Bildbasen, Kiruna

  16. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Tom Ivar Helbekkmo <tih@hamartun.priv.no> — 1998-02-26T21:58:36Z

    On Thu, Feb 26, 1998 at 04:35:18PM -0000, Goran Thyni wrote:

> Yes, just use ssh as-is and run psql etc in a ssh tunnel
> when running over insecure nets.

It is not the case that ssh is a complete replacement for anything and
everything in the way of authentication, authorization and encryption.
Among other things, "just use an ssh tunnel" means you have to have
had a previous out-of-band exchange of keys between the end-points for
the authentication to be completely secure.  Thus, ssh does not by
itself scale very well.  (This is, of course, the reason why Kerberos
is supported as an authentication method in recent versions of ssh.
This is good for people who use Kerberos 5, the version that ssh now
supports, but only people inside the US can legally do that, and for
those of us who still use Kerberos IV (I legally run the version from
KTH, in Sweden, both at home and at work), ssh won't always cut it.)

> IMHO, even Kerberous should be removed.

I strongly disagree.  On the off chance that the ability to utilize
cryptographic software not even included in the release somehow makes
PosgreSQL a weapon in the eyes of the US government, I guess it would
be necessary to remove it, but I can't believe that their laws can be
so mind-bogglingly stupid?  If this is the case, shouldn't /bin/cat be
export restricted, because you can use it to stuff text into software
that encrypts it?

Kerberos itself is export restricted, because it contains software
that implements cryptographic functions (specifically, the Top Secret
algorithm called DES, which it would mean the end of civilization as
we know it if anyone outside the US found out how it works), but this
surely cannot mean that anything that can use Kerberos is tainted?

The operating system I use the most, NetBSD, comes with the ability to
use Kerberos authentication present in various program sources, but
the actual Kerberos IV source code is in a separate, export restricted
package.  At a US site, when this is installed, you can compile the
sources in question with proper -D flags to enable the calls to the
Kerberos functions.  I've always understood this to be entirely legal.

Anyway, if it should at some point be decided to strip PostgreSQL of
any way of even calling user supplied cryptographic functions, PLEASE
don't do this without creating a clean, documented framework for
adding authentication methods to the system, so that those of us who
need secure authentication can reintegrate Kerberos and the like on
our own...

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"

  17. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-27T03:14:54Z

    > Anyway, if it should at some point be decided to strip PostgreSQL of
> any way of even calling user supplied cryptographic functions, PLEASE
> don't do this without creating a clean, documented framework for
> adding authentication methods to the system, so that those of us who
> need secure authentication can reintegrate Kerberos and the like on
> our own...

Don't worry.  Kerberos support is not going to be change, only improved
if we can.  I always liked Kerberos.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

  18. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Michael Graff <explorer@flame.org> — 1998-03-05T00:58:55Z

    Brett McCormick <brett@work.chicken.org> writes:

> Have we considering using the unix crypt function for passwords?  That
> way it wouldn't matter (as much) if people saw the password, and would
> still be (somewhat less) secure.

I would MUCH rather see MD5, salted with the username.

--Michael

  19. Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Michael Graff <explorer@flame.org> — 1998-03-05T01:05:36Z

    Goran Thyni <goran@bildbasen.se> writes:

> IMHO, even Kerberous should be removed.

No, it should be fixed, not removed.  I would very much like to use krb5
authentication.

My main problem with the whole authentication system is that there can only
be one global method.  That is, everything is password based, on one
password per user.

I would think a good method would have the (username, auth-data) stored
together, but you could have multiple (username, auth-data) tuples.  For
instance, I might have a Kerberos5 authentication:

	usename		authtype	authdata
	---------------	---------------	------------------------------
	explorer	krb5		explorer@FLAME.ORG
	explorer	md5		4f1929cbca91deadbeef0123...
	explorer	cryptpw		UNIX-standard crypted string
	explorer	plainpw		password

Then I can control how someone connects down to a method.  I could
allow different methods for different trust levels.  I might trust my
local, server machine with just a password, but deny access to the rest
of the net unless they use Kerberos5.

--Michael