[JDEV] Passwords, zero-K and storage
iainshigeoka at yahoo.com
Fri Jun 15 20:35:45 CDT 2001
Glad you brought up this point. I've been wondering about highly related
issues that might as well get thrown in.
At 11:52 PM 6/15/2001 +0100, DJ Adams wrote:
>there was a question in the jdev room about how to avoid storing usernames
>and passwords in the <username>.xml files on the server.
>I blurted out 'zero-K!' for half the answer - a way of "removing the
>liability of storing password on the server". This was followed by
>another answer a couple of mins later which contradicted me. I tried
>it out on my server, and sure enough, even when the mod_auth_plain and
>mod_auth_digest modules were commented out of JSM's load list, a password
>in plain text was stored on the server as well as the zero-K stuff.
>Anyway, I would suggest that the snippet of code in mod_register_new()
>shown above is both redundant and wrong, and should be removed. The
>purpose of this code is served by mod_auth_plain and / or mod_auth_0k.
>Of course, I'm ready to be contradicted again; I'd like to hear what
>others think. I've tried this out (removing the snippet) on my test
>server and it solves the problem and doesn't cause any others, as far
>as my minimal testing has shown.
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.
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?
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.
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).
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
<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
<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>
ps - sorry for the rant.
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
More information about the JDev