Exception in SCRAM.getSalt()

Openfire Openfire Support
1

I’m getting the following exception in openfire logs in Openfire 4.3.2 with custom authentication library and external mysql database. Could I have your assistance identifying what the problem is?:

2019.09.27 09:14:45 WARN [socket_c2s-thread-7]: org.jivesoftware.openfire.sasl.ScramSha1SaslServer - Exception in SCRAM.getSalt():
java.lang.UnsupportedOperationException: null
at org.jivesoftware.openfire.auth.DefaultAuthProvider.getPassword(DefaultAuthProvider.java:220) ~[xmppserver-4.3.2.jar:4.3.2]
at org.jivesoftware.openfire.auth.AuthFactory.getPassword(AuthFactory.java:168) ~[xmppserver-4.3.2.jar:4.3.2]
at org.jivesoftware.openfire.sasl.ScramSha1SaslServer.getSalt(ScramSha1SaslServer.java:313) [xmppserver-4.3.2.jar:4.3.2]
at org.jivesoftware.openfire.sasl.ScramSha1SaslServer.generateServerFirstMessage(ScramSha1SaslServer.java:153) [xmppserver-4.3.2.jar:4.3.2]
at org.jivesoftware.openfire.sasl.ScramSha1SaslServer.evaluateResponse(ScramSha1SaslServer.java:109) [xmppserver-4.3.2.jar:4.3.2]
at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java:329) [xmppserver-4.3.2.jar:4.3.2]
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:185) [xmppserver-4.3.2.jar:4.3.2]
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:177) [xmppserver-4.3.2.jar:4.3.2]

2

For SCRAM to work with a custom authentication library, that library must return the unencrypted, plain text password in its implementation of org.jivesoftware.openfire.auth.AuthProvider#getPassword Yours throws UnsupportedOperationException, which will not work for SCRAM.

3

Thank you for replying. However, we are not the system of record for the passwords. From the custom auth provider we call an external api to provide the authentication so we dont store the passwords in the ofuser table. Are you saying you can only select AES encryption if you are storing passwords on openfire’s external mysql database?

4

That’s not exactly what I was saying (you can I’m fact use any Auth provider that can provide the original password, not just Openfires own database-based one), but I think that you got the message that I was trying to convey.

5

It turns out Openfire reverted to the default auth provider by resetting the system property provider.user.className. I restored the properties to use the custom auth provider and now i’m getting a SASL Exception “PLAIN authentication failed for: username”. Will forcing the SASL mechanism to EXTERNAL fix this issue since I’m using a custom authentication library?

The interesting thing is that our original setup has been working in production for several months and just this week 1) Openfire switched from our custom authentication library to its default authentication by setting the system property provider.user.className 2) The SASL mechanism changed to SCRAM-SHA-1

I would also like to understand if Openfire is setup to reset the provider.user.className if it receives a certain amount of login failures

Please find the exception below:
javax.security.sasl.SaslException: PLAIN authentication failed for: username
at org.jivesoftware.openfire.sasl.SaslServerPlainImpl.evaluateResponse(SaslServerPlainImpl.java:144) ~[xmppserver-4.3.2.jar:4.3.2]
at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java:329) [xmppserver-4.3.2.jar:4.3.2]
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:185) [xmppserver-4.3.2.jar:4.3.2]

6

It is possible to have a perfect SCRAM-SHA-1/SCRAM-SHA-1-PLUS support for internal and external auths?

And add other SCRAM-SHA-2 too?

  • SCRAM-SHA-224
  • SCRAM-SHA-224-PLUS
  • SCRAM-SHA-256
  • SCRAM-SHA-256-PLUS
  • SCRAM-SHA-384
  • SCRAM-SHA-384-PLUS
  • SCRAM-SHA-512
  • SCRAM-SHA-512-PLUS

Linked to: https://github.com/scram-xmpp/info/issues/1

stpeter has been done a good job, it is now official: https://tools.ietf.org/html/rfc8600 (2019-06-21): https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA.

CRAM-MD5 to Historic:

RFC6331: Moving DIGEST-MD5 to Historic

“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]”.

After SCRAM-SHA-1(-PLUS):

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

-PLUS variants:

LDAP:

  • RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803

HTTP:

IANA: