Hi, You get the password in plain at the point when the user creates the account. Then you save it in 1 and 256.
If your question is that this is not possible anymore for people that created their account when you only offered SHA1. Yes there is no way around it, you cant migrate these users, they have to reset the password. I guess you think about only using 256 for new users, old users fail, try another mechanism and succeed. This is tricky i guess. There is nothing mentioned on how many times a client should try another mechanism or if it should at all. Scram makes it possible that a client can, but for example Gajim will not try another mechanism right now, but only because i didnt saw a reason how this could be a benefit other than hiding server implementation errors. If i were a server dev, i would probably chose to only use 256 in completely new setups, or if the operator is willing to reset all passwords. Especially in the light that its not clear if SHA256 is really a worthy gain over SHA1 in the context of SCRAM. regards Philipp 2019-01-24 16:20 GMT+01:00, Evgeny <xramt...@gmail.com>: > On Thu, Jan 24, 2019 at 6:11 PM, Florian Schmaus <f...@geekplace.eu> > 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. > 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 > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ > _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
