Skip site navigation (1) Skip section navigation (2)

securing PHP/Postgresql (was: MD5 in pg and php)

From: Joolz <joolz(at)xs4all(dot)nl>
To: list-postgresql-php <pgsql-php(at)postgresql(dot)org>
Subject: securing PHP/Postgresql (was: MD5 in pg and php)
Date: 2004-04-29 16:57:23
Message-ID: 20040429165723.GA18588@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-php
> [Bruno Wolff III schreef op 29-04-2004 05:11 -0500]
> On Thu, Apr 29, 2004 at 09:07:16 +0200,
>   Joolz <joolz(at)xs4all(dot)nl> wrote:
> > 
> > I want to store passwords in a pg db, MD5 seems like a good way to
> > enhance security (no more plaintext passwords over the line etc.)
> > I had a look at MD5, in PHP 4.3.4 there is a function md5() which
> > seems to work nicely:
> This may not help as much as you think. If you are using an ssl
> connection, the passwords won't be sent in the clear. If you aren't
> using an ssl connection the hashes will be in clear. I don't believe
> the postgres uses a random challenge so that you won't really raise
> the bar much.  Plus if snooping passwords is a threat, most likely
> snooping data will be as well (though not always) and forcing
> connections to use ssl may be your best bet. I believe as typically
> used this is vulnerable to man in the middle attacks, but these are
> going to be significantly harder to do than simple snooping.

Thanks for the tip. I already have things like:

  if (ini_get('register_globals') === 1) {
    say it's not safe, don't enter the application }


  if (!isset($_SERVER['HTTPS']) || $_SERVER['HTTPS'] !== 'on') {
    idem }

in my login screen. Still, I would feel more assured if passwords go
over the line md5()'d, even if that line is encrypted.

I have other things to worry about next. Right now I let the user
enter the pg username and password, store these values in session
variables and use them every time a database connection is needed.

Someone told me this is very insecure, as the session variables are
stored in either /tmp on the server (that's where I have them put), in
a local cookie or in the URL. Neither would be safe, a better approach
would be to authenticicate once (by looking up the user + password in
a table), and give access to certain tables, views etc. based on the
result of the first lookup; the result being different roles in the
organisation who have access to certain views etc. or a simple 'false'
if the password is wrong.

I have to think about it long and hard :-), the extra "layer" makes
things more secure, I would only have to register username (for
auditing purposes) plus the "role" in session variables, which could
be md5()'d. Still, the extra layer is from a logical point of view
redundant and thus errorprone.

Still, it might be a good idea. If anyone cares to share their opinion
on the matter (or discuss how you handled this), TIA!

Fedora Core release 1 (Yarrow) Linux 2.4.22-1.2188.nptl

In response to


pgsql-php by date

Next:From: Andrew McMillanDate: 2004-05-01 12:07:26
Subject: Re: securing PHP/Postgresql (was: MD5 in pg and php)
Previous:From: Viorel DragomirDate: 2004-04-29 11:42:26
Subject: Re: Question regarding session

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group