1. Forum
  2. FidoNet
  3. SYNC PROGRAMMING

  • src/sbbs3/useredit.cpp

    From deon@1:103/705 to Tracker1 on Sun Mar 5 14:41:15 2023
    Re: src/sbbs3/useredit.cpp
    By: Tracker1 to deon on Sat Mar 04 2023 08:41 pm

    Howdy,

    Because supported authentication mechanisms, such as CRAM-MD5 rely on having the original (unencrypted) passphrase, or at least an intermediate representation. Because of this, it would effectively need reversable encryption... and because with SBBS this would most likely mean a key that is right next to the vault... there's not much point in locking said vault.

    Yeah, I hadnt considered the email authentication methods, like CRAM-MD5, that authenticated based on a known shared secret (the password), without transferring that over the wire. I believe that is the only other auth method that SBBS uses (over passwords in the clear).

    But I dont agree with the last point "no much point locking said vault". I still think that having the passwords encrypted with a key is still better than having the password in the clear. But that might just be my view...

    (I do understand that in the event that a non authorised person has access to the filesystem, that encrypting is no more secure if they key is just as easy to obtain. But if the key can only be visible to a specific user, and somebody breaks in impersonating that user, then you have bigger problems.)


    ...����

    ---
    � Synchronet � AnsiTEX bringing back videotex but with ANSI
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Sat Mar 4 20:24:09 2023
    Re: src/sbbs3/useredit.cpp
    By: deon to Tracker1 on Sun Mar 05 2023 02:41 pm

    Re: src/sbbs3/useredit.cpp
    By: Tracker1 to deon on Sat Mar 04 2023 08:41 pm

    Howdy,

    Because supported authentication mechanisms, such as CRAM-MD5 rely on having the original (unencrypted) passphrase, or at least an intermediate representation. Because of this, it would effectively need reversable encryption... and because with SBBS this would most likely mean a key that is right next to the vault... there's not much point in locking said vault.

    Yeah, I hadnt considered the email authentication methods, like CRAM-MD5, that authenticated based on a known shared secret (the password), without transferring that over the wire. I believe that is the only other auth method that SBBS uses (over passwords in the clear).

    There are several secure (non-plain text) authentication methods that Synchronet supports which assume the server has access to the user password in plain text, e.g. SSH password auth, HTTP digest auth, APOP, etc.

    But I dont agree with the last point "no much point locking said vault". I still think that having the passwords encrypted with a key is still better than having the password in the clear. But that might just be my view...

    Not clear how/why that would be better. It would certainly give the impression of secure-password storage, but without the actual security. That sounds to me
    "worse", not "better".
    --
    digital man (rob)

    This Is Spinal Tap quote #11:
    Nigel Tufnel: No. no. That's it, you've seen enough of that one.
    Norco, CA WX: 47.3�F, 88.0% humidity, 3 mph SE wind, 0.01 inches rain/24hrs
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Sun Mar 5 20:47:31 2023
    Re: src/sbbs3/useredit.cpp
    By: Digital Man to deon on Sat Mar 04 2023 08:24 pm

    Not clear how/why that would be better. It would certainly give the impression of secure-password storage, but without the actual security. That sounds to me "worse", not "better".

    What was the motivation for unix developers to change /etc/passwd from having clear text passwords, to having DES crypt passwords? I'm sure at the time, folks didnt implement it becasue they thought it was "worse"?

    There are several secure (non-plain text) authentication methods that Synchronet supports which assume the server has access to the user password in plain text, e.g. SSH password auth, HTTP digest auth, APOP, etc.

    Anyway, I get it - for challenge reponse mechanisms, SBBS doesnt have a "password database" for each type in use - prefering to having a single store for the user's password.


    ...����

    ---
    � Synchronet � AnsiTEX bringing back videotex but with ANSI
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Sun Mar 5 03:08:16 2023
    Re: src/sbbs3/useredit.cpp
    By: deon to Digital Man on Sun Mar 05 2023 08:47 pm

    Re: src/sbbs3/useredit.cpp
    By: Digital Man to deon on Sat Mar 04 2023 08:24 pm

    Not clear how/why that would be better. It would certainly give the impression of secure-password storage, but without the actual security. That sounds to me "worse", not "better".

    What was the motivation for unix developers to change /etc/passwd from having clear text passwords, to having DES crypt passwords? I'm sure at the time, folks didnt implement it becasue they thought it was "worse"?

    Those passwords aren't reversable (able to be decrypted to the original clear text password) they're one-way hashes of a password. Not the same thing. A one-way hash of a password is more secure than storing the same password in either clear text or in a reversible form, but it also limits the subsequent uses of that stored hashed-password.
    --
    digital man (rob)

    Sling Blade quote #5:
    Karl Childers (to father): You ought not killed my little brother...
    Norco, CA WX: 45.3�F, 87.0% humidity, 0 mph ENE wind, 0.01 inches rain/24hrs --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Sat May 6 12:56:09 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/28fc0106f3e47e6ff2f36138
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    PETSCII terminals can't send { and }, so support ( and ) for search fwd/back --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Sat Jun 3 20:06:03 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/653e43e8449bf6b9bfb3a27a
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Hitting Ctrl-C at the "Use external editor" prompt shouldn't change anything --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Windows)@1:103/705 to Git commit to main/sbbs/master on Thu Sep 14 21:28:57 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/8d60770fa44d0ea8dd09d48b
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Change external editor yes/no prompt default to match current user settingAlso, although not a bug (because we re-read/parse the user's record everymenu cycle), don't decrement user.xedit before calling uselect()- just not a good practice to not modify variables unnecessarily.See the corresponding change to exec.cpp, which was a bug.
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Windows)@1:103/705 to Git commit to main/sbbs/master on Sat Sep 23 20:29:02 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/d71cce5ffce2d856b8b0f783
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Clear line counter before starting the user settings/config menu.

    Fixes unnecessary [Hit a key] prompt.
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Windows 11)@1:103/705 to Git commit to main/sbbs/master on Wed Nov 22 15:30:20 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/0bd7a0af71cf7e7b13edc6bc
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Fix CID 32913

    getkeys() could return -1 if user disconnects (and SS_ABORT not set), so this appears to be a valid bug.
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Windows 11)@1:103/705 to Git commit to main/sbbs/master on Thu Oct 10 12:32:57 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/583ab9195d04961c697a10cd
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Always reload the edited user record from disk after executing a "usercfg_mod"

    Normally, when modifying user fields via JS, the "user modified" node.dab
    flag would be set for that user (on all node's that user is logged-into) and the user record automatically re-read (soon after). But this doesn't work during newuser registration because the user is not yet "logged-into" a node.

    This fixes the issue reported by Nelgin (and observed on amessyroom's BBS) whereby if a new user resets/changes their external message editor, it would not take effect for their new user validation email to the sysop (they would still be using the default new user message editor as configured by the
    sysop).

    It's possible other new user default changes made (e.g. language) would also not have taken immediate effect as a result of this bug (now fixed).
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Windows 11)@1:103/705 to Git commit to main/sbbs/master on Mon Dec 16 18:24:31 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/207546a2b6e2ce0852852cda
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    openuserdat() was recently changed to not always return -1 on error
    --- SBBSecho 3.23-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Windows 11)@1:103/705 to Git commit to main/sbbs/master on Tue Jan 7 16:57:30 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/f7c75dee778e0383c550e0bd
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Populate the security level string being edited with current level (number)

    This appears to have been the original intention (otherwise, why call ultoa?), but was never done. Just a usability/convenience thing, but an apparent bug. --- SBBSecho 3.23-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Windows 11)@1:103/705 to Git commit to main/sbbs/master on Mon Dec 8 22:29:46 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/8ae00a5795ce733593c2c4ef
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Clean up the sbbs_t::console (JS console.status) bit flags

    Mainly this is renaming CON_R_ECHOX to CON_PASSWORD, but also eliminating several long-unused flags.
    --- SBBSecho 3.32-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Windows 11)@1:103/705 to Git commit to main/sbbs/master on Tue Dec 30 16:39:35 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/e891fb86becbb3f383eb47e2
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Remove the user (defaults) config menu that is now handled in user_settings.js

    Since the user config mod defaults to this script name (if blank), there
    was really no way to revert to the hard-coded logic any more anyway.
    --- SBBSecho 3.34-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Wed May 6 22:36:57 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/8d4a10dfb54ef3d9108a829b
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    useredit: log error if user_config getuserdat fails (CIDs 516411, 530902)

    After invoking the external user-config module the in-memory user_t
    needs to be re-read; if getuserdat fails the caller proceeds with
    stale data. Log the error like purgeuser() already does.

    CID 516411 was originally reported against the now-removed maindflts() function; it appears to have been merged into user_config(), so the
    single fix covers both CIDs.

    Co-Authored-By: Claude Opus 4.7 <[email protected]>
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Windows 11)@1:103/705 to Git commit to main/sbbs/master on Tue Jul 28 14:27:05 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/7ad244479109ee15f456a253
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    uedit: free search expressions on early loop exit (CID 651709)

    Coverity CID 651709 (RESOURCE_LEAK): "Variable find_expr going out of
    scope leaks the storage it points to", at useredit.cpp:108.

    sbbs_t::useredit() releases both of its heap allocations -- 'ar' (the
    '/' ARS search) and 'find_expr' (the 'T' boolean text search) -- in the
    'Q'uit case and again after the display/command loop. Two returns
    inside the loop skip that cleanup: the "no user data" bail-out, and the localtime32() failure Coverity flagged. The loop redraws the record on
    every pass, so both are reachable after a search has been entered, and
    both leak 'ar' as well as 'find_expr'.

    Break out of the loop instead of returning, so the existing cleanup
    runs. Behavior is otherwise unchanged.

    find_expr, and the free(ar) at the loop exit, are from ef1f8026a4
    (2026-07-25); the 'ar' leak on these two paths predates it.

    Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)