securing PHP/Postgresql (was: MD5 in pg and php) - Mailing list pgsql-php

From Joolz
Subject securing PHP/Postgresql (was: MD5 in pg and php)
Date
Msg-id 20040429165723.GA18588@localhost.localdomain
Whole thread Raw
In response to Re: MD5 in pg and php  (Bruno Wolff III <bruno@wolff.to>)
Responses Re: securing PHP/Postgresql (was: MD5 in pg and php)
List 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@xs4all.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 }

and

  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!

--
18:38-18:57
Fedora Core release 1 (Yarrow) Linux 2.4.22-1.2188.nptl

pgsql-php by date:

Previous
From: "Viorel Dragomir"
Date:
Subject: Re: Question regarding session
Next
From: Andrew McMillan
Date:
Subject: Re: securing PHP/Postgresql (was: MD5 in pg and php)