Subj : src/sbbs3/useredit.cpp
To   : MRO
From : Tracker1
Date : Sat Mar 04 2023 08:46 pm

  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.

 MR> so you think other comparable softwares do the same thing? I wasn't aware
 MR> 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.

 MR> also how about just encrypting the system password? i'd be happy with that
 MR> atleast. sure it needs to be decrypted somehow. does that just make it not
 MR> worth doing? with the wrong script running, someone can get full access.
 MR> 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

.