Re: [GENERAL] SHA1 on postgres 8.3 - Mailing list pgsql-hackers

From Sam Mason
Subject Re: [GENERAL] SHA1 on postgres 8.3
Date
Msg-id 20080404010157.GN6870@frubble.xen.chris-lamb.co.uk
Whole thread Raw
In response to Re: [GENERAL] SHA1 on postgres 8.3  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
List pgsql-hackers
On Thu, Apr 03, 2008 at 04:42:47PM -0700, Ron Mayer wrote:
> Sam Mason wrote:
> >On Thu, Apr 03, 2008 at 07:07:56PM +0200, Svenne Krap wrote:
> >>
> >>ID serial
> >>Username varchar
> >>Password_md5 varchar
> >>Password_sha1 varchar
> >... 
> >Why not just use SHA-512, you get many more quality bits that way.
> 
> Or if he just wanted to use builtin tools and reduce accidental
> collisions almost exactly the same much as he propopses, he could use
> 
>    password_md5_with_salt_xxx varchar
>    password_md5_with_salt_yyy varchar
> 
> but I also can't see the point.  Won't he have more
> collisions from cosmic rays turning the results of his comparisons
> from false to true anyway?

There's a difference between random bit flips, which in large systems
happen surprisingly regularly, and a determined attacker.  You'd be able
to get somewhere against the former by duplicating everything, and you'd
be able to get somewhere against the latter by using stronger hashes.

Or have I missed the point entirely.

> >Sounds like a good reason for moving the current md5 function out into
> >pgcrypto as well! :)
> 
> I'd rephrase it as saying "a good reason for making it less
> intimidating to install modules".   +1 to all the approaches
> that make this less scary.

That's a much nicer way of saying it!

I think that from an ISPs perspective (I can't remember the real use
case that was given recently) the main problem with modules is that
you have to build trust in each one individually.  I.e.  Doesn't the
code running in modules run as the postgres user?  If so, what would
stop a malicious module from doing anything that the postgres user can?
I'd probably phrase this as saying the modules are within PG's trust
boundary, rather than outside.  It's therefore the responsibility of
the person installing the module to verify (I think this will generally
be blind human trust) that the code isn't malicious.  I'd guess that's
a reason why so few modules are installed, it basically opens your
code up to another source, with whom the installer has no prior trust
relationship.

There are operating systems that allow authority to be attenuated
arbitrarily finely (i.e. not the very coarse user/role based ACL systems
we have at the moment) which would allow mutually suspicious code to
function.  I.e. PG would be able to assume that the module was malicious
and that the module wanted to crash PG, the module would assume the
reverse, and the ISP wouldn't have to worry at all.  It'll be a few
years before we get there though.

 Sam


pgsql-hackers by date:

Previous
From: Sam Mason
Date:
Subject: Re: [GENERAL] SHA1 on postgres 8.3
Next
From: Tom Lane
Date:
Subject: Re: About numeric division again