Synchronet v3.21e-Win32 (install) has been released (Mar-2026).

You can donate to the Synchronet project using PayPal.

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
module:rlogin [2025/04/19 19:19] – [Command-line] Add the -H option digital manmodule:rlogin [2025/12/13 17:34] (current) – [Auto-Login] fixed typos digital man
Line 70: Line 70:
 ==== Auto-Login ==== ==== Auto-Login ====
  
-For automated logins, [[server:Terminal#RLogin|Synchronet RLogin Server]] requires the //client-user-name// to be a valid user password, and the //server-user-name// to be a valid user ID (e.g. alias) which corresponds with the password.+For automated logins, the [[server:Terminal#RLogin|Synchronet RLogin Server]] requires the //client-user-name// to be a valid user password, and the //server-user-name// to be a valid user ID (e.g. alias) which corresponds with the password.
  
-Other RLogin servers (e.g. door game servers) may have different requirements for automated logins (e.g. no password).+Other RLogin servers (e.g. door game servers) may have different requirements for automated logins (e.g. //no// password).
  
 === Hashed Passwords === === Hashed Passwords ===
  
-Hashed passwords can be used to secure the local BBS user's password.+Hashed passwords can be used to securely authenticate the local BBS user with the remote RLogin server without leaking the user's local password.
  
-In some use cases, the RLogin server may be expected store/remember the sent client-user-name as a password for subsequent connection authentication (e.g. when a Synchronet RLogin server is used as a public Game Server).+In some use cases, the RLogin server may be expected to store/remember the sent client-user-name as a password for subsequent connection authentication (e.g. when a Synchronet RLogin server is used as a public Game Server).
  
 The ''-h'' command-line option (an alternative to the ''-p'' option) can be used to obfuscate the user's password that is sent to the potentially third-party RLogin server via 128-bit secure hashing algorithm (SHA-1), while still creating a unique, cryptographically secure password. The ''-h'' command-line option (an alternative to the ''-p'' option) can be used to obfuscate the user's password that is sent to the potentially third-party RLogin server via 128-bit secure hashing algorithm (SHA-1), while still creating a unique, cryptographically secure password.
-The user's password, user number, and account creation date are used to generate the password hash, so changing any of these values 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 user's password, user number, and account creation date are used to generate the password hash, so changing any of these values will change the resulting hashed password sent to (and presumably logged/stored on) the server. The resulting SHA-1 hash is sent as 40 hexadecimal digits.
  
-Included in the hashed parameters are so-called //salt// and //pepper// (strings of characters) to help insure that the a user with the same number, password, and creation date on another BBS won't generate the same hash value that is sent to the RLogin server (allowing a malicious server to identify users with same password). +Included in the hashed parameters are so-called //salt// and //pepper// (strings of characters) to help insure that the a user with the same number, password, and creation date on another BBS won't generate the same hash value that is sent to the RLogin server (allowing a malicious server to identify users with same passwords). 
 + 
 +The ''-H'' command-line option (an alternative to the ''-h'' option) uses a command-line supplied password (i.e. by the sysop) rather than the local user's password, to generate the password hash. This option allows a BBS to uniquely identify and authenticate users to an external RLogin server without using the user's local password, so subsequent changes to the user's password will not invalidate the RLogin credentials. If the Rlogin gateway is used to connect to multiple 3rd party RLogin servers, a different password value should be provided by the sysop for each RLogin server in order to prevent potential password hash duplication/reuse among systems. Passwords hashed with this option include //salt// but not //pepper// as the sysop-provided password already provides the function of "pepper".
  
 == Salt == == Salt ==
Line 89: Line 91:
  
 == Pepper == == Pepper ==
-To insure that a different hash is generated for use on different RLogin servers, a sysop may include server-unique data (so called "pepper") immediately after the ''-h'' option on the ''rlogin_gate'' command-line.+To insure that a different hash is generated for use on different RLogin servers, a sysop may include server-unique data (so called "pepper") immediately after the ''-h'' option on the ''rlogin'' command-line.
  
-When multiple 3rd party RLogin servers are being connected to with hashed passwords, it is recommended to include a different pepper value for each RLogin serverm, e.g. ''-hSEVERNAME''.+When multiple 3rd party RLogin servers are being connected to with hashed passwords, it is recommended to include a different pepper value for each RLogin server, e.g. ''-hSEVERNAME''.
  
-Including pepper allows server-unique hashes so that if one BBS auto-registers/authenticates its users with *multiple* RLogin servers, the credentials stored any //one// of the RLogin servers may not be used to authenticate on the others.+Including pepper allows server-unique hashes so that if one BBS auto-registers/authenticates its users with **multiple** RLogin servers, the credentials stored any //one// of the RLogin servers may not be used to authenticate on the others.
  
  

Trace: • RLogin Gateway • load directory