search

processone / ejabberd

Robust, Ubiquitous and Massively Scalable Messaging Platform (XMPP, MQTT, SIP Server)
https://www.process-one.net/en/ejabberd/
Other
6.11k stars 1.51k forks source link

[SCRAM] SCRAM-SHA-1-PLUS + SCRAM-SHA-256(-PLUS) + SCRAM-SHA-512(-PLUS) supports #2742

Closed Neustradamus closed 3 years ago

Neustradamus commented 5 years ago

To have compatibility with XMPP Servers and after:

Can you add supports of :

"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]".

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

-PLUS variants:

LDAP:

HTTP:

2FA:

IANA:

Note, after SCRAM-SHA-1(-PLUS):

Linked to:

zinid commented 5 years ago

On and on this goes. They invent new SCRAM every year (without clear migration path) and we should implement this every time? Why?

Neustradamus commented 5 years ago

@stpeter who works on it: https://tools.ietf.org/html/draft-ietf-mile-xmpp-grid.

IANA: https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

State of Play: https://github.com/scram-xmpp/info/issues/1

EDIT: @stpeter has done a good job, RFC8600 is official: https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA.

zinid commented 5 years ago

So, let's say I created a password with SCRAM-SHA-512, but my another client only supports SCRAM-SHA-1, then what to do?

Neustradamus commented 5 years ago

XMPP client devs must to update the software... ^^ The user will do the best choice :)

zinid commented 5 years ago

Yeah, sure.

Neustradamus commented 5 years ago

Can you reopen the ticket? There are a lot of informations now ^^

zinid commented 5 years ago

What information? You still don't answer my main question about migration path.

Neustradamus commented 5 years ago

For information: https://crypto.stackexchange.com/questions/66195/what-is-the-use-of-scram-sha-256-over-scram-sha-1

Neustradamus commented 5 years ago

More details for Tigase 8.0.0+:

In more for Tigase 8.0.1+:

Of course, -PLUS variant work without any problems for all.

If the password was in SCRAM-SHA-1 before a migration and if we want to have SCRAM-SHA-256 (and other), a reset all passwords is needed. Of course, it is possible to disable SCRAM-SHA-1 and/or SCRAM-SHA-256 too.

zinid commented 5 years ago

@Neustradamus how is information about Tigase relevant in this bug tracker?

Neustradamus commented 5 years ago

It is the solution for launch improvements of the missing part in ejabberd :)

Neustradamus commented 5 years ago

Any news on it?

The new RFC has been published by @stpeter: https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA.

Neustradamus commented 5 years ago

Goog news, there is a best article to convert old unsecured MD5 passwords to SCRAM-SHA-256 with PostgreSQL:

puiterwijk commented 4 years ago

@Neustradamus I think the problem upstream has with this is that it requires a reset of all user passwords to make use of it, as the Tigase and PostgreSQL articles also mention (the instructions for neither of them would port over to ejabberd, given that it basically comes down to "reset all passwords").

Also, what happens if a user password is stored in SCRAM-SHA256 format, but their client only supports SCRAM-SHA1? The server is unable to verify the user. The Tigase solution seems to be to store both a SHA1 and SHA256 based version of the password, and they say they can automatically port if you have the PLAIN auth enabled. (Which, if you use it, sorta defeats the entire purpose of SCRAM I'd say?) I think that if ejabberd wants to support SCRAM-SHA256, they should/would probably also support multiple stored passwords, to retain compatibility with clients that don't have SCRAM-SHA256, but I'm not knowledgeable of the code to a sufficient enough degree to know what that'd entail.

Basically, it's a new password storage mechanism without migration path from SCRAM-SHA1 that makes implementing this hard.

Neustradamus commented 4 years ago

@puiterwijk: Thanks for your comment on this VERY IMPORTANT not-closed ticket but currently closed.

First, it is important to support different SCRAM possibilities.

Second part, is the migration from actual SCRAM-SHA-1 but the first part is very important!

How it is possible to have this in other XMPP servers in more than XMPP clients and not in ejabberd?

mremond commented 4 years ago

@Neustradamus as always, patches are welcome (as well as respect).

Neustradamus commented 3 years ago

Thanks to @prefiks for SCRAM-SHA-1-PLUS + SCRAM-SHA-256(-PLUS) + SCRAM-SHA-512(-PLUS):

Neustradamus commented 3 years ago

@badlop: Not completely finished but @prefiks works on it. All people can say a very, very, big thanks about this improvement in ejabberd!

Neustradamus commented 3 years ago

After commit in ejabberd repository:

New commits about it:

Neustradamus commented 3 years ago

After commits in ejabberd repository:

New commits about it:

licaon-kter commented 3 years ago

@Neustradamus could you like...stop beating this horse?