[nos-bbs] JNOS md5 authentication

[Michael Fox - N6MEF]

Thanks for clarifying Maiko.

Hmm.  This is going to cause a couple of different problems, some of which
are independent of MD5.  I'm not sure what to suggest since what I know
about cryptography is only what I can look up.  So, here's what we're doing.
>From that, maybe a different approach can be found.

Client Station configuration:

As mentioned previously, the user knows the password they selected.  So they
configure that in Outpost.  When Outpost connects to JNOS via telnet:
-- If it does NOT see the MD5 challenge, it logs in with the username and
password as usual
-- If it DOES see the MD5 challenge, it runs the algorithm against the
challenge and the password to produce and send back the proper response.

Setting the User's Password:

Since JNOS doesn't let the user set their own password, and doesn't have a
method to recover from a forgotten password, we're working on a web page to
do that.  Here's how it works:

-- The user logs into our county ARES/RACES website.
-- If they have permission to create/update a password on JNOS, then they
have access to a page that allows them to set a new initial password, update
a password, or recover from a stolen password.  The web page enforces
various rules, like password length, contents, etc.  (BTW, we use the same
mechanism for other services, like e-mail, VPN, etc.)
-- The linux machines that host our JNOS systems would run a cron job every
15 minutes that would:
	-- Download the password file over a secure connection
	-- Merge it with some other portions of the password file which are
maintained by the JNOS sysop
         (such as passwords for other BBSs, denied users, etc.)
      -- If the result is different, replace the JNOS ftpusers file.

As a result, users can manage their own passwords any time of day or night,
regardless of whether the JNOS sysop is available or not.

Now, what to do about the new encrypted system.

I presume you plan to create a random salt for each user.  I don't know
enough to comment on whether having the user know the salt is a good thing
or not.  From what I've read about the advantage of salting, it seems to
defeat the purpose of salting to expose the salt value.  But let's say we do
that.  Then:

-- We'd need a way for the user to learn what the salt is so they can
configure it in their client.

-- We'd need a new way to handle the creation of new passwords (or salts),
updating existing passwords, and recovering from lost passwords.

I realize some may think user password management is a trivial thing.  But
not when there are a couple hundred users that may use any of several JNOS
systems, depending on where they are in the county.  It's just not feasible
to do that manually.

To be clear, I'm not trying to be difficult.  Just trying to clarify the
situation so we can work toward a solution that's actually feasible in this
environment.  I'm happy to help think through alternatives.

Michael, N6MEF


-----Original Message-----

Hi Michael,

The new JNOS password management breaks the MD5AUTHENTICATE in the
sense that we can not use the cleartext password anymore. The password is
replaced with a HASH + SALT pair now. I was thinking perhaps we could keep
the MD5AUTHENTICATE working by using the SALT value instead of cleartext
password, but then one is giving away a portion of a secure database.

So last night I was thinking, why not have a MD5AUTHENTICATE password field
added to the password management, it can be a random key per user, and that
would be the key assigned to the outpost client instead of their password.

Or if you think the SALT value is enough (I think it is anyways), then 
to keep it
working for those using the new stuff, we replace password with SALT value.

I hope this makes sense. IF you really want to continue to use MD5 ...

Is the logistics of your outpost operations greatly complicated by this 
or not ?

Maiko