Re: [GENERAL] SHA1 on postgres 8.3

From: Sam Mason <sam(at)samason(dot)me(dot)uk>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] SHA1 on postgres 8.3
Date: 2008-04-04 01:01:57
Message-ID: 20080404010157.GN6870@frubble.xen.chris-lamb.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Justin 2008-04-04 01:02:07 To many records returned
Previous Message Sam Mason 2008-04-04 00:37:30 Re: [GENERAL] SHA1 on postgres 8.3

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-04-04 01:04:23 Re: About numeric division again
Previous Message Sam Mason 2008-04-04 00:37:30 Re: [GENERAL] SHA1 on postgres 8.3