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