> On 5 feb. 2016, at 20:04, Lance Stout <lancest...@gmail.com> wrote: > > 3) This does not really decrease the initial authentication and subsequent > stream setup time. It is still using the full SASL process, so time wise > it is exactly the same as PLAIN. It is exactly one round trip faster than > SCRAM-SHA-1. It does use less hashing, which I agree can have a noticeable > delay in some browsers; however, the derived materials generated during > SCRAM-SHA-1 can be cached to significantly reduce the calculation time > for subsequent logins, and also serve as a secure replacement for the > plaintext password (which is also revokable by the server using a new salt).
I agree with most of your points, however, the salt can only be changed by the server if the server is not using hashed storage. If the server stores only ServerKey and StoredKey (plus the salt and iteration count) it can not change the salt without downgrading to PLAIN or resetting the user's password. I think the iteration count can be increased with hashed storage, but I'm not 100% sure. Provided the client has cached the ClientKey and StoredKey the only intensive computations are 3 times HMAC-SHA1. This will likely be negligible even on phones. Regards, Thijs
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
