[JDEV] Passwords, zero-K and storage

[Thomas Muldowney]

On Fri, Jun 15, 2001 at 08:35:45PM -0500, Iain Shigeoka wrote:
> Glad you brought up this point.  I've been wondering about highly related 
> issues that might as well get thrown in.
> 

<snip/>

> Note: my comments are from a general server design standpoint and not 
> specific to jabberd.
> 
> 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.

> It would seem that the only real way of doing this is to store the 
> plaintext password and user name _somewhere_ so you can move records from 
> one authentication system to another.  (storing plain passwords, hashes, or 
> 0k sequences).  At least with the current system.  Now the implementation 
> may encrypt all these passwords so only the server can access them, or 
> perhaps a migration utility in the server, etc... but at some point, 
> somewhere, the plaintext passwords will need to exist.  Otherwise, when you 
> plug in a next generation authentication system, you'll need to have 
> everyone re-send or regenerate their password info.
> 
> Am I missing something?
> 

No, that sounds about right.  Although I would venture to guess that most next
generation auth systems won't even use passwords, rather certificates, and PKI,
so a password is possibly useless at that point, and would still require a 
registration update.  I also wonder how many clients could transparently (sp?)
do the reregistration when it has a new method.

> This of course assumes that we need to worry about new auth protocols.  If 
> the existing 2 and a half (see side note at bottom) auth protocols are 
> pretty much it, then I guess there's not much of an issue here.  However, 
> since I doubt that this is true, it seems to be a serious problem for 
> upgrading existing servers that may have thousands of user accounts.  I 
> guess what I'm trying to say is, I would like to see the auth system build 
> to support secure _and_ seamless upgrades of authentication systems.
> 
> Method 1:  My thought is either we establish a standard server-side 
> password data "format" other than plaintext to provide a common "seed" 
> password that can be used to generate passwords in whatever module we are 
> using.  So when we install a new module and the existing user accounts 
> don't have password data in their format, they can ask the server, "hey, 
> give me a seed for this user", and use the data to generate its data.  The 
> reason we need it standardized is so that future auth algorithms can be 
> designed to be compatible with the data.  To avoid plaintext, we store the 
> password in a way that the data displays certain mathematical properties 
> that can be exploited for generating new passwords in new systems while 
> preventing their use to generate current passwords with current 
> systems.  Probably not a trivial task.
> 

No this is not, because every approach, especially next generation auth,
requires specifics.  Be it a password, a sequence number, a certificate, a 
public key.  A generalized system isn't always good.  As for storing the 
password, I think you just run into the classic problem of weak passwords.  No
matter how you store it the algo to view and save the password is in the source
and it's trivial to write a cracker.  Distribute that over a network of 
computers and you'll get the pword eventually.

> 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.

> 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.
> 
> <side note>It would be nice nice for server's to be backward compatible and 
> still support digest if not plaintext passwords.  In this case, the 
> plaintext password still needs to be stored on the server even if 0k is 
> used.  I am curious to know how many are dumping backward compatibility for 
> the sake of security (pure 0k), and how many are using both or all three 
> (but since they store passwords on the server, what is the advantage of 
> 0k?).  How many clients support 0k when the spec isn't finished or 
> "approved"?</side node>
> 

I have a server that dumped all semi clear pword support, it only has 0k, plus 
4096bit SSL, plus I require anyone talking to me to have a 4096bit GPG key that
I received not through the net.  I won't even start to discuss what we talk 
about on there ;-)  (no it's not a joke).

> >[2] http://docs.jabber.org/draft-proto/html/zerok.html
> 
> <side note>I would really like to see someone (whoever implemented it in 
> jabberd) take a whack at updating this doc.    I figure they could do it 
> much easier than having one of us reverse engineer the protocol or grunt 
> through the server code.  The whole "bootstrap" process of the 
> authentication algorithm is left out and really should be specified... From 
> a "clean room" server implementation standpoint (someone not working or 
> looking at jabberd) the current omission makes 0k pretty much useless.  I 
> suppose we should wait until the Foundation/JEP/JIG etc is all settled 
> first...  *sigh*</side note>
> 
> -iain
> 
> ps - sorry for the rant.
> 

It's always good to stimulate useful conversation.


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.

--temas

ps - sorry this is so rambly, I'm still waking up
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20010620/a5c80f6b/attachment-0002.pgp>