Thread: How to deny user changing his own password?
Hi My question is in subject. How can I deny user changing his own password using ALTER USER user WITH PASSWORD 'password'; ? Thanks adeon
adeon wrote: > Hi > > My question is in subject. > How can I deny user changing his own password using > ALTER USER user WITH PASSWORD 'password'; ? AFAIK you can't, IMHO you shouldn't anyway and I would object against such useless feature. Jan > > Thanks > adeon > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Now I think about this it would be useful: I have an Access database which connects to postgres and the password is saved in the access frontend. If someone (not sure how!) runs ALTER USER ..... WITH PASSWORD '....'; via the frontend they could disrupt the connection to the postgres backend. I'm sure a similar situation could happen with PHP or similar as you often don't use the postgres security features to secure your application.
Regards,
Ben Trewern
-----Original Message-----
From: Jan Wieck [mailto:JanWieck@Yahoo.com]
Sent: 29 May 2003 14:52
To: adeon
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] How to deny user changing his own password?
adeon wrote:
> Hi
>
> My question is in subject.
> How can I deny user changing his own password using
> ALTER USER user WITH PASSWORD 'password'; ?
AFAIK you can't, IMHO you shouldn't anyway and I would object against such useless feature.
Jan
>
> Thanks
> adeon
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
*****************************************************************************
This email and any attachments transmitted with it are confidential
and intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the sender and do not store, copy or disclose the content
to any other person.
It is the responsibility of the recipient to ensure that opening this
message and/or any of its attachments will not adversely affect
its systems. No responsibility is accepted by the Company.
*****************************************************************************
Trewern, Ben wrote: > Now I think about this it would be useful: I have an Access database > which connects to postgres and the password is saved in the access > frontend. If someone (not sure how!) runs ALTER USER ..... WITH > PASSWORD '....'; via the frontend they could disrupt the connection to > the postgres backend. I'm sure a similar situation could happen with > PHP or similar as you often don't use the postgres security features to > secure your application. This is the second worst possible reason I can imagine for a feature like this. Passwords coded into the frontend ... gosh! Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
> This is the second worst possible reason I can imagine for a feature > like this. Passwords coded into the frontend ... gosh! Depending on the application, coding a password into the front end can be a necessary condition. Think of a PHP web page script that makes database calls. How are you going to prevent other unauthorized connections from that system? Passwords aren't a perfect security device, but they're generally better than no password. I could see some merit to a 'LOCK' option on the alter user command, so that the password can only be changed by a superuser. -- Mike Nolan
On Thu, May 29, 2003 at 13:18:01 -0500, nolan@celery.tssi.com wrote: > > This is the second worst possible reason I can imagine for a feature > > like this. Passwords coded into the frontend ... gosh! > > Depending on the application, coding a password into the front end can > be a necessary condition. Think of a PHP web page script that makes > database calls. How are you going to prevent other unauthorized > connections from that system? Passwords aren't a perfect security > device, but they're generally better than no password. You can use ident authentication. > I could see some merit to a 'LOCK' option on the alter user command, so that > the password can only be changed by a superuser. That would only be useful if the account was shared, which is normally a bad idea.
I was actually thinking the same thing. Typically the use for a web user runs a system user with minimalistic permissions on the other hand, the **database** user that any CGI scripts connect to the database as need permissions to the database resources- two entirely different things. Unless you choose to have different DB user for each application with a web interface, you might be faced with a serious problem if the DB user's account password gets changed since that DB user's account is effectively used for several applications. Quoting nolan@celery.tssi.com: > > This is the second worst possible reason I can imagine for a feature > > like this. Passwords coded into the frontend ... gosh! > > Depending on the application, coding a password into the front end can > be a necessary condition. Think of a PHP web page script that makes > database calls. How are you going to prevent other unauthorized > connections from that system? Passwords aren't a perfect security > device, but they're generally better than no password. > > I could see some merit to a 'LOCK' option on the alter user command, so that > > the password can only be changed by a superuser. > -- > Mike Nolan > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > -- Keith C. Perry Director of Networks & Applications VCSN, Inc. http://vcsn.com ____________________________________ This email account is being host by: VCSN, Inc : http://vcsn.com
Bruno Wolff III <bruno@wolff.to> writes:
> nolan@celery.tssi.com wrote:
>> I could see some merit to a 'LOCK' option on the alter user command, so that
>> the password can only be changed by a superuser.
> That would only be useful if the account was shared, which is normally a bad
> idea.
It'd seem to me that once a bad guy has gotten into your database,
whether he can change a password is the least of your worries.
The people you'd really want to be afraid of would not call attention
to their breakin by doing anything as blatantly obvious as that, anyway.
In short, I don't see any value in a password lock option either.
And ISTM anyplace that used it would be getting in the way of good
password management practice. Users *should* be encouraged to change
their own passwords, and to do so regularly.
regards, tom lane
On Thu, May 29, 2003 at 05:36:04PM +0100, Trewern, Ben wrote: > Now I think about this it would be useful: I have an Access database which > connects to postgres and the password is saved in the access frontend. If > someone (not sure how!) runs ALTER USER ..... WITH PASSWORD '....'; via the > frontend they could disrupt the connection to the postgres backend. I'm > sure a similar situation could happen with PHP or similar as you often don't > use the postgres security features to secure your application. Not sure with Access, but in general when running something backed by a database you should not just allow arbitrary SQL reach the database. There should be no way for any user of the application to execute an ALTER USER query. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Before you were born your parents weren't as boring as they are now. They got that way paying your bills, cleaning up your room and listening to you tell them how idealistic you are." -- Charles J. Sykes' advice to teenagers
> In short, I don't see any value in a password lock option either.
It seems to me that if I can give a user 'read only' access to a database,
I should be able to give 'read only' access in every aspect, including
locking down the password.
> And ISTM anyplace that used it would be getting in the way of good
> password management practice. Users *should* be encouraged to change
> their own passwords, and to do so regularly.
No real argument there, but is an application a 'user' in the ordinary
sense of the word? Would you, as DBA, prefer a locked-down password or
one that you might have to change in dozens of locations?
It seems me that the underlying issue of how to authenticate access
from an 'outside' and compromiseable client may not be easily solveable.
Locking down the password falls under the category of 'damage control'.
('Inside' clients can be compromised too, of course.)
I'm not sure 'ident' solves the problem any better than an embedded password
does, and the documentation on ident raises this red flag:
This authentication method is therefore only appropriate for
closed networks where each client machine is under tight control
and where the database and system administrators operate in close
contact. In other words, you must trust the machine running the
ident server. Heed the warning:
The Identification Protocol is not intended as an authorization
or access control protocol. --RFC 1413
--
Mike Nolan
On Thu, May 29, 2003 at 17:09:18 -0500, nolan@celery.tssi.com wrote: > > I'm not sure 'ident' solves the problem any better than an embedded password > does, and the documentation on ident raises this red flag: If you want to run applications that connect to your DB from untrusted hosts there probably isn't any good solution. If you are connecting from untrusted networks, than you may want to set up an authenticated tunnel which you can then use for connecting to the DB. However, neither of these are the normal case. Ident authentication is better than password authentication because it is bound to the machine. Someone can't change it out from under or take it with them to use from another machine. > > This authentication method is therefore only appropriate for > closed networks where each client machine is under tight control > and where the database and system administrators operate in close > contact. In other words, you must trust the machine running the > ident server. Heed the warning: > > The Identification Protocol is not intended as an authorization > or access control protocol. --RFC 1413 Note that for applications running on the DB server you don't have to use an RFC 1413 server. On server common operating systems you can find out the user id of the process connecting to you via domain sockets. This is as good as whatever the user used to authenticate to the OS.