mirror of
https://github.com/NuSkooler/enigma-bbs.git
synced 2025-07-31 06:56:12 +02:00
Sync up with 0.0.10-alpha
This commit is contained in:
commit
0bfeca090d
97 changed files with 4568 additions and 786 deletions
|
@ -37,8 +37,8 @@ The following are ACS codes available as of this writing:
|
|||
| MM<i>minutes</i> | It is currently >= _minutes_ past midnight (system time) |
|
||||
| AC<i>achievementCount</i> | User has >= _achievementCount_ achievements |
|
||||
| AP<i>achievementPoints</i> | User has >= _achievementPoints_ achievement points |
|
||||
|
||||
\* Many more ACS codes are planned for the near future.
|
||||
| AF<i>authFactor</i> | User's current *Authentication Factor* is >= _authFactor_. Authentication factor 1 refers to username + password (or PubKey) while factor 2 refers to 2FA such as One-Time-Password authentication. |
|
||||
| AR<i>authFactorReq</i> | Current user **requires** an Authentication Factor >= _authFactorReq_ |
|
||||
|
||||
## ACS Strings
|
||||
ACS strings are one or more ACS codes in addition to some basic language semantics.
|
||||
|
|
|
@ -11,9 +11,15 @@ Archivers are manged via the `archives:archivers` configuration block of `config
|
|||
The following archivers are pre-configured in ENiGMA½ as of this writing. Remember that you can override settings or add new handlers!
|
||||
|
||||
#### ZZip
|
||||
* Formats: .7z, .bzip2, .zip, .gzip/.gz, and more
|
||||
* Formats: .7z, .bzip2, .gzip/.gz, and more
|
||||
* Key: `7Zip`
|
||||
* Homepage/package: [7-zip.org](http://www.7-zip.org/). Generally obtained from a `p7zip` package in UNIX-like environments. See http://p7zip.sourceforge.net/ for details.
|
||||
* Notes: Versions previous to 0.0.10-alpha defaulted to using 7zip for .zip files as well, but newer versions of the package give "volume" errors at times. See InfoZip below.
|
||||
|
||||
#### InfoZip
|
||||
* Formats: .zip
|
||||
* Key: InfoZip
|
||||
* Homepage/package: http://infozip.sourceforge.net/. Often already available in Linux. You will need `zip` and `unzip` in ENiGMA's path.
|
||||
|
||||
#### Lha
|
||||
* Formats: <a href="https://en.wikipedia.org/wiki/LHA_(file_format)">LHA</a> files such as .lzh.
|
||||
|
|
|
@ -74,6 +74,23 @@ Submit actions are declared using the `action` member of a submit handler block.
|
|||
| `@method:methodName` | Executes *methodName* local to the calling module. That is, the module set by the `module` member of a menu entry. |
|
||||
| `@method:/path/to/some_module.js:methodName` | Executes *methodName* exported by the module at */path/to/some_module.js*. |
|
||||
|
||||
#### Advanced Action Handling
|
||||
In addition to simple simple actions, `action` may also be:
|
||||
* An array of objects containing ACS checks and a sub `action` if that ACS is matched. See **Action Matches** in the ACS documentation below for details.
|
||||
* An array of actions. In this case a random selection will be made. Example:
|
||||
```hjson
|
||||
submit: [
|
||||
{
|
||||
value: { command: "FOO" }
|
||||
action: [
|
||||
// one of the following actions will be matched:
|
||||
"@menu:menuStyle1"
|
||||
"@menu:menuStyle2"
|
||||
]
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
#### Method Signature
|
||||
Methods executed using `@method`, or `@systemMethod` have the following signature:
|
||||
```
|
||||
|
@ -86,6 +103,7 @@ Many built in global/system methods exist. Below are a few. See [system_menu_met
|
|||
| Method | Description |
|
||||
|--------|-------------|
|
||||
| `login` | Performs a standard login. |
|
||||
| `login2FA_OTP` | Performs a 2-Factor Authentication (2FA) One-Time Password (OTP) check, if configured for the user. |
|
||||
| `logoff` | Performs a standard system logoff. |
|
||||
| `prevMenu` | Goes to the previous menu. |
|
||||
| `nextMenu` | Goes to the next menu (as set by `next`) |
|
||||
|
@ -179,6 +197,23 @@ opOnlyMenu: {
|
|||
}
|
||||
```
|
||||
|
||||
### Action Matches
|
||||
Action blocks (`action`) can perform ACS checks:
|
||||
```
|
||||
// ...
|
||||
{
|
||||
action: [
|
||||
{
|
||||
acs: SC1
|
||||
action: @menu:secureMenu
|
||||
}
|
||||
{
|
||||
action: @menu:nonSecureMenu
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Flow Control
|
||||
The `next` member of a menu may be an array of objects containing an `acs` check as well as the destination. Depending on the current user's ACS, the system will pick the appropriate target. The last element in an array without an `acs` can be used as a catch all. Example:
|
||||
```
|
||||
|
|
64
docs/configuration/security.md
Normal file
64
docs/configuration/security.md
Normal file
|
@ -0,0 +1,64 @@
|
|||
---
|
||||
layout: page
|
||||
title: Security
|
||||
---
|
||||
## Security
|
||||
Unlike in the golden era of BBSing, modern Internet-connected systems are prone to hacking attempts, eavesdropping, etc. While plain-text passwords, insecure data over [Plain Old Telephone Service (POTS)](https://en.wikipedia.org/wiki/Plain_old_telephone_service), and so on was good enough then, modern systems must employ protections against attacks. ENiGMA½ comes with many security features that help keep the system and your users secure — not limited to:
|
||||
* Passwords are **never** stored in plain-text, but instead are stored using [Password-Based Key Derivation Function 2 (PBKDF2)](https://en.wikipedia.org/wiki/PBKDF2). Even the system operator can _never_ know your password!
|
||||
* Alternatives to insecure Telnet logins are built in: [SSH](https://en.wikipedia.org/wiki/Secure_Shell) and secure [WebSockets](https://en.wikipedia.org/wiki/WebSocket) for example.
|
||||
* A built in web server with [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) support (aka HTTPS).
|
||||
* Optional [Two-Factor Authentication (2FA)](https://en.wikipedia.org/wiki/Multi-factor_authentication) via [One-Time-Password (OTP)](https://en.wikipedia.org/wiki/One-time_password) for users, supporting [Google Authenticator](http://google-authenticator.com/), [Time-Based One-Time Password Algorithm (TOTP, RFC-6238)](https://tools.ietf.org/html/rfc6238), and [HMAC-Based One-Time Password Algorithm (HOTP, RFC-4266)](https://tools.ietf.org/html/rfc4226).
|
||||
|
||||
## Two-Factor Authentication via One-Time Password
|
||||
Enabling Two-Factor Authentication via One-Time-Password (2FA/OTP) on an account adds an extra layer of security ("_something a user has_") in addition to their password ("_something a user knows_"). Providing 2FA/OTP to your users has some prerequisites:
|
||||
* [A configured email gateway](/docs/configuration/email.md) such that the system can send out emails.
|
||||
* One or more secure servers enabled such as [SSH](/docs/servers/ssh.md) or secure [WebSockets](/docs/servers/websocket.md) (that is, WebSockets over a secure connection such as TLS).
|
||||
* The [web server](/docs/servers/web-server.md) enabled and exposed over TLS (HTTPS).
|
||||
|
||||
:information_source: For WebSockets and the web server, ENiGMA½ _may_ listen on insecure channels if behind a secure web proxy.
|
||||
|
||||
### User Registration Flow
|
||||
Due to the nature of 2FA/OTP, even if enabled on your system, users must opt-in and enable this feature on their account. Users must also have a valid email address such that a registration link can be sent to them. To opt-in, users must enable the option, which will cause the system to email them a registration link. Following the link provides the following:
|
||||
|
||||
1. A secret for manual entry into a OTP device.
|
||||
2. If applicable, a scannable QR code for easy device entry (e.g. Google Authenticator)
|
||||
3. A confirmation prompt in which the user must enter a OTP code. If entered correctly, this validates everything is set up properly and 2FA/OTP will be enabled for the account. Backup codes will also be provided at this time. Future logins will now prompt the user for their OTP after they enter their standard password.
|
||||
|
||||
:warning: Serving 2FA/OTP registration links over insecure (HTTP) can expose secrets intended for the user and is **highly** discouraged!
|
||||
|
||||
:information_source: +ops can also manually enable or disable 2FA/OTP for a user using [oputil](/docs/admin/oputil.md), but this is generally discouraged.
|
||||
|
||||
#### Recovery
|
||||
In the situation that a user loses their 2FA/OTP device (such as a lost phone with Google Auth), there are some options:
|
||||
* Utilize one of their backup codes.
|
||||
* Contact the SysOp.
|
||||
|
||||
:warning: There is no way for a user to disable 2FA/OTP without first fully logging in! This is by design as a security measure.
|
||||
|
||||
### ACS Checks
|
||||
Various places throughout the system that implement [ACS](/docs/configuration/acs.md) can make 2FA specific checks:
|
||||
* `AR#`: Current users **required** authentication factor. `AR2` for example means 2FA/OTP is required for this user.
|
||||
* `AF#`: Current users **active** authentication factor. `AF2` means the user is authenticated with some sort of 2FA (such as One-Time-Password).
|
||||
|
||||
See [ACS](/docs/configuration/acs.md) for more information.
|
||||
|
||||
#### Example
|
||||
The following example illustrates using an `AR` ACS check to require applicable users to go through an additional 2FA/OTP process during login:
|
||||
|
||||
```hjson
|
||||
login: {
|
||||
art: USERLOG
|
||||
next: [
|
||||
{
|
||||
// users with AR2+ must first pass 2FA/OTP
|
||||
acs: AR2
|
||||
next: loginTwoFactorAuthOTP
|
||||
}
|
||||
{
|
||||
// everyone else skips ahead
|
||||
next: fullLoginSequenceLoginArt
|
||||
}
|
||||
]
|
||||
// ...
|
||||
}
|
||||
```
|
Loading…
Add table
Add a link
Reference in a new issue