Awesome - thanks, implemented.

--
Posted on Rocksolid Light

This one might be useful for RSL, but it will require a bit of adaptation to make use of the flatfile user database. It's a password reset page for users who've forgotten their passwords. It generates a random token, e-mails a link with the token to the user using phpmailer, validates the token against the user database, and lets the user change their password. I also added a 24 hour token expiry.

https://bitbucket.org/svga256/tomobbs/commits/5729fb4a6f916a47a814123fefd9ea19a891463d

One question - Is it safe to send passwords for validation in forms via $_POST without first being hashed? This is an area of php that I don't have a ton of experience with, so I just followed the exemplar code in register.php.

--
Posted on Rocksolid Light

vga256 wrote:

> This one might be useful for RSL, but it will require a bit of adaptation to make use of the flatfile user database. It's a password reset page for users who've forgotten their passwords. It generates a random token, e-mails a link with the token to the user using phpmailer, validates the token against the user database, and lets the user change their password. I also added a 24 hour token expiry.

> https://bitbucket.org/svga256/tomobbs/commits/5729fb4a6f916a47a814123fefd9ea19a891463d

Looks good!

> One question - Is it safe to send passwords for validation in forms via $_POST without first being hashed? This is an area of php that I don't have a ton of experience with, so I just followed the exemplar code in register.php.

You're kind of relying on SSL during that time. To hash it first would require client side scripting, which would make this feature unavailable if JS is disabled. It is best to choose $_POST as you are. Avoid $_GET for such things and receive as $_POST, (not $_REQUEST which allows someone to generate a $_GET and have it received and processed.

I took a look at the code. I do plan to add this feature to RSL at some point.

I notice that you are retrieving $keys, which is good. Not sure if the purpose of $keys is obvious, but it is meant to limit a request to a time period. Meaning, if you try the same request in the future (or someone get a hold of your request), it won't work after a certain time, as $keys are rotated at the server. So a request including $keys would not match after a certain period of time. Just thought I'd mention all that in case it isn't clear in the code why it is there.

BTW, I don't claim to know what I'm talking about, I'm a hobbyist programmer. If someone has better advice, please chime in :)

--
Retro Guy

> You're kind of relying on SSL during that time. To hash it first would require client side scripting, which would make this feature unavailable if JS is disabled. It is best to choose $_POST as you are. Avoid $_GET for such things and receive as $_POST, (not $_REQUEST which allows someone to generate a $_GET and have it received and processed.

Ah haaa... now that's interesting. I suspected that SSL was doing the heavy lifting, but that also helps me understand the risks for anyone communicating via non-https. I did not know there was a distinction between POST and GET security-wise! (I just POST everything out of habit)

> I took a look at the code. I do plan to add this feature to RSL at some point.

> I notice that you are retrieving $keys, which is good. Not sure if the purpose of $keys is obvious, but it is meant to limit a request to a time period. Meaning, if you try the same request in the future (or someone get a hold of your request), it won't work after a certain time, as $keys are rotated at the server. So a request including $keys would not match after a certain period of time. Just thought I'd mention all that in case it isn't clear in the code why it is there.

Ah haa.. thanks for the explanation. I left $keys in register.php because I didn't know what it was doing at the time. I guess my token generation will do the same job, but it's great to know that function has already been taken care of.

--
Posted on Rocksolid Light

On Wed, 2 Aug 2023 15:00:48 +0000
retro.guy@rocksolidbbs.com (Retro Guy) wrote:

> vga256 wrote:
>
> > This one might be useful for RSL, but it will require a bit of
> > adaptation to make use of the flatfile user database. It's a
> > password reset page for users who've forgotten their passwords. It
> > generates a random token, e-mails a link with the token to the user
> > using phpmailer, validates the token against the user database, and
> > lets the user change their password. I also added a 24 hour token
> > expiry.
>
> > https://bitbucket.org/svga256/tomobbs/commits/5729fb4a6f916a47a814123fefd9ea19a891463d
> >
>
> Looks good!
>
> > One question - Is it safe to send passwords for validation in forms
> > via $_POST without first being hashed? This is an area of php that
> > I don't have a ton of experience with, so I just followed the
> > exemplar code in register.php.
>
> You're kind of relying on SSL during that time. To hash it first
> would require client side scripting, which would make this feature
> unavailable if JS is disabled. It is best to choose $_POST as you
> are. Avoid $_GET for such things and receive as $_POST, (not
> $_REQUEST which allows someone to generate a $_GET and have it
> received and processed.
>
> I took a look at the code. I do plan to add this feature to RSL at
> some point.
>
> I notice that you are retrieving $keys, which is good. Not sure if
> the purpose of $keys is obvious, but it is meant to limit a request
> to a time period. Meaning, if you try the same request in the future
> (or someone get a hold of your request), it won't work after a
> certain time, as $keys are rotated at the server. So a request
> including $keys would not match after a certain period of time. Just
> thought I'd mention all that in case it isn't clear in the code why
> it is there.
>
> BTW, I don't claim to know what I'm talking about, I'm a hobbyist
> programmer. If someone has better advice, please chime in :)

You must ensure that the server will not permit a TLS/SSL protocol
downgrade attack. You must be certain that the server configuration will
never permit this to happen if sending unhashed or un-nonced passwords
through a encrypted connection. The server must refuse to handshake if
the client is not properly negotiating TLS/SSL.

A protocol downgrade attack is where a server will downgrade to an
earlier, weaker form of TLS/SSL or to HTTP in the clear when the
browser is not able to properly negotiate an encrypted connection. A
MITM can perform this attack and force a bad browser or bad server to
downgrade the connection cipher protocol and get the plaintext.

If there is going to be any javascript at all in the web front end,
this is where you would want it--for hashing passwords and nonces
together. And when hashing authentication data, do not use md5 or sha1.
Use sha256, sha384, sha512, b2sum, and other newer, longer hashes. If
you go the hashed password route, always program the client javascript
to do it with a random nonce provided by the server.

At a minimum the server must be configured to force HSTS (or a custom
equivalent) in https connections. It is also vital to use a PHP header
in the application to check that HSTS is enforced and that the server
values for the SSL connection show that SSL is active, and to fail by
refusing to proceed if HSTS is not engaged by either client or server.

If you don't programmatically force both client and browser to enforce
HSTS and prevent any possibility of downgrade attack, then getting pwnd
is just a matter of time.

Since we are dealing with retro enthusiasts, retro networks, and piles
of retro software, this issue is actually really important. Older
unpatched server software, browsers, and clients could be susceptible
to protocol downgrade attacks.

This is why I like the use of GPG for passing private messages
between servers. There is no way to downgrade that. It either works or
it fails without risk of exposing plaintext.

--
SugarBug | https://sybershock.com

Syber Shock wrote:

> You must ensure that the server will not permit a TLS/SSL protocol
> downgrade attack. You must be certain that the server configuration will
> never permit this to happen if sending unhashed or un-nonced passwords
> through a encrypted connection. The server must refuse to handshake if
> the client is not properly negotiating TLS/SSL.

> A protocol downgrade attack is where a server will downgrade to an
> earlier, weaker form of TLS/SSL or to HTTP in the clear when the
> browser is not able to properly negotiate an encrypted connection. A
> MITM can perform this attack and force a bad browser or bad server to
> downgrade the connection cipher protocol and get the plaintext.

This is good advice. I already force https using the web server (nginx
in my case). But forcing it also using HSTS (as you mention below) is a
good idea.

> If there is going to be any javascript at all in the web front end,
> this is where you would want it--for hashing passwords and nonces
> together. And when hashing authentication data, do not use md5 or sha1.
> Use sha256, sha384, sha512, b2sum, and other newer, longer hashes. If
> you go the hashed password route, always program the client javascript
> to do it with a random nonce provided by the server.

We could do this with JS, but there must be a fallback to allow log in
with JS disabled. Other features that silently fail without JS are not
very important, but logging in would be a pretty obvious fail.

> At a minimum the server must be configured to force HSTS (or a custom
> equivalent) in https connections. It is also vital to use a PHP header
> in the application to check that HSTS is enforced and that the server
> values for the SSL connection show that SSL is active, and to fail by
> refusing to proceed if HSTS is not engaged by either client or server.

> If you don't programmatically force both client and browser to enforce
> HSTS and prevent any possibility of downgrade attack, then getting pwnd
> is just a matter of time.

Adding HSTS to the code is easy. I'll mess around with it today.

> Since we are dealing with retro enthusiasts, retro networks, and piles
> of retro software, this issue is actually really important. Older
> unpatched server software, browsers, and clients could be susceptible
> to protocol downgrade attacks.

> This is why I like the use of GPG for passing private messages
> between servers. There is no way to downgrade that. It either works or
> it fails without risk of exposing plaintext.

Yup. I agree it's the better way to do messaging, and that's what we're
doing :)

--
Retro Guy

> One question - Is it safe to send passwords for validation in forms via $_POST without first being hashed? This is an area of php that I don't have a ton of experience with, so I just followed the exemplar code in register.php.

anon replying here, because I find that discussion interesting:

1) to my knowledge, neither GET nor POST are safe by themselves, since an attacker eavesdropping can extract all information contained, whichever method is used. GET is just slightly worse, because on top it presents all info in the form of an url, which might get stored (without intention) in all kinds of places.

2) an attacker that can read a password from the POST stream can also read a hash. So I fail to see any difference in sending a password vs sending a hash (which is then used serverside as a password again).

3) in my opinion, the safety of any communication between browser and server relies on the underlying protocols used. https was already mentioned in this thread, together with its limitations and challenges. Using tor or i2p gets rid of those headaches altogether (but that is just me talking, using tor at every possible corner).

--
Posted on RetroBBS

Anonymous wrote:

>> One question - Is it safe to send passwords for validation in forms via $_POST without first being hashed? This is an area of php that I don't have a ton of experience with, so I just followed the exemplar code in register.php.

> anon replying here, because I find that discussion interesting:

> 1) to my knowledge, neither GET nor POST are safe by themselves, since an attacker eavesdropping can extract all information contained, whichever method is used. GET is just slightly worse, because on top it presents all info in the form of an url, which might get stored (without intention) in all kinds of places.

The only real benefit to POST over GET is that you avoid the risk of giving someone a link that has the data visible in it. It's harder to spoof POST, but of course it can be done. You just reduce the risk, but you don't avoid all risk.

> 2) an attacker that can read a password from the POST stream can also read a hash. So I fail to see any difference in sending a password vs sending a hash (which is then used serverside as a password again).

> 3) in my opinion, the safety of any communication between browser and server relies on the underlying protocols used. https was already mentioned in this thread, together with its limitations and challenges. Using tor or i2p gets rid of those headaches altogether (but that is just me talking, using tor at every possible corner).

With the software we're discussing, RSL and tomo, I believe that SSL is sufficient. Enforcing SSL is a good idea, and it's pretty simple.

There are good reasons to limit access to some sites to only tor or i2p, but it's overkill for this task, and it severely limits the amount of people who would ever become a user of such sites.

The goal here is reasonable security. If someone is planning to overthrow the planet, just SSL won't be good enough.

--
Retro Guy

tiny patch for newsportal.php:

If the connection to the remote server fails during a message send, prevent a script execution crash in newsportal.php:
line ~128:

if (is_resource($ns))
fclose($ns);

(when it cannot connect, $ns is passed as false, which cannot be fclosed)

--
Posted on Rocksolid Light

vga256 wrote:

> tiny patch for newsportal.php:

> If the connection to the remote server fails during a message send, prevent a script execution crash in newsportal.php:
> line ~128:

> if (is_resource($ns))
> fclose($ns);

> (when it cannot connect, $ns is passed as false, which cannot be fclosed)

Thanks! I'll apply that soon.

--
Retro Guy

There's a typo in spoolnews.php (for Mail). I fixed it, here is the relevant part of the file, just one line changed (bbbs to bbs):

@@ -150,7 +150,7 @@ function get_articles($ns, $group) {

$nocem_check="@@NCM";
- $bbbsmail_check="@@RSL";
+ $bbsmail_check="@@RSL";

--
Retro Guy

New commit to rslight-lib.php. If they don't display well here, I'll send a better description:

nntp treats commands as case insensitive, but overlooked was LIST NEWSGROUPS. This fixes it (starting at line 58):

if ($command[0] == 'list') {
if(isset($command[1])) {
- $msg = get_list($command[1], $msgsock);
+ $msg = get_list(strtolower($command[1]), $msgsock);
} else {
$msg = get_list("active", $msgsock);
}

Starting at line 1044 is an old bug, which is now fixed:

if(trim($name[1]) !== "") {
$msg.=$findgroup."rn";
} elseif(file_exists($spooldir."/".$name[0]."-title")) {
- $msg.=file_get_contents($spooldir."/".$name[0]."-title", IGNORE_NEW_LINES);
+ $msg.=file_get_contents($spooldir."/".$name[0]."-title")."rn";
} else {
$msg.=$findgroup."rn";
}

--
Retro Guy

Here is a list of recent changes:

Add interBBS Mail feature. (mostly complete and working)

Limit browser caching headers to only overboard and search results.

Discontinue use of overview flat files. Overview is now handled
only in the sqlite .db3 overview file (which already existed, but
needs upgrading at 0.9.0). Modified INSTALL.md to show steps to
upgrade properly.

Add history.db3 to handle deleted (NoCeM or expired) articles to
keep the article number reserved, and keep a record of deleted
message-ids. This greatly improves external newsreader support.

Fix a few bugs discovered along the way.

Clean up indentation on most .php files.

--
Retro Guy