Thread: PGSQL encryption functions

PGSQL encryption functions

From
"Mark R. Dingee"
Date:
<p>Everyone,<p><p>I'm in need of a one-way pgsql script that will take a plain-text string and return an ecrypted
string(preferably 32 character) . I've been using md5('string'), but I'm concerned it's too weak for my needs. Does
anyonehave any recommendations?<p><p>Thanks,<p>Mark 

Re: PGSQL encryption functions

From
Josh Berkus
Date:
Mark,

> I'm in need of a one-way pgsql script that will take a plain-text string
> and return an ecrypted string (preferably 32 character) .  I've been
> using md5('string'), but I'm concerned it's too weak for my needs.  Does
> anyone have any recommendations?

You check out pgcrypto in /contrib in the PostgreSQL source?

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco


Re: PGSQL encryption functions

From
Bruno Wolff III
Date:
On Tue, Nov 01, 2005 at 14:38:05 -0500, "Mark R. Dingee" <mark.dingee@cox.net> wrote:
> Everyone,
> 
> I'm in need of a one-way pgsql script that will take a plain-text string and return an ecrypted string (preferably 32
character).  I've been using md5('string'), but I'm concerned it's too weak for my needs.  Does anyone have any
recommendations?

What are your needs?


Re: PGSQL encryption functions

From
"Mark R. Dingee"
Date:
I'll check it out.  Thanks, Josh

On Tuesday 01 November 2005 02:49 pm, Josh Berkus wrote:
> Mark,
>
> > I'm in need of a one-way pgsql script that will take a plain-text string
> > and return an ecrypted string (preferably 32 character) .  I've been
> > using md5('string'), but I'm concerned it's too weak for my needs.  Does
> > anyone have any recommendations?
>
> You check out pgcrypto in /contrib in the PostgreSQL source?




Re: PGSQL encryption functions

From
"Mark R. Dingee"
Date:
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.

Thanks,
Mark

On Tuesday 01 November 2005 04:28 pm, Bruno Wolff III wrote:
> On Tue, Nov 01, 2005 at 14:38:05 -0500,
>
>   "Mark R. Dingee" <mark.dingee@cox.net> wrote:
> > Everyone,
> >
> > I'm in need of a one-way pgsql script that will take a plain-text string
> > and return an ecrypted string (preferably 32 character) .  I've been
> > using md5('string'), but I'm concerned it's too weak for my needs.  Does
> > anyone have any recommendations?
>
> What are your needs?
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>                http://archives.postgresql.org


Re: PGSQL encryption functions

From
Tom Lane
Date:
"Mark R. Dingee" <mark.dingee@cox.net> writes:
> md5 works, but I've been able to 
> brute-force crack it very quickly,

Really?  Where's your publication of this remarkable breakthrough?
        regards, tom lane


Re: PGSQL encryption functions

From
Mario Splivalo
Date:
On Tue, 2005-11-01 at 17:13 -0500, Tom Lane wrote:
> "Mark R. Dingee" <mark.dingee@cox.net> writes:
> > md5 works, but I've been able to 
> > brute-force crack it very quickly,
> 
> Really?  Where's your publication of this remarkable breakthrough?

I'd say you can't bruteforce md5, unless you're extremley lucky.
However, md5 is easily broken, you just need to know how to construct
the hashes.

One could switch to SHA for 'increaased' security.

Although I don't think he'd be having problems using MD5 as he described
it. I'd also lilke to see he's example of brute-force 'cracking' the MD5
digest.
Mike
-- 
Mario Splivalo
Mob-Art
mario.splivalo@mobart.hr

"I can do it quick, I can do it cheap, I can do it well. Pick any two."




Re: PGSQL encryption functions

From
"Mark R. Dingee"
Date:
Mike & Tom,

The script I'm using to "break" md5 presumes that the cracker knows the 3 
elements being concatenated together to form the plain-text sting which is 
then passed into md5.  The method I'm using then begins running through 
various permutations.  Do you believe that the methodology is appropriate or 
that I'm being a bit paranoid?

Thanks

On Tuesday 01 November 2005 05:13 pm, Tom Lane wrote:
> "Mark R. Dingee" <mark.dingee@cox.net> writes:
> > md5 works, but I've been able to
> > brute-force crack it very quickly,
>
> Really?  Where's your publication of this remarkable breakthrough?
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: 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

On Wednesday 02 November 2005 04:26 am, Mario Splivalo wrote:
> On Tue, 2005-11-01 at 17:13 -0500, Tom Lane wrote:
> > "Mark R. Dingee" <mark.dingee@cox.net> writes:
> > > md5 works, but I've been able to
> > > brute-force crack it very quickly,
> >
> > Really?  Where's your publication of this remarkable breakthrough?
>
> I'd say you can't bruteforce md5, unless you're extremley lucky.
> However, md5 is easily broken, you just need to know how to construct
> the hashes.
>
> One could switch to SHA for 'increaased' security.
>
> Although I don't think he'd be having problems using MD5 as he described
> it. I'd also lilke to see he's example of brute-force 'cracking' the MD5
> digest.
>
>     Mike


Re: PGSQL encryption functions

From
Neil Saunders
Date:
OK, you're not really "breaking" md5. If the attacker already knows
the information being encrypted, then all you're testing is the
concatenation order- Surely the information is more important than the
order? md5 is a one way hash function, and so using an alternate
algorithm will provide no benefit whatsoever; you're just running
through 9 permutations.

Kind Regards,

Neil.

On 11/2/05, Mark R. Dingee <mark.dingee@cox.net> wrote:
> Mike & Tom,
>
> The script I'm using to "break" md5 presumes that the cracker knows the 3
> elements being concatenated together to form the plain-text sting which is
> then passed into md5.  The method I'm using then begins running through
> various permutations.  Do you believe that the methodology is appropriate or
> that I'm being a bit paranoid?
>
> Thanks
>
> On Tuesday 01 November 2005 05:13 pm, Tom Lane wrote:
> > "Mark R. Dingee" <mark.dingee@cox.net> writes:
> > > md5 works, but I've been able to
> > > brute-force crack it very quickly,
> >
> > Really?  Where's your publication of this remarkable breakthrough?
> >
> >                       regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: 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
>
> On Wednesday 02 November 2005 04:26 am, Mario Splivalo wrote:
> > On Tue, 2005-11-01 at 17:13 -0500, Tom Lane wrote:
> > > "Mark R. Dingee" <mark.dingee@cox.net> writes:
> > > > md5 works, but I've been able to
> > > > brute-force crack it very quickly,
> > >
> > > Really?  Where's your publication of this remarkable breakthrough?
> >
> > I'd say you can't bruteforce md5, unless you're extremley lucky.
> > However, md5 is easily broken, you just need to know how to construct
> > the hashes.
> >
> > One could switch to SHA for 'increaased' security.
> >
> > Although I don't think he'd be having problems using MD5 as he described
> > it. I'd also lilke to see he's example of brute-force 'cracking' the MD5
> > digest.
> >
> >       Mike
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: 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
>


Re: PGSQL encryption functions

From
Tom Lane
Date:
"Mark R. Dingee" <mark.dingee@cox.net> writes:
> The script I'm using to "break" md5 presumes that the cracker knows the 3 
> elements being concatenated together to form the plain-text sting which is 
> then passed into md5.  The method I'm using then begins running through 
> various permutations.  Do you believe that the methodology is appropriate or 
> that I'm being a bit paranoid?

Well, this is a fundamentally insecure way of using *any* crypto hash method.
You're blaming MD5 for the fact that you're misusing it.

There has to be some component of the hash input that the attacker
doesn't know and can't trivially guess.  Adding a randomly chosen "salt"
string is one common way to do that.
        regards, tom lane


Re: PGSQL encryption functions

From
Bruno Wolff III
Date:
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.


Re: PGSQL encryption functions

From
"Mark R. Dingee"
Date:
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


Re: PGSQL encryption functions

From
Bruno Wolff III
Date:
On Wed, Nov 02, 2005 at 16:01:19 -0500, "Mark R. Dingee" <mark.dingee@cox.net> wrote:
> 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.

Why do you need any more than the session id and the random number? Once you
switch to including some random data, it seems like it would be simpler to
just use random data/

> 
> 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.

If they have privileged accounts on the web server you may need to worry about
this.