search

svarshavchik / courier

Courier Mail Server
http://www.courier-mta.org
72 stars 12 forks source link

SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) + SCRAM-SHA-512(-PLUS) supports #19

Open Neustradamus opened 4 years ago

Neustradamus commented 4 years ago

"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".

Can you add support for?

Cyrus SASL is perfect:

RFCs:

Now there is SCRAM-SHA-512(-PLUS):

Now there is SCRAM-SHA3-512(-PLUS):

https://xmpp.org/extensions/inbox/hash-recommendations.html

-PLUS variants:

IMAP:

LDAP:

HTTP:

2FA:

IANA:

Linked to:

svarshavchik commented 4 years ago

I'm open to reviewing patches and pull requests, of course.

Neustradamus commented 3 years ago

@svarshavchik: Have you looked? Cyrus SASL has it, ... Dovecot too...

svarshavchik commented 3 years ago

No, I do not have an update here. In the last year noone else mentioned any need for this, and if someone needs it bad enough, patches are still welcome.

Neustradamus commented 2 years ago

@svarshavchik: I wish you a Happy New Year!

Have you progressed on it?

Thanks in advance.

svarshavchik commented 2 years ago

CRAM and hash-based authentication schemes were preferred a long time ago before the overall TLS encryption became widespread and available. Today TLS offers a far superior level of security than password-only schemes.

Additionally most of these require the server to store client passwords in plain text, which is actually even worse from security perspective. The most secure password validation mechanism is using TLS for the entire client session, with a plain text password that's one-way hashed on the server, so even if the server is compromised the passwords will not be.

If someone were to submit a patch to implement these I'll review it, but this is not a priority for me.

Neustradamus commented 2 years ago

@svarshavchik: Thanks for your reply but Courier must not to support obsolete and unsecure CRAM-MD5 and DIGEST-MD5:

It is really very important, to add, for example in first time without TLS Binding (= without -PLUS variants).

It is already done in:

A more complete list here: https://github.com/scram-xmpp/info/issues/1.

Thanks in advance.

Linked to:

svarshavchik commented 2 years ago

CRAM-MD5 and other CRAM authentication methods are disabled by default, and require explicit configuration in order to enable.

As such, no action is needed, since CRAM-MD5 is not enabled in a default configuration.

Neustradamus commented 2 years ago

@svarshavchik: Thanks for your clarification but badly some admins enable it...

The SCRAM supports are important, it is for this I relaunch you about it.

svarshavchik commented 2 years ago

In the interim I can update the documentation to note that MD5 should only be enabled for legacy client support.

Like I wrote earlier, if someone needs this sufficiently to implement a patch I'll review it, but this is not a very high priority since HMAC/SCRAM authentication mechanism are really no longer needed, and TLS is better than HMAC/SCRAM. Additionally, Courier supports certificate-based authentication, without any passwords, which is the highest level of secuirty, overall. Implementing SCRAM is mostly a wasted effort. High-security installations will use certificates to authenticate, anyway.

Neustradamus commented 2 years ago

@svarshavchik: Yes you can add about MD5.

Maybe it is a good page about SCRAM: https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/how-to-securely-authenticate-with-scram-in-postgres-13/ba-p/1548319.

Neustradamus commented 2 years ago

@svarshavchik: I have added the last RFC in the description: RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2:

I wish you a good reading.

svarshavchik commented 2 years ago

imap4rev2 lists the SCRAM authentication methods as SHOULD, not MUST, they're not required. In any case, Courier does not implement imap4rev2, anyway.