Re: sha1, sha2 functions into core?

On Wed, Aug 15, 2012 at 4:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marko Kreen <markokr(at)gmail(dot)com> writes:
>> On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>> Is there a TODO here?
>
>> There is still open ToDecide here: [snip]
>
> The argument against moving crypto code into core remains the same as it
> was, ie export regulations. I don't see that that situation has changed
> at all. Thus, I think we should leave all the pgcrypto code where it
> is, in an extension that's easily separated out by anybody who's
> concerned about legal restrictions. The recent improvements in the ease
> of installing extensions have made it even less interesting than it used
> to be to merge extension-supported code into core --- if anything, we
> ought to be trying to move functionality the other way.

Ok.

> If anybody's concerned about the security of our password storage,
> they'd be much better off working on improving the length and randomness
> of the salt string than replacing the md5 hash per se.

Sorry, I was not clear enough - by "password storage" I meant password
storage for application-specific passwords, not postgres users.

Postgres own usage of md5 is kind of fine, as:
- only superusers can see the hashes (pg_shadow).
- if somebody sees contents of pg_shadow, they don't need
to crack them, they can use hashes to log in immediately.

But for storage of application passwords, the hash needs
to be one-way and hard to crack, to decrease any damage
caused by leaks.

--
marko