[JDEV] Passwords, zero-K and storage

[Iain Shigeoka]

At 10:22 AM 6/20/2001 -0500, you wrote:
> >
> > I've been playing around with these issues and from a modular standpoint,
> > the system seems a bit incomplete.  Theoretically, when you plug in a new
> > auth module, you should be able to use it to immediately authenticate new
> > and existing accounts (accounts established and authenticated against 
> older
> > user records).  For instance, I should be able to unplug digest and 
> plug in
> > 0k and keep on chugging.
>
>Why would this necessarily be a design goal?  An authentication system is
>something to be highly guarded and carefully used.  This is how you let users
>on your system, and just dropping in a new method is something to be carefully
>considered.  It may be nice to do that, but the ramification of having the
>user passwords stored cleartext on the server isn't pretty.  Even when you
>store crypted ones how much better is that since most people use crappy
>passwords anyway.  So I'm not totally convinced that is a design goal, 
>although
>I do feel this partially already works.

I agree.  I just want a way for a server to upgrade its authentication 
system and have clients automatically migrate to using it.  For example, I 
have a feeling that 0k may be a stop gap until we move on to something else 
(certificates?).  Anyhow, it would be nice to know that if this were to 
occur, the user base could be upgraded without reregistration.

> > 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).
>
>Is this not the get for iq:auth with registration?  Using the get on iq:auth
>the client could see the new method available, if necessary query the user for
>a password, or even offer to upgrade them, and then do so.  I mean the get was
>basically put in so people could see if 0k was available when client authors
>began implementing it, so they are basically doing what you are discussing.

Yes.  It is.  However, from a server perspective, I would probably like to 
see a way to push the information out and "enforce" it.  Basically, 
something that says, "hey client, you need to re-auth in this new way 
because the old method won't be supported for much longer".  I suppose this 
could be a "not our problem" issue.  Servers can simply offer the new auth 
method (relying on iq get), perhaps send an IM to the users when they login 
using a depreciated method saying to upgrade their clients to support it 
because the auth will change soon, and then just cut the old auth method 
out after some time.  All without any standard in place.

>Just to summarize my feelings.  I believe that the iq:auth get and the
>registration process are the correct method for this.  It allows the client to
>fully choose the upgrade path (as is necessary), and keep it mostly modular.
>Granted this whole beast isn't very well documented yet, and that largely adds
>to the problem.

:)  I can agree with this.  I would probably like this documented (that the 
client is responsible for these actions) and probably some common scenarios 
to guide both client and server developers.  Something for the new 
Standards effort once the Foundation is ready.

-iain


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com