1. Forum
  2. fsxNet
  3. FSX BBS

  • Re: RFC - BBS WEB AUTH

    From crax@21:1/188 to 3SHINOBI on Wed May 23 16:34:12 2018
    Quoting Shinobi to Nuskooler <=-

    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.

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

    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.

    Yep.

    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.

    Shared secrets aren't meant to be transmitted.

    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

    crax
    ___ Blue Wave/386 v2.30

    --- Mystic BBS/QWK v1.12 A39 2018/04/21 (Raspberry Pi/32)
    * Origin: ACiD Underworld // blackflag.acid.org:31337 (21:1/188)
  • From shinobi@21:1/153 to crax on Wed May 23 21:55:44 2018
    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)