• src/sbbs3/useredit.cpp

    From Rob Swindell@VERT to Git commit to main/sbbs/master on Sat Jul 31 13:00:34 2021
    https://gitlab.synchro.net/main/sbbs/-/commit/a53829d34393689015add034
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Stop beeping at the sysop when user-searches are successful.

    If anything, I suppose would be beep if a search fails, but really, I think beeps are kind of annoying these days. Not changing the currently selected/viewed user is likely all that's really needed to indicate a search failure.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Thu Mar 3 16:45:56 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/8118291d967d67119f28a4ad
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Check return value of filelength()

    Fix CID 33266: Negative loop bound

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Sun Mar 6 16:06:49 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/d8c36d9d898830fa0b8456f9
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Remove unnecessary current user (co-sysop) level/flag checks

    As Andre pointed out, these checks perform no function because a user with a level lower than the user being edited cannot enter the related command-key anyway.

    This was just effectively dead code that was held-over from ancient SBBS days, seemingly before I learned to effectively use the || operator:
    if(!(atoi(str)>useron.level && console&CON_R_INPUT))

    :-)

    Fixes issue #361

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Fri Dec 30 16:20:50 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/c7eb313c0a749c22975e5a37
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Don't assign to unused variable

    CID 433272

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Sat Jan 21 21:49:11 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/d83001e8cff767fcd80261d6
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Better handling of Quit/Ctrl-C at default protocol selection

    IF user hits 'Q' (or whatever the "Quit" key is), set the default protocol field in the user record to " " (instead of an empty string).
    If user hits abort (Ctrl-C), don't make any change to the default protocol.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on ChromeOS)@VERT to Git commit to main/sbbs/master on Sat Feb 25 23:13:17 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/c4aba51b7290fc74743cf78b
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Display more of the user's password

    Reversed the order of the pwmod date and the password itself.
    The number of chars of the user's password displayed depends on the
    terminal width. e.g. on an 80 column terminal, 18 chars will be
    displayed. If the user's password is longer than what can be displayed,
    this is indicated with a trailing "..". Wider displays (e.g. 132 column)
    can display all 40 chars of a user's password.

    This fixes issue #442

    When passwords aren't displayed (due to sysop configuration), show
    "<hidden>" instead of "XXXXXXXX" to make that more clear.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From MRO@VERT/BBSESINF to Rob Swindell (on ChromeOS on Sun Feb 26 13:09:45 2023
    Re: src/sbbs3/useredit.cpp
    By: Rob Swindell (on ChromeOS) to Git commit to main/sbbs/master on Sat Feb 25 2023 11:13 pm


    This fixes issue #442

    When passwords aren't displayed (due to sysop configuration), show


    do you have plans to encrypt the user passwords and system passwords in the data files?
    ---
    þ Synchronet þ ::: BBSES.info - free BBS services :::
  • From Digital Man@VERT to MRO on Sun Feb 26 12:30:50 2023
    Re: src/sbbs3/useredit.cpp
    By: MRO to Rob Swindell (on ChromeOS on Sun Feb 26 2023 01:09 pm

    Re: src/sbbs3/useredit.cpp
    By: Rob Swindell (on ChromeOS) to Git commit to main/sbbs/master on Sat Feb 25 2023 11:13 pm


    This fixes issue #442

    When passwords aren't displayed (due to sysop configuration), show


    do you have plans to encrypt the user passwords and system passwords in the data files?

    No immediate plans, no.
    --
    digital man (rob)

    Synchronet "Real Fact" #103:
    Synchronet added PETSCII (e.g. C64/C128) terminal support in October of 2018 Norco, CA WX: 49.4øF, 74.0% humidity, 7 mph E wind, 0.35 inches rain/24hrs
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From MRO@VERT/BBSESINF to Digital Man on Sun Feb 26 18:46:55 2023
    Re: src/sbbs3/useredit.cpp
    By: Digital Man to MRO on Sun Feb 26 2023 12:30 pm


    When passwords aren't displayed (due to sysop configuration), show


    do you have plans to encrypt the user passwords and system passwords in the data files?

    No immediate plans, no.

    what the helllll.

    why is that not being considered?
    ---
    þ Synchronet þ ::: BBSES.info - free BBS services :::
  • From Digital Man@VERT to MRO on Sun Feb 26 17:11:03 2023
    Re: src/sbbs3/useredit.cpp
    By: MRO to Digital Man on Sun Feb 26 2023 06:46 pm

    Re: src/sbbs3/useredit.cpp
    By: Digital Man to MRO on Sun Feb 26 2023 12:30 pm


    When passwords aren't displayed (due to sysop configuration), show


    do you have plans to encrypt the user passwords and system passwords in the data files?

    No immediate plans, no.

    what the helllll.

    why is that not being considered?

    It's been discussed at length before, but basically it comes down to:
    providing the illusion of security is a worse crime than not providing the requested security feature in the first place.

    Synchronet supports many methods of secure authentication (e.g. CRAM-MD5) which means we do practically need the original user password in plan text in memory as some point during the authentiation process(es). So we'd have to have a way to decrypt an encrypted password (i.e. stored in user.tab file). Which means you'd have to have a private key stored somewhere. Is that private key store secure? If it's just a file in the sbbs directory tree, its no more secure than the user.tab file. You see where this is going?

    What's the point of encrypting the passwords in the user.tab file if all a prying-eye needs is another file from the same directory tree to use as the key to decrypt them?
    --
    digital man (rob)

    Breaking Bad quote #18:
    Already, Operation: TBD, thanks for nothing Gomey. - Hank Schrader
    Norco, CA WX: 48.1øF, 69.0% humidity, 2 mph E wind, 0.27 inches rain/24hrs
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From MRO@VERT/BBSESINF to Digital Man on Sun Feb 26 21:18:51 2023
    Re: src/sbbs3/useredit.cpp
    By: Digital Man to MRO on Sun Feb 26 2023 05:11 pm

    Synchronet supports many methods of secure authentication (e.g. CRAM-MD5) which means we do practically need the original user password in plan text in memory as some point during the authentiation process(es). So we'd have to have a way to decrypt an encrypted password (i.e. stored in user.tab file). Which means you'd have to have a private key stored somewhere. Is that private key store secure? If it's just a file in the sbbs directory tree, its no more secure than the user.tab file. You see where this is going?

    What's the point of encrypting the passwords in the user.tab file if all a prying-eye needs is another file from the same directory tree to use as the key to decrypt them?

    i dunno, just seems weird that the passwords are in plain text in a few places. if you think it's okay then i guess it is.

    people just have to look at the old and new scripts they use so they can't type a file on the system.
    ---
    þ Synchronet þ ::: BBSES.info - free BBS services :::
  • From deon@VERT/ALTERANT to Digital Man on Mon Feb 27 15:30:54 2023
    Re: src/sbbs3/useredit.cpp
    By: Digital Man to MRO on Sun Feb 26 2023 05:11 pm

    Howdy,

    in memory as some point during the authentiation process(es). So we'd have to have a way to decrypt an encrypted password (i.e. stored in user.tab file). Which means you'd have to have a private key stored somewhere. Is that private key store secure? If it's just a file in the sbbs directory tree, its no more secure than the user.tab file. You see where this is going?

    Why is it needed to decrypt it?


    ...ëîåï

    ---
    þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
  • From Digital Man@VERT to deon on Sun Feb 26 21:32:36 2023
    Re: src/sbbs3/useredit.cpp
    By: deon to Digital Man on Mon Feb 27 2023 03:30 pm

    Re: src/sbbs3/useredit.cpp
    By: Digital Man to MRO on Sun Feb 26 2023 05:11 pm

    Howdy,

    in memory as some point during the authentiation process(es). So we'd have to have a way to decrypt an encrypted password (i.e. stored in user.tab file). Which means you'd have to have a private key stored somewhere. Is that private key store secure? If it's just a file in the sbbs directory tree, its no more secure than the user.tab file. You see where this is going?

    Why is it needed to decrypt it?

    I'm not sure I understand your question. Why is a key needed to decrypt a password? Because that's how reversable encryption works. <shrug>
    --
    digital man (rob)

    Sling Blade quote #7:
    Karl: I don't reckon the Good Lord would send anybody like you to Hades.
    Norco, CA WX: 42.6øF, 79.0% humidity, 0 mph NE wind, 0.18 inches rain/24hrs
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From deon@VERT/ALTERANT to Digital Man on Mon Feb 27 20:08:02 2023
    Re: src/sbbs3/useredit.cpp
    By: Digital Man to deon on Sun Feb 26 2023 09:32 pm

    in memory as some point during the authentiation process(es). So we'd have to have a way to decrypt an encrypted password (i.e. stored in user.tab file). Which means you'd have to have a private key stored somewhere. Is that private key store secure? If it's just a file in the sbbs directory tree, its no more secure than the user.tab file. You see where this is going?

    Why is it needed to decrypt it?

    I'm not sure I understand your question. Why is a key needed to decrypt a password? Because that's how reversable encryption works. <shrug>

    So you said "We'd have to have a way to decrypt an encrypted password".

    My question, is why do you need to decrypt it?

    This message is in the context that somebody asked if you had plans to encrypt user's passwords.



    ...ëîåï

    ---
    þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
  • From echicken@VERT/ECBBS to deon on Mon Feb 27 14:44:25 2023
    Re: src/sbbs3/useredit.cpp
    By: deon to Digital Man on Mon Feb 27 2023 20:08:02

    So you said "We'd have to have a way to decrypt an encrypted password".

    My question, is why do you need to decrypt it?

    IIRC the reason is that Synchronet supports many protocols, each with different authentication mechanisms. We need the client to send us something that can be compared to what we have on file. It's not possible to do this across the board if we don't have the plain password to start from.

    So we either resort to the lowest common denominator, or we store the encrypted password in many permutations per user, or we require different passwords for different services.

    ---
    echicken
    electronic chicken bbs - bbs.electronicchicken.com
    ---
    þ Synchronet þ electronic chicken bbs - bbs.electronicchicken.com
  • From MRO@VERT/BBSESINF to echicken on Mon Feb 27 10:59:02 2023
    Re: src/sbbs3/useredit.cpp
    By: echicken to deon on Mon Feb 27 2023 02:44 pm

    that can be compared to what we have on file. It's not possible to do this across the board if we don't have the plain password to start from.

    So we either resort to the lowest common denominator, or we store the encrypted password in many permutations per user, or we require different passwords for different services.

    so you think other comparable softwares do the same thing? I wasn't aware of that. having passwords in multiple files in plain text seems insecure.

    also how about just encrypting the system password? i'd be happy with that atleast. sure it needs to be decrypted somehow. does that just make it not worth doing? with the wrong script running, someone can get full access. i've done it several times to demonstrate.
    ---
    þ Synchronet þ ::: BBSES.info - free BBS services :::
  • From echicken@VERT/ECBBS to MRO on Mon Feb 27 18:01:50 2023
    Re: src/sbbs3/useredit.cpp
    By: MRO to echicken on Mon Feb 27 2023 10:59:02

    encrypted password in many permutations per user, or we require
    different
    passwords for different services.

    so you think other comparable softwares do the same thing? I wasn't aware of that. having passwords in multiple files in plain text seems insecure.

    I don't know about comparable, but I've used things that required a different password for some protocol. I had a separate POP3 password in gmail, for example. I don't know if this was for a technical reason or if it was like a revokable 'device password'.

    By multiple permutations I mean hash the password several different ways, storing each result (probably in the same file), but never the original. The goal being to have hashes on hand compatible with different protocols. It'd be a huge pain though, and I haven't thought it through. Might not work at all.

    also how about just encrypting the system password? i'd be happy with that atleast. sure it needs to be decrypted somehow. does that just make it not worth doing? with the wrong script running, someone can get full access. i've done it several times to demonstrate.

    The main problem is how to safely pass in the encryption key so that there's been a net improvement in security. An environment variable is probably the only real answer, and even then not fully. At least then it's passed in at runtime, not on the command line, and not necessarily in a file on disk.

    Depending on what you mean by running the wrong script, there isn't always much to be done to protect sysops from themselves. A JS module could do whatever it wanted to your BBS, and I don't think most sysops realize how much trust is involved there. Some shell script or batch file running as your BBS user could do a lot of damage or see a lot of data, which encryption might mitigate depending on the scenario.

    ---
    echicken
    electronic chicken bbs - bbs.electronicchicken.com
    ---
    þ Synchronet þ electronic chicken bbs - bbs.electronicchicken.com
  • From Digital Man@VERT to deon on Mon Feb 27 10:55:06 2023
    Re: src/sbbs3/useredit.cpp
    By: deon to Digital Man on Mon Feb 27 2023 08:08 pm

    Re: src/sbbs3/useredit.cpp
    By: Digital Man to deon on Sun Feb 26 2023 09:32 pm

    in memory as some point during the authentiation process(es). So we'd have to have a way to decrypt an encrypted password (i.e. stored in user.tab file). Which means you'd have to have a private key stored somewhere. Is that private key store secure? If it's just a file in the sbbs directory tree, its no more secure than the user.tab file. You see where this is going?

    Why is it needed to decrypt it?

    I'm not sure I understand your question. Why is a key needed to decrypt a password? Because that's how reversable encryption works. <shrug>

    So you said "We'd have to have a way to decrypt an encrypted password".

    My question, is why do you need to decrypt it?

    To perform secure hash based authentication (e.g. CRAM-MD5), you either need the original password, in plain text, or you need a pre-hashed (unsalted) password using the same crypto-hash scheme as that method of authentication. Since we support multiple methods of secure authentication using very different crypto algorithms/secure-hashes, we need the original password in plain text. That means if the password were stored encrypted, we'd have to be able decrypt it (on the fly).

    This message is in the context that somebody asked if you had plans to encrypt user's passwords.

    I understand.
    --
    digital man (rob)

    Synchronet/BBS Terminology Definition #40:
    HTTPS = Secure HTTP (authenticated and encrypted HTTP over TLS)
    Norco, CA WX: 50.3øF, 70.0% humidity, 0 mph NNE wind, 0.00 inches rain/24hrs ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to MRO on Mon Feb 27 11:00:36 2023
    Re: src/sbbs3/useredit.cpp
    By: MRO to echicken on Mon Feb 27 2023 10:59 am

    having passwords in multiple files in plain text seems insecure.

    Set SCFG->System->Security Options->Display/Log Passwords Locally to "No" and then user passwords should then only ever be stored in *one* file (data/user/user.tab).

    For versions of Synchronet before 3.20, the option location in SCFG and userbase filename (user.dat) are different.
    --
    digital man (rob)

    Breaking Bad quote #15:
    Cheer up Gomey, your people still got J. Lo. - Hank Schrader
    Norco, CA WX: 50.3øF, 70.0% humidity, 0 mph NNE wind, 0.00 inches rain/24hrs ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Lmorchard@VERT/DECAFBAD to deon on Mon Feb 27 20:09:31 2023
    Re: src/sbbs3/useredit.cpp
    By: deon to Digital Man on Mon Feb 27 2023 08:08 pm

    So you said "We'd have to have a way to decrypt an encrypted password".

    My question, is why do you need to decrypt it?

    Random drive-by comment from someone just starting to peek at the codebase: It sounds like there are multiple auth mechanisms. Each uses a different hashing algo which requires the plaintext password as input.

    So, you could reversibly encrypt the password, which doesn't really get you much security since the decryption key would be co-located with the passwords.

    You could calculate all the variant hashes up front on password change - though then you'd need to force a password change if you ever alter what auth mechanisms are supported.

    Sounds like a pain in the butt?

    ---
    þ Synchronet þ 0xDECAFBAD - bbs.decafbad.com
  • From MRO@VERT/BBSESINF to echicken on Mon Feb 27 15:09:00 2023
    Re: src/sbbs3/useredit.cpp
    By: echicken to MRO on Mon Feb 27 2023 06:01 pm


    so you think other comparable softwares do the same thing? I wasn't aware of that. having passwords in multiple files in plain text seems insecure.

    I don't know about comparable, but I've used things that required a different password for some protocol.

    i was thinking about stuff like citadel which is now groupware or a server suite. i thought it had ftp but i'm not sure. I dont think their passwords are in plain text in many data files.

    I had a separate POP3 password in
    gmail, for example. I don't know if this was for a technical reason or if it was like a revokable 'device password'.

    i think it's both. i have those device passwords in my email client for gmail and my old old old yahoo accounts (which i should terminate. thanks for the databreach money, yahoo).

    Depending on what you mean by running the wrong script, there isn't always much to be done to protect sysops from themselves. A JS module could do whatever it wanted to your BBS, and I don't think most sysops realize how much trust is involved there. Some shell script or batch file running as

    i just mean a script that isn't locked down that allows you to type out files. i know when that issue was around years ago there were some measures put in place to stop using ATcodes to type out a file.
    ---
    þ Synchronet þ ::: BBSES.info - free BBS services :::
  • From MRO@VERT/BBSESINF to Digital Man on Mon Feb 27 15:12:55 2023
    Re: src/sbbs3/useredit.cpp
    By: Digital Man to MRO on Mon Feb 27 2023 11:00 am

    Re: src/sbbs3/useredit.cpp
    By: MRO to echicken on Mon Feb 27 2023 10:59 am

    having passwords in multiple files in plain text seems insecure.

    Set SCFG->System->Security Options->Display/Log Passwords Locally to "No" and then user passwords should then only ever be stored in *one* file (data/user/user.tab).


    yeah i didnt even think about the log recording. i was thinking about
    the system pw being in the main.cnf and then the user date file.

    do you mean user.dat instead of user.tab?
    ---
    þ Synchronet þ ::: BBSES.info - free BBS services :::
  • From MRO@VERT/BBSESINF to Lmorchard on Mon Feb 27 15:16:39 2023
    Re: src/sbbs3/useredit.cpp
    By: Lmorchard to deon on Mon Feb 27 2023 08:09 pm


    So, you could reversibly encrypt the password, which doesn't really get you much security since the decryption key would be co-located with the passwords.

    You could calculate all the variant hashes up front on password change - though then you'd need to force a password change if you ever alter what auth mechanisms are supported.

    Sounds like a pain in the butt?

    Yeah, but think of it this way: why do you put a lock on your door?
    Anybody can kick it down.

    It makes it harder. it's a deterrant. it draws attention.
    i've actually got into several bbses using mods that have that exploit i mentioned. I've typed out the system pw and the users pw and taken complete control of a bbs.

    It would be harder for a bonehead like me to go and grab a key and decrypt, yadda yadda yadda when the way i just mentioned takes a few mins.
    ---
    þ Synchronet þ ::: BBSES.info - free BBS services :::
  • From Digital Man@VERT to MRO on Mon Feb 27 13:51:14 2023
    Re: src/sbbs3/useredit.cpp
    By: MRO to Digital Man on Mon Feb 27 2023 03:12 pm

    Re: src/sbbs3/useredit.cpp
    By: Digital Man to MRO on Mon Feb 27 2023 11:00 am

    Re: src/sbbs3/useredit.cpp
    By: MRO to echicken on Mon Feb 27 2023 10:59 am

    having passwords in multiple files in plain text seems insecure.

    Set SCFG->System->Security Options->Display/Log Passwords Locally to "No" and then user passwords should then only ever be stored in *one* file (data/user/user.tab).


    yeah i didnt even think about the log recording. i was thinking about
    the system pw being in the main.cnf and then the user date file.

    <nods>

    do you mean user.dat instead of user.tab?

    No, I meant user.tab: https://synchro.net/docs/newuserbase.txt
    --
    digital man (rob)

    Synchronet "Real Fact" #119:
    Synchronet v2.00a for DOS was released on June 6, 1994 (6 months after v1c02) Norco, CA WX: 48.2øF, 86.0% humidity, 1 mph E wind, 0.00 inches rain/24hrs
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From MRO@VERT/BBSESINF to Digital Man on Mon Feb 27 17:35:06 2023
    Re: src/sbbs3/useredit.cpp
    By: Digital Man to MRO on Mon Feb 27 2023 01:51 pm


    do you mean user.dat instead of user.tab?

    No, I meant user.tab: https://synchro.net/docs/newuserbase.txt

    oh, okay. i have not upgraded yet.
    ---
    þ Synchronet þ ::: BBSES.info - free BBS services :::
  • From Gamgee@VERT/PALANT to MRO on Tue Feb 28 18:12:00 2023
    MRO wrote to Digital Man <=-

    do you mean user.dat instead of user.tab?

    No, I meant user.tab: https://synchro.net/docs/newuserbase.txt

    oh, okay. i have not upgraded yet.

    And apparently don't pay any attention to the message bases, either.

    Strange since you post so much.



    ... As a matter of fact, it IS a banana in my pocket.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Tracker1@VERT/TRN to Digital Man on Sat Mar 4 20:39:26 2023
    Re: src/sbbs3/useredit.cpp
    By: Digital Man to deon on Sun Feb 26 2023 21:32:36

    Why is it needed to decrypt it?

    I'm not sure I understand your question. Why is a key needed to decrypt a password? Because that's how reversable encryption works. <shrug>

    I think the question is regarding any need for reversable encryption... generally passwords are entered and then hashed with a salt in many systems.
    The original password entry is never actually saved, only the salt+hash.

    It looks like Dovecot stores an intermediate step for the hash instead of the unencrypted passphrase. All of that said, probably not much better using reversable encrytion with the key next to the vault.


    --
    Michael J. Ryan
    +o roughneckbbs.com
    tracker1@roughneckbbs.com

    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Tracker1@VERT/TRN to deon on Sat Mar 4 20:41:39 2023
    Re: src/sbbs3/useredit.cpp
    By: deon to Digital Man on Mon Feb 27 2023 15:30:54

    Why is it needed to decrypt it?

    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.


    --
    Michael J. Ryan
    +o roughneckbbs.com
    tracker1@roughneckbbs.com

    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Tracker1@VERT/TRN to MRO on Sat Mar 4 20:46:42 2023
    Re: src/sbbs3/useredit.cpp
    By: MRO to echicken on Mon Feb 27 2023 10:59:02

    So we either resort to the lowest common denominator, or we store the
    encrypted password in many permutations per user, or we require
    different
    passwords for different services.

    so you think other comparable softwares do the same thing? I wasn't aware of that. having passwords in multiple files in plain text seems insecure.

    Some aren't very far from that... some will use multiple intermediate versions of hashed passphrases (email systems in particular)... Others have started to adopt more complex systems for authentication altogether (OAuth2, etc). Passphrase federation is another common approach.

    also how about just encrypting the system password? i'd be happy with that atleast. sure it needs to be decrypted somehow. does that just make it not worth doing? with the wrong script running, someone can get full access. i've done it several times to demonstrate.

    The "system" password could probably be one-way hashed, yes. If that is/was used as a key for other things (like the TLS encryption secret), then it needs to be known at system load. Which is another rabbit hole of more complex systems.

    And even then, this complexity can lead to issues in practice... like 10% of azure hosted SQL server instances losing about 20 hours of data (as a practical example) a few years ago. Because an update to the key rotation broke on a portion of the servers/services.

    In the end, for BBSes, don't use the same password you use anywhere else. And with synchronet supporting longer options, you can just use a passphrase generator for them.


    --
    Michael J. Ryan
    +o roughneckbbs.com
    tracker1@roughneckbbs.com

    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From deon@VERT/ALTERANT 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
  • From Digital Man@VERT 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
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From deon@VERT/ALTERANT 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
  • From Digital Man@VERT 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 ---
    þ 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 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

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows)@VERT 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 setting

    Also, although not a bug (because we re-read/parse the user's record every
    menu 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.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows)@VERT 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.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT 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.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Tue Mar 31 01:23:49 2020
    src/sbbs3 useredit.cpp 1.68 1.69
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv14500

    Modified Files:
    useredit.cpp
    Log Message:
    Cruft removal.


    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Sat May 9 01:21:16 2020
    src/sbbs3 useredit.cpp 1.71 1.72
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv1452

    Modified Files:
    useredit.cpp
    Log Message:
    Clear mouse hotspots when existing the user default config menu.


    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Sun May 10 13:43:59 2020
    src/sbbs3 useredit.cpp 1.72 1.73
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv1878

    Modified Files:
    useredit.cpp
    Log Message:
    Auto-terminal detection (e.g. of ANSI or PETSCII) assumes COLOR support. You need to disable auto-detection to also disable color ANSI/PETSCII.


    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to sbbs/master on Thu Sep 3 18:45:51 2020
    https://gitlab.synchro.net/sbbs/sbbs/-/commit/276a4a5b2409ed199eb333a2
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Allow left/right/home/key keys to navigate users in online "UEDIT"
    - as requested (and insured) by Nelgin

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to sbbs/master on Sun Sep 13 20:07:29 2020
    https://gitlab.synchro.net/sbbs/sbbs/-/commit/53e44f9b6c291691811fde16
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Don't prompt UTF-8 terminal users to ask if they support CP437.

    ---
    ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to sbbs/master on Wed Sep 23 18:42:41 2020
    https://gitlab.synchro.net/sbbs/sbbs/-/commit/98d4f0839217108314a838d5
    Modified Files:
    src/sbbs3/useredit.cpp
    Log Message:
    Allow forward-to-netmail option to be toggled off by user

    Bug introduced in commit a2f5990b4db (Sept-11):
    By calling putuserrec() before modifying user->misc and then calling
    noyes(), we're giving an opportunity for the low-level node sync code to
    read the modified "useron" back from the database, thus losing the change
    we just made to user->misc. Instead, move the putuserrec() call to the end
    of the case statement. Another option would have been to turn off the NETMAIL flag before the first call to putuserrec().

    Bug reported by Nugax (BYTEXCHG)

    ---
    ï¿­ 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 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

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT 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).

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