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
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

https://gitlab.synchro.net/main/sbbs/-/commit/e71c279c5f4f0eaf0310bdf8
Modified Files:
src/sbbs3/useredit.cpp
Log Message:
Elminate meaningless typecast
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)