Hello All,

I'm attaching short document I wrote regarding the BBS WEB AUTH process.

I'd be glad just for any comments

Best regards

Shinobi

ATTACHMENT: BBS WEB AUTHENTICATION PROPOSAL

-- CUT HERE --

-------------------------------------------------------
BBS WEB AUTHENTICATION PROPOSAL - REQUEST FOR COMMENT -------------------------------------------------------

* AUTHENTICATION ELEMENTS *

The connection between BBS and Web server is designed as follows:

1) Server
- The server is written in Python Flask.
- The server handles POST and GET requests.
- The server provides classic html Forms.
- The server provides classic html Tables.

2) Client
- The client is dumbed elinks browser.
- it consists of disabling all the user
functions like saving, going to custom
url, opening files from disc etc.
- The client is trusted by the BBS.

3) BBS
- The BBS provides standard inbound listening.
- It provides capability to run external program.
- It can provide the external program current user's username.

4) Shared secret
- Both the BBS and the Server stores shared secret.
- The shared secret is used to authenticate the BBS towards Server.
- Once the Shared secret handshake is successful the BBS is trusted
and it can provides username of current user running the doors.

* AUTHENTICATION *

** DATA STRUCTURES **

- BBS_KEY - string 64 chars long (random characters)
- BBS_SECRET - string 64 chars long (random characters)

** AUTHENTICATION PROCESS **

- The server has BBS_KEY and BBS_SECRET stored in it.
- The BBS runs shell script providing it current user username.
- The shell script prepares intermediate html file.
- The html file is unique for each BBS Door session.
- The html file contains form with BBS_KEY, BBS_SECRET and username.
- When the user is dropped into dumbed elinks the html file is displayed.
- In case he wants to authenticate towards the web-server it's enough
just to press button (in text-mode) and submit POST request to the
server.
- Once the form is submitted the user authenticates towards the web
server as logged user from BBS.

-- CUT HERE --

--- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: INFOLINKA BBS (21:1/153)

ATTACHMENT: BBS WEB AUTHENTICATION PROPOSAL

I'm having a hard time understanding what this is attempting to solve? Is the goal to authenticate against a BBS user (user/pass) from a website?

On Sunday, May 20th shinobi muttered...

The html file contains form with BBS_KEY, BBS_SECRET and
username. - When the user is dropped into dumbed elinks the html file is

This just exposed the key and secret.

If it's what I *think* you're attempting (Q: above), then you need a non-unique
HTML form that *only* collects username/password for a BBS user. The form submits to a *server* side component. The server side can then authenticate against the BBS. No real need for any secret/key/etc. as the server side component is implicitly trusted (it's on your server). If you want to allow 3rd
parties to do this, all of the proceeding applies, but you can introduce the trust measure. Something like auth=public_key:HMAC_SHA256(secret, {creds})

This allows a crypto-secure token to be generated and sent in to the auth provider (your server that talks to the BBS) and includes a ID (public_key) unique for the creds. Of course in this case you also need the plain-text creds
for the BBS, so the final payload could be e.g.: auth={user:$USER,pass:$PASS,key:$KEY,token:$HMAC}





--- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 8.9.4)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)

I'm having a hard time understanding what this is attempting to solve?
Is the goal to authenticate against a BBS user (user/pass) from a
website?

Sorry about not being clear. The goal is to authenticate user against web server. That means. When You logon to BBS. And then select from menu Doors. Then You should be dropped into text browser. And this browser has to authenticate against web server. And there shouldn't be the need to logon
once more to the web server.

The reason of this approach is to be able to access web pages in text-mode
from BBS against custom Web server.

The html file contains form with BBS_KEY, BBS_SECRET and
username. - When the user is dropped into dumbed elinks the html file

This just exposed the key and secret.

This is to be done on the BBS side. The user won't have access to the form. That means. From user's point of view. You logon to BBS. Select application. That application runs custom elinks. And forward You to web pages with the username and shared secret.

However the user doesn't see neither content of the form (it's disabled in
the custom elinks) and doesn't see the file on the BBS machine filesystem.

If it's what I *think* you're attempting (Q: above), then you need a non-unique HTML form that *only* collects username/password for a BBS user. The form submits to a *server* side component. The server side can

If I guess that right You talking about the other way. That means from web to BBS. I'm talking about auth from BBS to web. Is that correct?

Thanks for the comment. I'm very glad about it. Your feedback is appreciated.

Best regards

Shinobi

--- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: INFOLINKA BBS (21:1/153)

To the second part...

This allows a crypto-secure token to be generated and sent in to the auth provider (your server that talks to the BBS) and includes a ID (public_key) unique for the creds. Of course in this case you also need the plain-text creds for the BBS, so the final payload could be e.g.: auth={user:$USER,pass:$PASS,key:$KEY,token:$HMAC}

Except we are both talking each about another direction. You've got the point And that's in the sending the secret across the http. That's of course a huge design flaw. When I would like to exchange token between parties... it must
be hashed. Not to spoil the token to the transport layer. Very good. Thanks very much.

Best regards

Shinobi

--- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: INFOLINKA BBS (21:1/153)

What's running on the web server that requires the identity of the BBS user?

Well... it can be just anything. For now my application is just simple. Two search prompt to find food product by both code or name. Then possibility to edit the food database data. And possibility to update food log data.
When user is editing we want him to save his credentials so we can refer to
the person who did the change. And when the user saves the food he has eaten
we want to display him only his intake.

This just exposed the key and secret.

Yep.

That's what I came up with. It's just better to save use the secret together with username, possibly i.p. address or line from which the user is
accessing. And his name and password possibly. Whatever... just to get the
hash to prepare the token. I guess the md5 is quite obsolete. So possibly something newer.

Shared secrets aren't meant to be transmitted.

Well... that's what NuSkooler told me. And I totally agreed with him.

If the server just needs to identify the BBS as known in order to trust the user name, a unique key for each BBS it talks to is sufficient (assuming the server verifies the BBS key is valid). That's a basic form of authentication. There are a few problems

That's why I submitted the draft alpha prep phase of document. I'm glad for Your comments.

Best regards

Shinobi

--- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: INFOLINKA BBS (21:1/153)