Re: migrate hashname function from 8.1.x to 8.4

From: Nicolás Garfinkiel <nicolas(dot)garfinkiel(at)gmail(dot)com>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: migrate hashname function from 8.1.x to 8.4
Date: 2011-01-11 12:01:36
Message-ID: E694C395-71CC-4901-9E9C-32859C15C4A9@genesis-manlab.com.ar
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Indeed Craig, I would like to smack the guy as well, for this and many many other creepy crawlers in my everyday job!

Violence aside, thanks for your answer. The C module is what I was planning to do, but was not sure if there is another way. Of course using crypt would be the right thing to do, but I cannot afford it, as users from our system can barely remember their password, let alone collect them and recreate them! Of course I could reset their pwds, but that's gonna be a hard sell to my boss.

Cheers and thanks again!

On 11/01/2011, at 07:29, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> wrote:

> On 01/11/2011 03:02 PM, nicolas(dot)garfinkiel(at)genesis-manlab(dot)com(dot)ar wrote:
>
>> well, what i mean is that hashname() function would return a different value
>> depending the pgsql version.
>
> Yep. It seems to be an undocumented function with no particular defined behaviour. This isn't especially surprising. I personally wish such functions were in a different schema or were prefixed with something like "pg_int_" ... but they're not.
>
>> SELECT password FROM user WHERE password = hashname('AZALEA')
>
> !!WTF!!
>
> I hope you're not trying to use this as a secure one-way hash function. If so, find whoever decided to do so, and smack them. This function is intended for fast hashing for clustering things into random buckets, and isn't in any way intended to be even vaguely suitable for security use.
>
> See:
>
> http://www.postgresql.org/docs/current/static/pgcrypto.html
>
> Unlike the hashname() function, crypt() etc are well-defined functions with well-understood, stable results compatible not only between Pg versions but also between Pg and other software.
>
>> Just a side note: our goal with this upgrade is to improve our system's performance
>> and stability (which 8.1 is not) while not embarking in any kind of refactoring,
>> as plans are underway to develop a new system. what we are looking for is
>> just a quick fix, if there's such thing out there!
>
> Fix your app to use pgcrypto. Use a digest function from pgcrypto, storing both password digest and password salt. For that matter even unsalted use of md5() would be better, or crypt() with hardcoded salt, though both are pretty shocking.
>
>
> Failing that, extract hashname() from 8.1 and bundle it into a loadable C function module compatible with 8.1 and 8.4. Call your function "myhash()" or something, and use it instead of hashname() in both versions.
>
> A look at at hashname() in 9.0 shows it living in src/backend/access/hash/hashfunc.c . It calls hash_any(...) in the same file to do the real work. As it seems pretty well contained, assuming the 8.1 implementation is similar it should be easy to adapt to use as a loadable module. I haven't checked 8.1's code to check.
>
> See the tutorial for help on how to implement C extension modules.
>
> Personally I think you're way better off fixing your app to use pgcrypto and a decent hash function.
>
> --
> Craig Ringer

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message ๏̯͡๏ Guido Barosio 2011-01-11 14:27:23 Re: [pgsql-es-ayuda] Para participantes extranjeros en el Tercer PGDay Latinoamericano.
Previous Message rsmogura 2011-01-11 11:01:57 Re: Mixed client_encoding database question