Re: CRAM-MD5 and storage of password
On 4/27/12 2:12 AM, Chris Newman wrote:
> --On April 26, 2012 23:01:33 +0200 "Rolf E. Sonneveld"
> <R.E.Sonneveld@...> wrote:
>> Thanks for your answer. I understand and agree it's the infamous chicken
>> and egg problem (as usual with standards ), but the minimum I can do
>> is to file an RFE for this customer and hope it will get sufficient
>> 'momentum' to get it implemented, hoping that client support will sooner
>> or later follow.
> I'd personally appreciate if you get the RFE created.
The RFE I filed today got ERB (Enhancement Request Bug) number 14012027.
If anyone on the list would be interested in this functionality, please
add your name/support ID to this ERB.
>> If cleartext storage of passwords in the directory is enabled (and
>> configured in the mail server), will it be possible to support
>> simultaneously CRAM-MD5 and PLAIN?
> --On April 26, 2012 23:26:11 +0200 "Rolf E. Sonneveld"
> <R.E.Sonneveld@...> wrote:
>> Hi, Chris,
>> On 4/26/12 6:56 PM, Chris Newman wrote:
>>> --On April 25, 2012 17:35:42 -0700 Ned Freed <ned.freed@...>
>>>>> or is there an alternative (assuming there are clients that can do
>>>>> but that can't do TLS)?
>>>> SCRAM is the alternative you're looking for. Unfortunately, I don't
>>>> we've implemented support for it yet, although I suppose you could
>>>> do it
>>>> yourself with the authentication plugin. But that doesn't get you
>>>> support, of course.
>>> It would be possible (and not too difficult) to add SCRAM support (RFC
>>> 5802/5803) to Messaging Server (7u4 or later) using our third-party
>>> authentication server interface (although the optional channel binding
>>> feature would require some enhancements to the interface).
>> Can you elaborate on this channel binding feature. Do you mean the
>> mailSMTPSubmitChannel feature?
> No. I'm talking about RFC 5802's "Channel binding" feature described
> in section 6 (unrelated to MTA channels). It allows a SCRAM
> authentication to be bound to an SSL session so that SCRAM+SSL is
> significantly more secure than passwords+SSL and provides true mutual
> authentication that can't be intercepted. SCRAM was designed to be
> useful with or without SSL, raising the security level significantly
> in both cases relative to plaintext passwords.
>>> As I'm personally interested in seeing SCRAM succeed, I'd be willing
>>> to write the server code (and I'm willing to do so in my free time if
>>> necessary as my work time is very constrained). But that still leaves
>>> the problem of client support. If you managed to get one or two client
>>> vendors on board, we could get it working.
>> Anyone contacts within the MUA industry? If SCRAM was added to the Java
>> libraries, it would be a major step forward. Well, Java is owned by
>> Oracle, so...
> I have a couple contacts, but none who would be able to spend
> implementation time on a client authentication feature at my request.
In the past there were companies (like Innosoft ) that implemented
technologies to anticipate on customer requests. Supporting SCRAM in
Comms Suite while other MTA vendors do not yet support it is a
competitive advantage (well, let's be realistic, it is one of a list of
features that can make up a competitive advantage).
>>> Another option is Kerberos/GSSAPI. We've had one customer get that
>>> working through the third-party authentication server interface (by
>>> implementing RFC 4752). I find Kerberos expensive in terms of
>>> management and client configuration costs, but at least there are
>>> client implementations available.
>> When using third-party authentication, what does it mean for
>> patches/upgrades of the messaging server? Will it keep working?
> Yes, the inter-process protocol is a stable documented protocol.
Excuse me, I'm not sure my question was clear and I'm not sure how to
interpret your answer. What I intended to say is the following: suppose
a customer implements Kerberos/GSSAPI using the 3rd party authentication
server interface for the current version (7.0u4-24) and it works. Now,
suppose later this year version 7.1 of Messaging Server is released and
the customer decides to upgrade, then my question is: will the
Kerberos/GSSAPI software written by the customer against the 3rd party
auth server interface keep working, or will it require modifications and
re-testing. I suppose your answer means, that an upgrade of the mail
server will have no impact on the customer written code, but I'm not
sure if that is what I should read in it.
>>> CRAM-MD5 has too many design flaws, so it's basically considered
>>> useless from a security perspective these days. Ditto for APOP.
>> So to summarize: the best thing for now is: use SASL PLAIN and encrypt
>> the transport layer, is that correct?
> For most usage scenarios, PLAIN+SSL/TLS is the right choice today (and
> that's a sad statement about the importance that's placed on
> authentication security by the industry). Client certificate
> authentication is also possible and more secure, but it tends to be
> suitable mostly for high security environments that can afford to
> spend a lot on PKI management.