On Donnerstag, 24. Januar 2019 16:20:57 CET Evgeny wrote: > On Thu, Jan 24, 2019 at 6:11 PM, Florian Schmaus <[email protected]> > > wrote: > > Then you can't authenticate unless the server also stores the > > authentication data for SCRAM-SHA1. I guess that is your point. What > > is > > wrong with the server storing the required data to authenticate > > clients > > with eg. SCRAM-SHA1 or SCRAM-SHA256 (besides the implementation > > overhead > > argument)? Maybe I am missing something? > > I am not sure what you mean. I can only do that on the server > if I get plain password from the client which is something SCRAM > was designed to prevent if I understand it correctly.
You see the plaintext password during registration. That’s when you create the SCRAM blobs on the server side. > Also, the problem still remains with upgrading existing > SHA-1 to SHA-256/384/512/whatever and if I don't upgrade it there > is possibility to create interop problem again, unless a client > 1) supports all previous SHA versions > 2) doesn't treat previous SHA versions as a downgrade attack Upgrading SCRAM is a Pain In The you-know-what, as you correctly identified yourself. The interoperability with other services isn’t great either, as you also identified. For stuff like TURN/STUN/... I would suggest to investigate the possibility of tokens for user authentication (which cannot be used to log into the XMPP service). I think I’ve seen such an implementation of a STUN/TURN/XMPP setup in the past, but I can’t remember where. kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
