From: "Mark R. Dingee" <mark.dingee@cox.net>
To: pgsql-sql@postgresql.org
Subject: Re: PGSQL encryption functions
Date: Wed, 2 Nov 2005 16:01:19 -0500
User-Agent: KMail/1.8.2
Cc: Bruno Wolff III <bruno@wolff.to>
References: <200511011438.06610.mark.dingee@cox.net>
	<200511011700.50776.mark.dingee@cox.net>
	<20051102185930.GA10108@wolff.to>
In-Reply-To: <20051102185930.GA10108@wolff.to>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200511021601.20138.mark.dingee@cox.net>

Thanks Bruno.  I'm using a hash so I can merge info available in the HTTPS 
header with data I store on the server so that the hash can be reconstructed 
during the validation process from the raw elements.  Tom Lane reminded me of 
using random seeds similar to what you are suggesting.  I think I will try to 
incorporate that into the process.  Perhaps a segment from the initial 
SSL_SESSION_ID may work without generating too much overhead.

You're right, sniffing isn't a real concern for me in this application.  My 
biggest concern is internal users playing around trying to find a backdoor 
into sensitive data.

Thanks
Mark

On Wednesday 02 November 2005 01:59 pm, Bruno Wolff III wrote:
> On Tue, Nov 01, 2005 at 17:00:50 -0500,
>
>   "Mark R. Dingee" <mark.dingee@cox.net> wrote:
> > Bruno,
> >
> > I use an authenticate() function as a part of state maintenance in a PHP
> > web app.  In the function, I generate an encrypted token that is then
> > used in the validation process on subsequent pages.  md5 works, but I've
> > been able to brute-force crack it very quickly, so I'm looking for an
> > alternative.  Any thoughts would be greatly appreciated.
>
> This isn't a problem with MD5. While MD5 does have some theoretical
> weaknesses, they aren't really an issue in this case.
>
> Why are you using a hash at all? If you are using the hash as a key, why
> not just use a random string instead? The web browser could be handed a
> session id and random string and on the server you would have a table
> indexed by session ids that includes the random string.
>
> On many systems you can use /dev/urandom as a source of random data. Since
> you don't seem to be concerned about sniffing, /dev/random is probably
> overkill and having it block when low on entropy would probably be a
> problem for you.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend