#1845 mod_sasl_ssdp: Wrong calculation of hash if PLAIN is disabled
Reporter
Martin
Owner
Nobody
Created
Updated
Stars
★ (1)
Tags
Component-Community
Status-New
Type-Defect
Priority-Medium
Martin
on
With PLAIN auth enabled prosody and my client calculate the same downgrade protection hash (calc is calculated by my client, recv is what my client receives from prosody):
```
raw: OAUTHBEARER,PLAIN,SCRAM-SHA-1,SCRAM-SHA-1-PLUS|tls-exporter
calc: fXNRzKJ3ccSa9fGXEJotLadWM5g=
recv: fXNRzKJ3ccSa9fGXEJotLadWM5g=
```
If I disable PLAIN auth by setting `disable_sasl_mechanisms = { "PLAIN" } ` there is a discrepancy between the downgrade protection hashes:
```
raw: OAUTHBEARER,SCRAM-SHA-1,SCRAM-SHA-1-PLUS|tls-exporter
calc: KLdxyd14RVfso6sao6+8+xGr/Lc=
recv: fXNRzKJ3ccSa9fGXEJotLadWM5g=
```
As the downgrade protection hash sent from prosody is identical in both cases it seems that mod_sasl_ssdp ignores the deactivation of PLAIN.
Zash
on
Thanks for the report
I think we discussed this in the chat. Was this a problem with mod_sasl_ssdp not taking disable_sasl_mechanisms etc into account?
Changes
tags Component-Community
Martin
on
Yes, exactly.
Martin
on
Using Thilos [patches](https://groups.google.com/g/prosody-dev/c/XpdWuJv_-hM/m/-GZGtzVMBgAJ) it works for me:
```
raw: OAUTHBEARER,SCRAM-SHA-1,SCRAM-SHA-1-PLUS|tls-exporter
calc: KLdxyd14RVfso6sao6+8+xGr/Lc=
recv: KLdxyd14RVfso6sao6+8+xGr/Lc=
downgrade protection success
```
Martin
on
Any objections to the patches? As far as I can see there was also no feedback in the google group.
Martin
on
Comments from Zash in the prosody MUC:
> I'd suggest just copypasting the derivation of that value into the community modules, instead of inventing a new internal API
> API design is hard and would need more thought
> otherwise it inevitably ends up biting us somehow
With PLAIN auth enabled prosody and my client calculate the same downgrade protection hash (calc is calculated by my client, recv is what my client receives from prosody): ``` raw: OAUTHBEARER,PLAIN,SCRAM-SHA-1,SCRAM-SHA-1-PLUS|tls-exporter calc: fXNRzKJ3ccSa9fGXEJotLadWM5g= recv: fXNRzKJ3ccSa9fGXEJotLadWM5g= ``` If I disable PLAIN auth by setting `disable_sasl_mechanisms = { "PLAIN" } ` there is a discrepancy between the downgrade protection hashes: ``` raw: OAUTHBEARER,SCRAM-SHA-1,SCRAM-SHA-1-PLUS|tls-exporter calc: KLdxyd14RVfso6sao6+8+xGr/Lc= recv: fXNRzKJ3ccSa9fGXEJotLadWM5g= ``` As the downgrade protection hash sent from prosody is identical in both cases it seems that mod_sasl_ssdp ignores the deactivation of PLAIN.
Thanks for the report I think we discussed this in the chat. Was this a problem with mod_sasl_ssdp not taking disable_sasl_mechanisms etc into account?
ChangesYes, exactly.
Using Thilos [patches](https://groups.google.com/g/prosody-dev/c/XpdWuJv_-hM/m/-GZGtzVMBgAJ) it works for me: ``` raw: OAUTHBEARER,SCRAM-SHA-1,SCRAM-SHA-1-PLUS|tls-exporter calc: KLdxyd14RVfso6sao6+8+xGr/Lc= recv: KLdxyd14RVfso6sao6+8+xGr/Lc= downgrade protection success ```
Any objections to the patches? As far as I can see there was also no feedback in the google group.
Comments from Zash in the prosody MUC: > I'd suggest just copypasting the derivation of that value into the community modules, instead of inventing a new internal API > API design is hard and would need more thought > otherwise it inevitably ends up biting us somehow