Actually, getting rid of a master passwords is exactly what our server team is working on. Here's what design features we're implementing: 1) on connect with login/password device is issued a token, and a session stops. Device has to reconnect with a token. No concurrent sessions are allowed with one token. 2) every connected device has a token, and only one. It should not regenerate tokens for every new connection 3) a device can issue another token for the use in another device (like, connected web client can issue a token and present it as a QR code, so mobile client can scan it and instantly connect) 4) on issuing a new token all devices get a message with warning, 'new token issued' 5) it is possible to get a list of all issued tokens, and revoke them, all or individually 6) the other way to revoke all tokens is to connect with login/password and revoke all tokens. This way a malintentioned entity which obtained a token will not be able to break authorized users's session before he can possibly revoke former's token.
As for certificates to be used & SASL external, well, don't know it it has something to do with tokens. I also think that 'master password' in our scheme is redudnant, it's just a 'password'. If a server developer wants to provide such functionality it can be outside of the standard's scope. чт, 14 февр. 2019 г. в 15:02, Florian Schmaus <[email protected]>: > I want to start an effort, both on the specification side and > implementation side, for easier onboarding and to get rid of "master" > passwords on user's devices. > > As far as I can tell, this requires three mechanisms: > 1) A one-time token authentication mechanism > 2) A mechanism for clients allowing them to request their servers sign a > client-provided certificate signing request (CSR) so that the resulting > certificate can be used for authentication (using SASL EXTERNAL) > 3) A mechanism for clients to request a "master recovery password" from > the server > > A user story could go like this: A server operator generates a new > account for the user on his XMPP service *and* a QR code which contains > the JID and the one-time authentication token. Now the user installs an > XMPP client and scans the QR code. The client authenticates using the > one-time token and immediately after successful authentication generates > a X509 certificate and a certificate signing request (CSR). The CSR is > then sent to the server to sign, which the server happily does. From now > on the client uses the certificate using SASL EXTERNAL to authenticate. > The client also (optionally) requests a master recovery password from > the server and tells the user to write the master password down and keep > it in a safe place (back of the user keyboard, obviously). This master > recovery password can be used by the user to reclaim his account in case > he lost access to all of his devices, or to bootstrap a new device. > > As far as I can tell we do not have a specification for any of the three > mechanisms (happy to stand corrected). Since all three mechanisms are > independent of each other, they could be used standalone and can be > developed separate. > > For now, I would like to focus on (2), to get rid of master passwords > from devices and move towards per-device-certificate SASL EXTERNAL > authentication. I already talked with a few client and server developers > at FOSDEM about this and received some valuable feedback. Now I'd like > to gather input from a wider audience. > > Your feedback is much appreciated. > > - Florian > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04 http://www.redsolution.ru
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
