[nos-bbs] JNOS md5 authentication

[M Langelaar]

Thanks for the feedback Michael,

The user can set their own password with the new feature, but
sysop still has to 'validate' the password file. This has more to do
with management and logistics then it does cryptography.

You've said enough, is it safe to say you 'really want to continue
to use the MD5 challenge in your overal system ?

I can do what I did with Winlink and add a third category to the
JNOS password management (2 - md5authenticate) and encrypt
the password, that way I can get the cleartext back for MD5. Seems
a bit backwards, but at least I still have no cleartext files in the end.

For those that don't use MD5AUTHENTICATE, then the 3rd categrory
will not exist, the HASH:SALT will be the only way a user password is
stored, which will cover most installations, so it's a 'okay' compromise
I suppose. Unless anyone else has an idea ?

Yep, that's what I will do then. No other way. It's actually not 'hard'.

That way you can continue without any change to your operations.

Maiko

On 09/02/2020 9:47 p.m., Michael Fox - N6MEF wrote:

> 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
>
>
>
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/nos-bbs_lists.tapr.org