search

esl / MongooseIM

MongooseIM is Erlang Solutions' robust, scalable and efficient XMPP server, aimed at large installations. Specifically designed for enterprise purposes, it is fault-tolerant and can utilise the resources of multiple clustered machines.
Other
1.64k stars 422 forks source link

SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) supports #2442

Closed Neustradamus closed 3 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?

SCRAM-SHA-512(-PLUS):

SCRAM-SHA3-512(-PLUS):

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

-PLUS variants:

LDAP:

HTTP:

2FA:

IANA:

Note: RFC6331: Moving DIGEST-MD5 to Historic

Linked to:

fenek commented 4 years ago

Hi @Neustradamus

This is definitely a very good idea. Sadly, we probably won't manage to add them for the next release but I'll add this request to our internal backlog.

Neustradamus commented 4 years ago

@fenek: Any news for this important point?

fenek commented 4 years ago

We haven't forgotten about this but the upcoming release is currently focused on different items.

michalwski commented 4 years ago

@Neustradamus can you explain (or point as to a documentation) how existing accounts using SCRAM-SHA-1 can be migrated to SCRAM-SHA-256. If I understand it correctly there is no other option as setting new password with the new mechanism.

Neustradamus commented 4 years ago

In first, it is possible to support all possibilities, minimum is:

Maybe possible to add others?

After the migration MD5 -> SHA-XXX is in second part.

Of course it is easy to create a code to have PLAIN, SCRAM-SHA-1 and SCRAM-SHA-256 passwords for example. And it is possible to enable: PLAIN (or not) / SCRAM-SHA-1 (or not) / SCRAM-SHA-256 (or not) /...

Current SCRAM-SHA-1 user passwords do not change, if an user will change: PLAIN (if enabled)/SCRAM-SHA-1/SCRAM-SHA-256/...

Example Cyrus SASL works now with: https://cyrusimap.org/sasl/sasl/authentication_mechanisms.html

Since Tigase 8.0+, you can look here: https://docs.tigase.net/tigase-server/master-snapshot/Administration_Guide/html/#schemaChangev800

Article: Convert old unsecured MD5 passwords to SCRAM-SHA-256 with PostgreSQL: https://info.crunchydata.com/blog/how-to-upgrade-postgresql-passwords-to-scram

Since PostgreSQL 10, MD5 -> SCRAM-SHA-256:

MongoDB 3.0: SCRAM-SHA-1 MongoDB 4.0: SCRAM-SHA1 and SCRAM-SHA-256, read here: https://www.mongodb.com/blog/post/exciting-new-security-features-in-mongodb-40

Neustradamus commented 4 years ago

@fenek @michalwski: Happy New Year 2020! Have you news about it? Have you worked on it?

michalwski commented 4 years ago

@Neustradamus Happy New Year 2020!

The next MongooseIM release is planned for end of January. I'll make sure this issue gets done as one of the first after the release.

And thanks for reminding about this!

Neustradamus commented 4 years ago

@michalwski: Why not in this next release?

michalwski commented 4 years ago

We have some other things planned for the upcoming release and I'm not sure we'll be able to fit this one.

Just for the record, MongooseIM already supports SCRAM-SHA-1 since version 1.4.0 which is 6 years old.

Neustradamus commented 4 years ago

It is easy to report some days after for this important feature.

The first problem is that there is only SCRAM-SHA-1, no SCRAM-SHA-1-PLUS. The second problem is that there is not SCRAM-SHA-256(-PLUS) and other SHA-2 family.

Neustradamus commented 4 years ago

@fenek @michalwski: Any news one more after? What is the progress for this important part?

michalwski commented 4 years ago

Hi @Neustradamus, this is one of our top priorities for the next release. I did initial research regarding the possibility of adding -plus variants and it may not be easy to achieve. The plan minimum is to add support of SCRAM-SHA-256 (SCRAM-SHA-1 is already supported).

Also I'm wondering how important is it to allow users to switch between the methods. If I understand it correctly in order to allow both -SHA-1 and -SHA-256 the password would have to be stored in a way that allows us to get the plain version from which the chosen method can proceed.

Neustradamus commented 4 years ago

First step:

Second step:

Third step:

Fourth step:

Neustradamus commented 4 years ago

@NelsonVides, @janciesla8818 and @michalwski: I have seen a lot of changes about SCRAM-SHA-256, thanks a lot for your improvements!

Why do not change history SCRAM-SHA-1 function and file names?

Examples:

Previously, I have used same base like your "256" adding, but it will be better if we have;

It is hard to add -PLUS variants? I see "channel_binding" but no SCRAM-SHA-1-PLUS and SCRAM-SHA-256-PLUS.

Can you add other SCRAM (224/384/512)?

Neustradamus commented 4 years ago

@NelsonVides, @janciesla8818 and @michalwski: Have you looked, what do you think?

janciesla8818 commented 4 years ago

Hi @Neustradamus,

Thanks for the provided suggestions, much appreciated! We are still working on those modules and the naming might still change. It will mostly depend on the functionalities and differences to '_sha256' modules. We'll let you know where do we land at.

michalwski commented 4 years ago

Hi @Neustradamus,

Thanks for keeping a close and detailed eye on the SCRAM-SHA-* progress in (probably) all XMPP related projects!

Answering to your questions:

  1. Naming convention, this is a good idea.
    1. All new SCRAM-SHA mechanism will have it's own module cyrsasl_scram_shaNUM module.
    2. There will be one mongoose_scram module, since this is a helper module and all the functions can be parametrise with the hashing algorithm.
    3. Names in tests can be adjusted to what you suggested.
  2. -PLUS variants - We are going to try implementing it. It's difficult, because currently there is no easy way to extract the low-level TLS data in order to do the channel_binding. Current tls library needs to be extended in order to provide us this information. We'll see how the research around this goes, it may turn out that -PLUS variants will be added later.
  3. SCRAM (224/384/512) - Adding SCRAM 256 we are doing required refactoring (also around storing the hashes for different algorithms in db) which will allow us to easily add other algorithms. I think this can be achieved within this release.
Neustradamus commented 4 years ago

Do not forget to specify:

Why "SCRAM_SHA_PREFIX" and not "SCRAM_SHA1_PREFIX"?

Currently:

Note better to have:

An admin can configurate PLAIN or SCRAM-SHA-1 or SCRAM-SHA-256 or several in same time?

Neustradamus commented 4 years ago

@NelsonVides, @janciesla8818 and @michalwski: Thanks for your changes! I have done some comments on the last PR...

Neustradamus commented 4 years ago

Thanks a lot to all people who work on SCRAM.

The order must be: SCRAM-SHA-512-PLUS -> SCRAM-SHA-512 -> SCRAM-SHA-384-PLUS -> SCRAM-SHA-384 -> SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 -> SCRAM-SHA-1-PLUS -> SCRAM-SHA-1

@janciesla8818, @NelsonVides, @michalwski: Have you seen my 3 reviews on esl/MongooseIM#2713?

Neustradamus commented 4 years ago

Dear @janciesla8818, @NelsonVides, @michalwski,

I have done two PRs:

michalwski commented 4 years ago

Thanks for the PRs @Neustradamus :) I merged #2719 and the change you proposed in #2720 will be included in a PR which @janciesla8818 is currently working on.

Thanks for keeping a close eye on the SCRAM-SHA-* improvements!

michalwski commented 4 years ago

Regarding the following question from @Neustradamus

An admin can configurate PLAIN or SCRAM-SHA-1 or SCRAM-SHA-256 or several in same time?

An admin will be able to configure:

  1. The stored password format, by default hashes for all the supported algorithms will be stored, but it will be possible to store only selected algorithms.
  2. The advertised auth mechanisms, when advertising the mechanisms MongoseIM will make sure that only these are advertised which have corresponding hash as defined by the stored password format configuration.
Neustradamus commented 4 years ago

@janciesla8818, @NelsonVides, @michalwski: Thanks for your good job!

But I am not sure, the order is good?

It must be: SCRAM-SHA-512-PLUS -> if failed -> SCRAM-SHA-512 -> if failed -> SCRAM-SHA-384-PLUS -> if failed -> SCRAM-SHA-384 -> if failed -> SCRAM-SHA-256-PLUS -> if failed -> SCRAM-SHA-256 -> if failed -> SCRAM-SHA-1-PLUS -> if failed -> SCRAM-SHA-1

michalwski commented 4 years ago

Do you mean the order on the list of supported mechanisms when the server advertises it to the client?

Neustradamus commented 4 years ago

@michalwski : Yes, and it will be good to have same in test, no? -> From best to worst.

michalwski commented 4 years ago

@Neustradamus the advertised list of authentication mechanisms can be adjusted. @janciesla8818 what do you think?

When it comes to selecting the authentication mechanism by the client, my understanding is that if the client is capable of channel binding and advertises it to the server, it will not be allowed to use other scram mechanisms than -PLUS variant. Is my understanding correct?

Moreover, when the server advertises an authentication mechanism, it will be possible for the client to authenticate with the mechanism unless:

  1. The server doesn't have the hash for a particular version because the list of the mechanisms was extended but passwords were not reset so new hash was not generated.
  2. The client doesn't provide valid data

At this point, I don't see much value (on the server side) in adding such test case which iterates over all the mechanisms.

Neustradamus commented 4 years ago

In the RFC 8600:

An XMPP client can have a setting like "Force connection with SCRAM-SHA-1"... for example

But if there is not forced options, it is the best order... and the first which works...

Of course, like you know, SCRAM is prefered than DIGEST-MD5.

For example, currently in Psi/Psi+, there are two options:

michalwski commented 4 years ago

Hi @Neustradamus I think the last PR in this topic is this one #2745 Do you think that after merging it, the issue can be considered done?

Neustradamus commented 4 years ago

@janciesla8818, @NelsonVides, @michalwski: For me the order is good yes, good job to all!

Can you do a test of a Mongoose IM server (C2S/S2S) on XMPP.net?

Neustradamus commented 3 years ago

@janciesla8818, @NelsonVides, @michalwski: Thanks for 3.7.0 release but before official news, I would like to test a Mongoose IM on XMPP.net, I want to see the result of:

Neustradamus commented 3 years ago

@janciesla8818, @NelsonVides, @michalwski: About LDAP part, how it works?

Neustradamus commented 3 years ago

@janciesla8818, @NelsonVides, @michalwski, @fenek: There is a MUC Room for Erlang Solutions / Mongoose IM? If yes, what is it? If not, what are your XMPP accounts? Thanks in advance!

michalwski commented 3 years ago

Hi @Neustradamus, after releasing 3.7 we took a break for breathing and focusing on some other matters. When it comes to the test on xmpp.net the result may be dissatisfying for you. MongooseIM currently advertises and allows to authenticate even before STARTTLS sessions. It can be configured to require STARTTLS, in this case, the authentication will be rejected but still advertised on the plain connection. Could you point us to a XEP, describing the best practices regarding TLS and advertised features? I think this is something we can improve. It'd be better to cover the requirement in a separate issue.

michalwski commented 3 years ago

When it comes to LDAP authentication backend, currently it works only with SCRAM-EXTERNAL and SCRAM-PLAIN.

Neustradamus commented 3 years ago

@michalwski: Have you progressed on it?

NelsonVides commented 3 years ago

Hi @Neustradamus,

I'm gonna try to keep these topics organised.

With that said, I'd like to close this old issue, I believe it has been solved. Let me know if you're fine with this.

Neustradamus commented 3 years ago

@NelsonVides: Yes, you can close this ticket, SCRAM are here, only a problem of order...

Neustradamus commented 3 years ago

Hi @janciesla8818, @NelsonVides, @michalwski, for your informations, new RFCs soon:

There are too:

Neustradamus commented 3 years ago

Hi @janciesla8818, @NelsonVides, @michalwski: For your information, there was a SCRAM problem in Conversations:

Have you feedbacks about SCRAM usage statistics?

NelsonVides commented 3 years ago

Hi @janciesla8818, @NelsonVides, @michalslaski: For your information, there was a SCRAM problem in Conversations:

* [iNPUTmice/Conversations@2a57c92](https://github.com/iNPUTmice/Conversations/commit/2a57c92f63afbe6c8627b84ba959614c2667de96)

Have you feedbacks about SCRAM usage statistics?

@Neustradamus That issue in Conversations has nothing to do with the protocol, but rather with their internal implementation of the serverkey-clientkey, so we have no concerns about that. Usage statistics, we don't have anything to share for the moment.

Neustradamus commented 1 year ago

Hi @janciesla8818, @NelsonVides, @michalwski: It is official for TLS 1.3 Binding!

Details:

For your information, SCRAM-BIS is in progress: https://tools.ietf.org/html/draft-melnikov-scram-bis.

Linked to:

NelsonVides commented 1 year ago

Hi @janciesla8818, @NelsonVides, @michalslaski: It is official for TLS 1.3 Binding!

* RFC 9266: Channel Bindings for TLS 1.3: https://tools.ietf.org/html/rfc9266

Details:

* tls-unique for TLS =< 1.2

* tls-exporter for TLS = 1.3

For your information, SCRAM-BIS is in progress: https://tools.ietf.org/html/draft-melnikov-scram-bis.

Linked to:

* [RFC 9266: Channel Bindings for TLS 1.3 support #3721](https://github.com/esl/MongooseIM/issues/3721)

Hi @Neustradamus,

I've seen the TLS 1.3 channel binding, it's on my personal task list. But first I need support for that in the underlying TLS libraries, and also, some code cleanup in MIM usage of the TLS libraries. So it'll take a while for this to be done, you don't need to remind me, I won't forget, but it won't be soon I'm afraid.

Thanks for the heads up!

PS: you probably wanted to tag @michalwski, not @michalslaski ;)

Neustradamus commented 1 year ago

Thanks @NelsonVides for your answer :)

The question is why @michalwski has done a change of username? ^^

NelsonVides commented 1 year ago

Thanks @NelsonVides for your answer :)

The question is why @michalwski has done a change of username? ^^

No change of username, those are two different Michałs 😛

Neustradamus commented 1 year ago

I know and I have updated ALL my comments.

And I am not alone...

You can see here:

Neustradamus commented 1 year ago

@NelsonVides: Have you looked for SCRAM-SHA3-512 and TLS Binding for TLS 1.3?

Neustradamus commented 1 year ago

@NelsonVides: Have you progressed on it?