Thread: Solution to the pg_user passwd problem !?? (c)
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)
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) > >
Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)
From
jwieck@debis.com (Jan Wieck)
Date:
>
> 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) #
> > 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
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...
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) # > >
Re: [HACKERS] Solution to the pg_user passwd problem !?? (c)
From
darcy@druid.net (D'Arcy J.M. Cain)
Date:
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.
> > > 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
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?
> > 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
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
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
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
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
> 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, -- --------------------------------------------- G�ran Thyni, sysadm, JMS Bildbasen, Kiruna
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"
> 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)
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
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