[JDEV] Passwords, zero-K and storage

[David Waite]

Iain Shigeoka wrote:

> Method 2:  Another approach is to establish yet another protocol to allow
> clients to authenticate with an existing auth module, then once logged in,
> generate new information with a new auth module to "upgrade" to that
> authentication scheme.  This protocol can be very simple (e.g. force the
> client to auth twice: first with one module then with another) but the
> clients need to know about this in a standard (otherwise, only client A
> will work with server A).  This approach is basically a "let the client
> worry about it" strategy.  The client must know the plain text password,
> and can authenticate against both systems using it.  The worry is that
> client's will have a lot of auth bloat having to be able to support all
> auth systems in order to seamlessly access any jabber server (versus only
> needing to know about one auth method and use it on any jabber server if
> the server's are responsible for making these conversions).

I would say a third method should just be to have the authentication module
handle authentication, not the server. Currently for all three methods
(plaintext, digest, 0k), the server fetches data and compares internally - it
should instead just *ask* some external authentication service whether or not
the user is authenticated.

This would not provide migration for users within jabber XDB to some service
outside of xdb - but if you are authenticating against a system such as
LDAP or kerberos, you don't want to do this anyways.

> So far this has not been an issue because we've always had the plaintext
> password on the server which served as the common data format for password
> information (method 1 with plaintext being the special password storage
> format... ha ha ha).  It was easy to upgrade to 0k because we could upgrade
> people on the server using the plaintext password.  However, I expect that
> many/most would like to use the 0k advantage of no plaintext password at
> all on the server.  If this is the case, then the next auth protocol (if
> there will be one) is in for some trouble if we don't address things
> sometime.

If someone really wants passwords to be secure, they need to use a secure
method of account registration, authentication, and renewal in the case of 0k.
The only secure registration method I've seen so far is Jabber-thru-SSL, and
the server does not enforce any behavior based on the connection being through
or not through SSL (such as limiting plaintext authentication, turning off
registration, not allowing password changes). There is a lot of work left.

-David Waite