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

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

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