Giuseppe Moscarella opened 8 years ago
|
|
Can you provide full, verbose client logs? Including stanza exchange? We have tested SCRAM implementation and it works for us. You could try following options to limit enabled mechanisms: sess-man/plugins-conf/enabled-mechanisms=PLAIN,DIGEST-MD5 |
|
It would be also good to provide version of used Smack and babbler library, so we could use same versions to replicate this issue. |
|
I've created a maven integration test with both babbler and smack. You can clone it from https://github.com/bytecodeguru/tigase-scram-test. It also contains the packets captured with ngrep during my local tests. I'm now trying your proposed workaround sess-man/plugins-conf/enabled-mechanisms=PLAIN,DIGEST-MD5 and will let you know if it works asap. |
|
I can confirm that the suggested workaround configuration works in my test environment, thank you. Perhaps it would be useful to add it to the administration doc. Please let me know if I can help further to investigate the SCRAM authentication issue. |
|
Bartek, please take a look. |
|
Short versionTigase Server works fine, Smack library is broken. Longer versionAs you can see in "RFC- 5802 attribute
cannot contains space (@x20@) character. But Smack sends for example:
In this case, Server rejects those request as invalid. I set your test @ SmackScramIT@ to connect to It failed 14 times per 36 runs. Each failed test contains x20 character in @nonce@. Sample failed test:
Sample success test:
|
|
Babbler works fine with tigase.org and my local Server. |
|
Bartosz Malkowski wrote:
Thank you for the detailed feedback. I will file an issue to smack devs. However I can't get babbler working using my test credentials, the test is passing with PLAIN auth but failing every time with SCRAM. It seems for fail for a different reason than smack. Could you try using username "jenkins" password "test" on your environment? SCRAM:
PLAIN:
|
|
Letters in username doesn't matter. No idea what is wrong with your server. I'm using revision 8e20620. Here is my config:
|
|
I also checked SCRAM data you quoted in last comment. Data are OK, and my SCRAM code calculates the same values, so problem fur sure isn't in SCRAM implementation. |
|
Bartosz Malkowski wrote:
Thank you for your help. I can confirm that changing credentials I get the same issue. I've downloaded the latest nightly build and I am now trying to enable remote debugging to check what is really happening in my test environment. |
|
The smack support team confirms the issue: https://issues.igniterealtime.org/browse/SMACK-735 Meanwhile I tracked down the code that refuses to authentication: it's AbstractSaslSCRAM.java in processClientLastMessage()
The arrays are equal in length but (completely) different in content. Any clue? |
|
Nope! It may be everything. Different salted password? |
|
Bartosz Malkowski wrote:
Here are the values of the variables just before the proof match condition, I have base64 encoded byte arrays for readability:
|
|
|
|
Bartosz Malkowski wrote:
Sorry I made this debug test using different credentials "jenkins2" "test2". The column tig_users.user_pw contains "469e3aa6433370b9dfa16be36a85fb21" for user jenkins2. Thank you for your effort, I'd like to be able to help you more than this. I'll try to find a better test case, but really I don't understand what could be the difference between your environment and mine. |
|
Can you check WHAT exactly is salted? With exactly what salt? What password is got from DB? You can start here: |
|
I managed to print some intermediate results:
|
|
Does |
|
The password is exactly the value stored in tig_users table. Yes the salt is different at each login attempt. For example here is a first attempt:
Here is a second attempt:
|
|
Scram doesn't works with passwords hashed with md5. For Scram you have to use plain passwords or salted ones compatible with Scram (pbkd2). |
|
Bartosz Malkowski wrote:
Thank you, this could explain everything, in fact I have this config: TigPutDBProperty('password-encoding', 'MD5-USERNAME-PASSWORD'); So, if I understand correctly, this would stop working after a simple upgrade to the latest tigase snapshot that enables scram by default. Perhaps it would be better to clarify this in the changelog. How do I fix the situation for my existing users? Should I follow the procedure described at http://docs.tigase.org/tigase-server/snapshot/Administration_Guide/html/#hashedPasswords ? I don't think it's possible to transform hashed passwords back to plain ones without the help of the users ;-) Moreover I don't see pbkd2 method, only plain or md5-*. Should I really revert back to plain? I'm starting to think that at this point the only feasible solution for this situation is to disable SCRAM. |
|
Bartosz Malkowski wrote:
Thanks for the detailed bug description. Just for the record. This is tracked as SMACK-735 (https://issues.igniterealtime.org/browse/SMACK-735). May I suggest that Tigase should report a different SASL error in case c-nonce contains invalid characters (and in similar cases) instead of 'not-authorized'? A think a good candidate would be 'malformed-request' (RFC 6120 § 6.5.8.). |
|
Giuseppe Moscarella wrote:
Bartek, could we make availability of SCRAM based on the Florian Schmaus wrote:
Makes sense. |
|
Implemented |
|
Just built and ran a build with this fix, following errors occur on startup:
and
|
|
Commit reverted. I made mistake. It cannot be done automatically because it needs a lot of changes in AuthRepository interface. We can postpone it to release 7.2. The only way to turn off SCRAM is set list of allowed SASL mechanisms in @init.properties@. |
|
A follow-up #4814 was created to implement checking of the DB property. |
Type |
Bug
|
Priority |
Major
|
Assignee | |
RedmineID |
4678
|
Version |
tigase-server-7.1.0
|
Spent time |
47h 30m
|
After upgrading Tigase server to 7.1.0-SNAPSHOT-b4325 my clients can't authenticate.
For example I get this exception using smack:
And this exception using babbler:
If I configure tigase to use only PLAIN authentication method for my vhost, my clients (mobile and desktop apps) login without problems, so it's not a matter of wrong credentials.
Everything was working fine with older 7.1.0 snapshots (7.1.0-SNAPSHOT-b4193) when SCRAM was not enabled by default.
This is a blocker for me, because I don't know what is wrong and can't change my production client code to disable SCRAM and force PLAIN.
I tried
but existing vhosts seems to ignore that. The only working thing that disables SCRAM is forcing PLAIN explicitly in each VHOST, I used psi client for that.
My system creates dynamically many vhosts, and it would be very tedious to force PLAIN auth for the existing ones.
Is it possible at least to disable SCRAM authentication with a global configuration that is valid for every vhost?