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
module:rlogin [2025/04/19 19:35] – [Auto-Login] Document the -H option digital manmodule:rlogin [2025/12/13 17:34] (current) – [Auto-Login] fixed typos digital man
Line 78: Line 78:
 Hashed passwords can be used to securely authenticate the local BBS user with the remote RLogin server without leaking the user's local 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 passwords). 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).
Line 95: Line 95:
 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''. 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: