• exec/rlogin.js

    From Rob Swindell@VERT to Git commit to main/sbbs/master on Fri Oct 29 19:11:13 2021
    https://gitlab.synchro.net/main/sbbs/-/commit/334e768c5362ba4913316e7f
    Modified Files:
    exec/rlogin.js
    Log Message:
    Allow the client-name, server-name, and term-type to be passed as arguments

    Optional, for easier use with game servers that take one of the 3 rlogin negotation parameters as the name/code of the door to execute. A telgate
    mode flag value argument must be provided (use 0 for default behavior)
    if you want to provide any of the other arguments to override the defaults
    (the user's alias, real name, and current detected terminal type).

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Fri Aug 9 21:40:08 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/c286eb9f79a2bd10e0383ab2
    Modified Files:
    exec/rlogin.js
    Log Message:
    Fixed typo

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Mon Oct 21 11:32:07 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/454ef936c5163eece13fbe00
    Modified Files:
    exec/rlogin.js
    Log Message:
    The P, C, and v options would report 'unrecognized option'

    Fix for issue #798

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Tue Oct 29 13:45:03 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/f654c1d758fad83eaa3d19b1
    Modified Files:
    exec/rlogin.js
    Log Message:
    Allow multiple uses of -c and -s options to built-up an auth string

    To solve problem of adding some kind of prefix/tag to a user alias when connecting to a door server. e.g. ?rlogin server -s [TAG] -s %a

    Hopefully you don't need/want a space separating the string elements, as
    that's not really doable with this solution.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Thu Apr 10 12:49:18 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/dbbdd109a053fc1b6ca42c28
    Modified Files:
    exec/rlogin.js
    Log Message:
    Fix default mode value (should *not* be 10, i.e TG_NODESYNC|TG_CRLF)

    Bug introduced in commit 49053f3158e5a0b671c

    the 'mode' value was by default, undefined.
    the 'timeout' value is by default, 10.

    When mode value/flags was not provided on the command-line, undefined
    was passed to bbs.rlogin_gate() as the 5th parameter, but the number 10
    is passed as the 6th parameter (for time-out). The problem is, the first
    Number parameter passed to bbs.rlogin_gate() is interpretted as the mode
    value and so that becomes 10 (0x0A) which includes TG_NODESYNC thus enabling all node messages/activity being displayed to the rlogin user and interrupting their rlogin session (e.g. game play).

    Just make the 0 the default value for mode, like we did in telgate.js.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Thu Apr 10 14:42:03 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/0b011cc83ef109cfadb6b536
    Modified Files:
    exec/rlogin.js
    Log Message:
    Add '-h' option to send a salted and hashed password to the server

    Like the -p option, except the server won't get a copy of the client BBS
    user's password or be able to decode it.

    The user's password, user number and account creation date are used to generate the password hash (along with the salt), so changing any of these will change the resulting hashed password sent (and presumably logged/stored) on the server. The resulting SHA-1 hash is sent as 40 hexadecimal digits.

    The default salt is the system's QWK-ID, but the sysop can specify their own salt (e.g. random number or secret passphrase) via the "salt" key in the [rlogin] section of modopts.ini or root section of ctrl/modopts/rlogin.ini

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Thu Apr 10 15:13:46 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/a54caff6cb0e403b156b0a24
    Modified Files:
    exec/rlogin.js
    Log Message:
    Allow optional pepper to be specified with '-h' (hashed password) option

    e.g. '-hSEVERNAME'

    This allows server-unique hashing so that if one BBS auto-registers /authenticates its users with *multiple* Rlogin servers, the credentials
    stored on of the rlogin servers may not be used to authenticate on the others.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Sat Apr 19 13:26:00 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/d9ec9756815cdaf1e29d8477
    Modified Files:
    exec/rlogin.js
    Log Message:
    Add -H <password> option, to send specified hashed-password

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

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net