sbbs

... rather than a hash of the *user's* password. This allows the local
user to potentially change their password later without invalidating it on
the RLogin server, assuming the RLogin server saves/reuses the specified
password for subsequent authentication (as the Synchronet terminal server
does).

The existing -h option still works as before, but it's a known issue that if
a user changes their password locally, they will no longer be able to
re-authenticate with any RLogin servers they previously created accounts on
using the previous password.

With the -H option, the sysop is instead in control of the password used and
since the resulting hash is from a combination and system and user unique
source data (including optinal salt), as long the same -H password is not used
for multiple 3rd party Rlogin servers, the hashed password should be secure
from capture and reuse on any other RLogin server (or the local server).

While the -h option might be slightly more secure (since a different user
password is likely used for each generated hash), the -H option is less
error-prone and still considered (by me) to be secure from password leaking
and malicious reuse.