From: Mark R. Dingee <mark.dingee@cox.net>
To: pgsql-sql@postgresql.org
Cc: Bruno Wolff III <bruno@wolff.to>
Subject: Re: PGSQL encryption functions
Date: Wed, 2 Nov 2005 16:01:19 -0500
Message-ID: <200511021601.20138.mark.dingee@cox.net> (raw)
In-Reply-To: <20051102185930.GA10108@wolff.to>
References: <200511011438.06610.mark.dingee@cox.net>
<200511011700.50776.mark.dingee@cox.net>
<20051102185930.GA10108@wolff.to>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: mark.dingee@cox.net, bruno@wolff.to
Subject: Re: PGSQL encryption functions
In-Reply-To: <200511021601.20138.mark.dingee@cox.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox