This fixes issue #442
When passwords aren't displayed (due to sysop configuration), show
Re: src/sbbs3/useredit.cpp
By: Rob Swindell (on ChromeOS) to Git commit to main/sbbs/master on Sat Feb 25 2023 11:13 pm
This fixes issue #442
When passwords aren't displayed (due to sysop configuration), show
do you have plans to encrypt the user passwords and system passwords in the data files?
When passwords aren't displayed (due to sysop configuration), show
do you have plans to encrypt the user passwords and system passwords in the data files?
No immediate plans, no.
Re: src/sbbs3/useredit.cpp
By: Digital Man to MRO on Sun Feb 26 2023 12:30 pm
When passwords aren't displayed (due to sysop configuration), show
do you have plans to encrypt the user passwords and system passwords in the data files?
No immediate plans, no.
what the helllll.
why is that not being considered?
Synchronet supports many methods of secure authentication (e.g. CRAM-MD5) which means we do practically need the original user password in plan text 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?
What's the point of encrypting the passwords in the user.tab file if all a prying-eye needs is another file from the same directory tree to use as the key to decrypt them?
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?
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?
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?
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.
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.
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.
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.
having passwords in multiple files in plain text seems insecure.
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?
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.
I don't know about comparable, but I've used things that required a different password for some protocol.
I had a separate POP3 password in
gmail, for example. I don't know if this was for a technical reason or if it was like a revokable 'device password'.
Depending on what you mean by running the wrong script, there isn't always much to be done to protect sysops from themselves. A JS module could do whatever it wanted to your BBS, and I don't think most sysops realize how much trust is involved there. Some shell script or batch file running as
Re: src/sbbs3/useredit.cpp
By: MRO to echicken on Mon Feb 27 2023 10:59 am
having passwords in multiple files in plain text seems insecure.
Set SCFG->System->Security Options->Display/Log Passwords Locally to "No" and then user passwords should then only ever be stored in *one* file (data/user/user.tab).
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?
Re: src/sbbs3/useredit.cpp
By: Digital Man to MRO on Mon Feb 27 2023 11:00 am
Re: src/sbbs3/useredit.cpp
By: MRO to echicken on Mon Feb 27 2023 10:59 am
having passwords in multiple files in plain text seems insecure.
Set SCFG->System->Security Options->Display/Log Passwords Locally to "No" and then user passwords should then only ever be stored in *one* file (data/user/user.tab).
yeah i didnt even think about the log recording. i was thinking about
the system pw being in the main.cnf and then the user date file.
do you mean user.dat instead of user.tab?
do you mean user.dat instead of user.tab?
No, I meant user.tab: https://synchro.net/docs/newuserbase.txt
MRO wrote to Digital Man <=-
do you mean user.dat instead of user.tab?
No, I meant user.tab: https://synchro.net/docs/newuserbase.txt
oh, okay. i have not upgraded yet.
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>
Why is it needed to decrypt it?
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.
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.
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.
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...
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".
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.
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"?
| Sysop: | Thearcadeguy |
|---|---|
| Location: | Stuart, Florida |
| Users: | 5 |
| Nodes: | 12 (0 / 12) |
| Uptime: | 70:54:02 |
| Calls: | 105 |
| Files: | 25 |
| Messages: | 15,377 |