think
16px
820px

Attack Surface / Threat Model — reference detail

Status (2026-07-13): partly in scope. The paper is Jaringan-led, and security appears as one countable/analytical metric (#7): attack surface = number of nodes holding store credentials + able to write/propagate (LuckPerms N, LCore N, NeoCore 1). That simple count IS in the paper (Eval §E). This document's fuller capability table below is optional reference detail — do NOT turn it into a formal threat model, adversary simulation, or hardening build; that's the cybersecurity depth deliberately left out of scope. Keep the paper's security treatment to the count + one honest caveat: NeoCore's transport is currently plaintext/unauthenticated, so the advantage is credential distribution and channel hardening (TLS/auth) is future work.

Scope & assets

  • Assets: the permission store (ranks/prefixes), the authority to change permissions, and the propagation channel that carries changes.
  • Primary attacker: one fully compromised game server — the attacker holds whatever that one fleet node legitimately holds. (Secondary: a passive/active network attacker on the sync link.)
  • Out of scope: compromise of the master/DB host itself, physical access, full penetration testing.

Trust models compared

  • Flat trust (LCore, and LuckPerms-style messaging): every server holds credentials to the shared store and can broadcast changes. No central authority.
  • Mediated authority (NeoCore): game servers hold no store credentials; all mutations go through one authoritative master. (As-is: plaintext gRPC, no authn. Hardened: + TLS + token auth.)

Capability table — what can ONE compromised game server do?

Capability Flat (LCore / LuckPerms) NeoCore — as-is (plaintext) NeoCore — hardened (TLS + auth)
Directly read the permission store Yes (has DB creds) No (no DB creds) No
Directly write/modify the store Yes No No
Directly broadcast a change to the fleet Yes (publish to Redis) No (must ask the master) No
Request a change from the authority n/a (no authority) Yes Yes, but authenticated + authorizable
Impersonate another server (spoof origin id) Yes (no identity check) Yes (requesterServer is a plaintext string) No (mutual auth)
Eavesdrop sync traffic (passive) Yes (on-path) Yes (plaintext) No (TLS)
Tamper with sync traffic in flight (MITM) Yes Yes No (TLS)
Escalate to network-wide admin Yes (write store + propagate) Partial (only if the master accepts an unauthorized request) Scoped by authz (residual: within its own authorized role)
DoS the sync path Yes (flood channel) Yes (flood master) Yes (rate-limiting = further work)

Key findings (the paper's security narrative)

  1. The biggest blast-radius reduction is already there in NeoCore, for free: credential separation. Because slaves hold no store credentials, a compromised game server cannot read, write, or broadcast permissions directly — it can only ask the authority. This holds with zero hardening and is verified in the code (no JDBC/Redis in client*).
  2. What the minimal hardening (A1) adds: TLS closes eavesdropping/MITM; token/mutual auth closes server impersonation (today requesterServer is a spoofable string). These convert NeoCore from "architecturally mediated" to "mediation you can actually trust on the wire."
  3. Honest residual risk (state it plainly): even hardened, a compromised node with a valid credential can still act within its authorized scope; full least-privilege authorization (which server may change which ranks) is further work, as is DoS rate-limiting. Hardening shrinks the blast radius and removes impersonation/eavesdropping; it does not make a compromised-but-authorized node harmless.

How each row is evidenced in the paper

  • "No DB creds" rows → static evidence (code: absence of store credentials in slaves).
  • Impersonation / eavesdrop / MITM rows → demonstrated before/after A1 (a small PoC: spoof requesterServer pre-hardening; show auth rejects it post-hardening; show plaintext capture vs TLS).
  • Escalation / DoS rows → analytical, with the residual-risk caveats above.