Hi Marvin, > > I've split out the SCRAM upgrade task definition into a new ProtoXEP: > > https:// > > github.com/tmolitor-stud-tu/xeps/tree/scram-upgrades > > Rendered version: > > https://dyn.eightysoft.de/final/xep-scram-upgrade.html > > Just wanted to mention that this specification isn't really a "SCRAM > upgrade", but rather a "change salted password" specification (which > might be an interesting idea to have, but that's another story), > because the server has no way to verify that the salted password is the > same as the previous one when upgrading from SCRAM-SHA-1 to SCRAM-SHA- > 256. Well, if a client used different passwords to generate she SCRAM-SHA-256 hash than was used for the SCRAM-SHA-1, mere chaos would evolve. But you are right: we should add wording to XEP-0388 that the password used for the new hash MUST be the same as used to log in the client in the first place.
> I also question the proposed upgrade mechanism in general. The server > can only suggest mechanisms independent of the user's account name. If > the server previously only stored SCRAM-SHA-1 secrets and some users > upgraded but others didn't, the list can't be used meaningfully. What > we'd need here is a new error code for the server to tell the client > after the <authenticate> message that the user can't use SCRAM-SHA-256 > yet, but will be able to do so after some upgrade operation being > performed (which probably entails sending the password in plain). > A client that is trying to do SCRAM-SHA-256 when the server doesn't > have matching credentials yet must have the plain password at hand > already (as it can't have the SaltedPassword yet due to lack of salt), > so it is already prepared to provide it. If channel binding is desired > for security reasons, one could also do a SCRAM-SHA-1-PLUS before > sending the password to the server in plain. You misunderstood the upgrade tasks: the server knows perfectly well which SASL mechanisms a specific account can be upgraded to and which mechanisms can already be used right away (the "from"-attribute of the stream header tells it which account the client wants to upgrade). Of course the server has to store all hashes independently (e.g. two database fields, one for SCRAM-SHA-1 and one for SCRAM-SHA-256). This wasn't outlined in the XEP because I figured details on the storage implementations of servers were out of scope for this XEP. But I could well add some wording that all hashes should be stored on the server, not only one of them. -tmolitor _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
