Increase the iteration count for SCRAM-SHA512 to 10000

[fdie]

The recommended iteration count has been increased to 10000 for SASL-SCRAM-SHA512 as stated here

[Neustradamus]

@fdie: Yep!

[tmolitor-stud-tu]

The same rationale is true for SCRAM-SHA-1 and SCRAM-SHA-256, too. You should increase these as well. Also 10000 is the absolute minimum and still really low. You should consider increasing it to 32768 or add a config setting to allow users to configure a higher iteration count.

[fdie]

I agree, the RFCs minimal iteration counts are hard coded but they should be configurable.
And scram-sha1 should be disabled...

[weiss]

they should be configurable.

If we can figure out a value that presumably (a) is secure enough for everyone for the foreseeable future without (b) resulting in multi-second delays during login when using common client hardware, I think there'd be value in sticking to hard-coding it.

Obscure configuration settings blow up the documentation, increase the amount of (untested) code paths, and carry the risk that admins who don't know what they're doing will do something bad (unintentionally). In my book, this should only be a configuration setting if the desirable value actually does depend on the environment.

And scram-sha1 should be disabled...

That's configurable already.

[tmolitor-stud-tu]

(a) is secure enough for everyone for the foreseeable future without (b) resulting in multi-second delays during login when using common client hardware

Unfortunately these requirements can not be met simultaneously imho. We can make it harder for attackers, but since SHA wasn't designed for hashing passwords and can therefore be massively parallelized, a secure default would certainly involve a multi second delay on old devices (depending on the definition of "old" of course).

That said, on my "old" android device from 2017 a value of 32768 caused only < 100ms delay when testing with Conversations and a patched ejabberd, so that value is probably good and can be used as lower bar.