Subj : src/sbbs3/useredit.cpp
To   : deon
From : Digital Man
Date : Sat Mar 04 2023 08:24 pm

  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

.