Re: reducing our reliance on MD5

From: "Henry B (Hank) Hotz, CISSP" <hbhotz(at)oxy(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "Hotz Henry B(dot)" <hbhotz(at)oxy(dot)edu>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Subject: Re: reducing our reliance on MD5
Date: 2015-02-14 18:12:03
Message-ID: 790CA760-CD8C-4E74-AE60-05D1BCDFC4E7@oxy.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

SASL was done by many of the same people who did GSSAPI. It's main practical advantages are that it supports password-based mechanisms (in addition to GSSAPI/krb5), and that it’s more explicitly pluggable than GSSAPI is.

The password mechanism is simple enough that it's frequently implemented without a general library in e.g. older Jabber clients. We could likewise provide that as a configure fallback if availability of client libraries turns out to be a problem.

Cyrus SASL is bundled with a saslauthd and other utilities that handle the on-disk storage of hashed passwords. SASLauthd can be configured to use PAM, Kerberos 5, MySQL, custom plugin, or local BDB files for password verification/storage. (Instead of our own, we can provide someone else’s gun to shoot yourself with! ;-))

For myself, I think getting rid of MD5 is a low priority. If its replaced with SASL, then that has the advantage (?) of replacing GSSAPI as well, so the number of user options increases while the number of mechanisms in PG itself decreases.

Personal email. hbhotz(at)oxy(dot)edu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-02-14 19:10:53 Re: "multiple backends attempting to wait for pincount 1"
Previous Message Andres Freund 2015-02-14 17:56:03 Re: "multiple backends attempting to wait for pincount 1"