| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| module:rlogin [2025/04/10 16:09] – [Auto-Login] Clean-up hashed passwords doc a bit digital man | module:rlogin [2025/04/19 19:35] (current) – [Auto-Login] Document the -H option digital man |
|---|
| | ''-m'' | telnet-gateway-mode| Set of one or more [[:module:telgate#mode|telgate mode flags]] (''TG_*'') separated by pipe (''|'') symbols (default is ''0'') | | | ''-m'' | telnet-gateway-mode| Set of one or more [[:module:telgate#mode|telgate mode flags]] (''TG_*'') separated by pipe (''|'') symbols (default is ''0'') | |
| | ''-p'' | //none// | Send current user alias and password as server-name and client-name values, as expected by a Synchronet RLogin Server | | | ''-p'' | //none// | Send current user alias and password as server-name and client-name values, as expected by a Synchronet RLogin Server | |
| | ''-h'' | [//pepper//] | Send current user alias and **hashed** password as server-name and client-name values | | | ''-h'' | [//pepper//] | Send current user alias and **hashed** user-password as server-name and client-name values, optionally applying the specified //pepper// (e.g. server name) to the hashed value | |
| | | ''-H'' | password | Send current user alias and specified **hashed**-password as server and client-name | |
| | ''-q'' | //none// | Don't display banner or pause prompt (be quiet) | | | ''-q'' | //none// | Don't display banner or pause prompt (be quiet) | |
| | ''-v'' | //none// | Display remote host name/address/port in messages | | | ''-v'' | //none// | Display remote host name/address/port in messages | |
| ==== 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 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 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 (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 == |
| |
| == 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. |
