• ENiGMA 1/2 Waiting For Caller feature

    From NuSkooler@21:1/121 to All on Wednesday, February 20, 2019 19:38:05
    ENiGMA 1/2 "WFC" Request for Comments --

    I did a small poll regarding the next major ENiGMA 1/2 feature - WFC or FSE & engine re-write. WFC seems to be in the lead. With that in mind, I'd love to hear comments / suggestions on the current feature set plan as well as feedback
    on the security aspects:

    Traditional WFC Features:
    * A terminal driven WFC (dashboard) that can be viewed by +ops
    * Display of basic statistics
    * Active connections/nodes
    * Last _N_ logins/calls
    * Quick login of authenticated user -> menu supplied, e.g. `mainMenu`
    * Send and receive node messages with online node(s)
    * Ability to break into chat with an online user
    * Some basic management
    * View logs

    Modern Features:
    * Remote access over secure channels only (Secure WebSocket or SSH)
    * WFC will be `menu.hjson` and `theme.hjson` backed like all other components
    * View and execute Scheduled Tasks

    Missing Features:
    * Node Spy feels wrong in the modern era, so I have no plans for this, sorry!

    To have highly secure remote access, the ideal methods are as folows:
    * SSH via Public Key Authentication (PubKey): This method would require a public SSH key to be installed on the system. Clients (* see notes) would utilize their private keys to communicate.
    * Secure WebSockets (WebSockets over TLS, wss://) with Client Authentication (ClientAuth): This method would require the public key portion of a TLS certificate to be installed on the system. Clients (web browsers) would sign & send with their private key.
    * Secure WebSockets with TLS termination: Similar to the Secure WebSockets method but allows the functionality to work behind TLS-terminating load balancers & reverse proxies (For example, Xibalba runs behind Caddy web server)
    using a appended fingerprint header (commonly, `X-SSL-Client-SHA1`).

    The above are highly secure, but have some possible issues:
    I do not know of any ANSI-BBS terminals that support public key authentication.
    Currently SyncTERM, NetRunner, and MagiTerm all use username/password only AFAIK. I'd love to see this functionality added in *general* since I'd like to add public key auth to the system for regular users as well.

    Less ideal solution:
    Require "alias" WFC-only logins (example: "!NuSkoolerWFC") that have system-assigned passwords. These would be long PRNG with high entropy. Less secure, and terminals might have password limitations that restrict this.

    OK, that was long! I'd really love to hear feedback about the features in general, and the security issues!


    --- ENiGMA 1/2 v0.0.10-alpha (linux; x64; 10.13.0)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From NuSkooler@21:1/121 to NuSkooler on Saturday, February 23, 2019 14:37:03
    As a follow up, here are some of the current working changes to the RFC:
    * Allowed via any connection considered "secure". How secure you want it is determined by the 'SC' ACS: SC1=SSL/TLS, SC2=2FA, SC3=SSL/TLS+2FA
    * Public Key Auth and TLS Client Auth will be options on a per-user basis (ie: if they are enabled and required for login)

    The default ACS for WFC would probably look something like this: "SC3ID1GM[wfc]" - meaning:
    * SC3: SSL or TLS + 2FA
    * ID1: User ID 1 (aka root/initial op)
    * GM[wfc]: Group membership of 'wfc'

    Of course, ops can change this to allow other users, groups, so on.

    2-factor Authentication (2FA) in this case would be One Time Password (OTP) based using one of:
    * Time-Based One-Time Password (TOTP, RFC-6238)
    * HMAC-Based One Time Password (HOTP, RFC-4266)

    If these sound weird, this basically means after first factor auth (u/n +
    pass or pub key), if enabled, the user would be prompted for a OTP. This would work with things like Google Auth and many others.

    Request For Comments! :)

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