| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: Successor of MD5 authentication, let's use SCRAM |
| Date: | 2012-10-22 15:21:43 |
| Message-ID: | 50856487.3020405@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/12/12 3:44 PM, Stephen Frost wrote:
> wrt future-proofing, I don't like the "#-of-iterations" approach. There
> are a number of examples of how to deal with multiple encryption types
> being supported by a protocol, I'd expect hash'ing could be done in the
> same way. For example, Negotiate, SSL, Kerberos, GSSAPI, all have ways
> of dealing with multiple encryption/hashing options being supported.
> Multiple iterations could be supported through that same mechanism (as
> des/des3 were both supported by Kerberos for quite some time).
>
> In general, I think it's good to build on existing implementations where
> possible. Perhaps we could even consider using something which already
> exists for this?
Sounds like SASL to me.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2012-10-22 15:28:35 | Re: Deprecating RULES |
| Previous Message | Andrew Dunstan | 2012-10-22 14:57:33 | Re: Successor of MD5 authentication, let's use SCRAM |