Hello all,

I would like to use password authentication for pgsql users for remote
backup purposes. I don't like the fact storing cleartext password on a
system. From documentation, i have learnt that passwords can be encrypted
by md5 and crypt methods.

But we know, that md5 is rather weak encryption, so I am asking is there
any feasible way, how we can use SHA1 instead MD5?

Cheers,
Bohdan

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Mon, Oct 24, 2005 at 10:39:11AM +0200, Bohdan Linda wrote:
>
> Hello all,
>
> I would like to use password authentication for pgsql users for remote
> backup purposes. I don't like the fact storing cleartext password on a
> system. From documentation, i have learnt that passwords can be encrypted
> by md5 and crypt methods.
>
> But we know, that md5 is rather weak encryption, so I am asking is there
> any feasible way, how we can use SHA1 instead MD5?

Firstly, SHA-1 is in no better shape than MD5, see [1]. Secondly all
the current attacks are based upon generating collisions which kills it
for the digital signing purpose, but for the purposes of authentication
like we're using that's not relevent. That would require being able to
generate a password that matches a given hash which none of the current
attacks do.

However, looking into the future this would require the following:

1. Adding code to backend and frontend (sha1 code may exist in contrib,
not sure).
2. Changing the protocol to support another hashing algorithm.
3. All sorts of other fiddling but it wouldn't be too hard.

By all means, submit a patch but there's no real hurry right now. We
should probably move straight to something more secure anyway, maybe
SHA-256 or something.

[1] http://www.schneier.com/blog/archive...a1_broken.html

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFDXKp3IB7bNG8LQkwRArc5AJ0bPZ9eKelMdCrJvGRu6f pqFnQ5LQCbB707
Dfb+VdD0McWvHbX0UD6yvxE=
=CT84
-----END PGP SIGNATURE-----

Thank you for the explanation.

Cheers,
Bohdan

---------------------------(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 Mon, Oct 24, 2005 at 11:33:50 +0200,
Martijn van Oosterhout <kleptog@svana.org> wrote:
>
> By all means, submit a patch but there's no real hurry right now. We
> should probably move straight to something more secure anyway, maybe
> SHA-256 or something.

This makes more sense. There is little point in going to the effort to
changing to SHA-1 only to change again later.
There isn't any hurry to change now, so it might be better to wait until
the next group of hash functions is designed, built on lessons learned from
the attacks against MD5 and SHA-1.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On 10/27/05, Bruno Wolff III <bruno@wolff.to> wrote:
>
> On Mon, Oct 24, 2005 at 11:33:50 +0200,
> Martijn van Oosterhout <kleptog@svana.org> wrote:
> >
> > By all means, submit a patch but there's no real hurry right now. We
> > should probably move straight to something more secure anyway, maybe
> > SHA-256 or something.
>
> This makes more sense. There is little point in going to the effort to
> changing to SHA-1 only to change again later.
> There isn't any hurry to change now, so it might be better to wait until
> the next group of hash functions is designed, built on lessons learned
> from
> the attacks against MD5 and SHA-1.
>

It might be a good step to go through and figure out what needs to be
changed, then implement a plugin type system to reduce the need for changes
when the next generation of hashes gets "broken". It might even allow for
authentication to external sources, like LDAP or some other plugin.