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

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

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

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

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

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

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 :::

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

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 :::

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

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 :::

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

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

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

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

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 :::

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

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

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

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

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 :::

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 :::

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 :::

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

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 :::

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

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

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

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

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

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

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

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

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

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

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

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