Server-side credential custody
Torn API keys remain in TornChain's server-side credential store. They are not placed in browser storage or returned in application responses.
How TornChain protects API keys and faction data.
This page describes the controls currently implemented by TornChain and the limits of those controls.
Faction members, faction administrators, and TornChain site-administrator screens cannot view or export API keys. However, TornChain performs unattended server-side polling, so its server must be able to use a stored key. A person with root control of the Droplet and application deployment can technically alter or inspect that running process. Preventing the infrastructure owner from doing that requires a separately controlled credential service that is not included in this application package.
No key-view function
No faction, administrator, testing, Discord, report, export, or browser endpoint returns a stored Torn key. Administrator features consume cached operational results instead of selecting credentials.
Used only for Torn requests
The server accesses a member key only when an authorized feature needs to call the official Torn API. Keys are not intentionally written to logs or shared with faction members.
Separated operational secrets
Production keeps application secrets outside the image, source tree, and database. Database access, host access, and backups are limited to the services and operators that require them.
Credential handling
- Stored credential
- The member's Torn key and its service metadata remain in the server-side credential store until the member disconnects or deletes the account.
- Service access
- Background services retrieve a credential only through the dedicated credential module when an authorized Torn request is due.
- Duplicate identifier
- A keyed, non-reversible identifier detects accidental reuse without becoming a usable Torn API key.
- Key lifecycle
- Accepted over HTTPS, verified with Torn, stored server-side, used for official Torn requests, and deleted when the member disconnects or deletes the account.
Sessions and request integrity
- Session storage
- Only a SHA-256 hash of each random TornChain session token is stored in the application database.
- Browser cookie
- Session cookies are HttpOnly, Secure, SameSite=Lax, and scoped to the site root.
- CSRF protection
- Every authenticated mutation requires a session-bound HMAC-SHA-256 token, same-origin validation, and Fetch Metadata checks. Login first obtains a separate, short-lived signed token in a Secure, HttpOnly, SameSite=Strict cookie, then must return the matching value in an X-CSRF-Token header. Credential enrollment remains JSON-only and same-origin checked.
- Tenant isolation
- Faction scope is derived from the verified server session. The browser cannot select a different faction ID to access another faction's data.
- Torn overlay connection
- The optional TornChain Overlay accepts a Torn key once for server-side verification and protected credential enrollment. The key is cleared from the form before the request begins and is never written to Tampermonkey storage. Tampermonkey receives only a separate random, expiring bearer token; TornChain stores only its SHA-256 hash. That token exposes a minimal faction feed and only the member's own participation, current-hit claim or assignment release, and watcher check-in or check-out actions. Membership, faction access, role, and action rules are checked server-side on every request. The token expires after 180 days or 30 inactive days, and the member can revoke it from the overlay or Settings.
Torn API data-use summary
- Data storage
- Credentials remain in TornChain's server-side credential store until the member disconnects or deletes the account. TornChain also stores the cached operational data needed for faction features.
- Data sharing
- Faction coordination data is visible only to verified members of the same faction. Personal energy may appear in faction totals and claimant-readiness indicators. Raw personal battle stats are not shown to other faction members.
- Purpose of use
- Identity verification, faction-membership validation, chain polling, energy confirmation, watcher coordination, war operations, and faction reporting.
- Key storage and sharing
- The TornChain sign-in key is stored server-side and sent only to the official Torn API. An optional FFScouter key is entered separately in account Settings and is used only for FFScouter estimate requests.
- Retention
- Cached Torn data is retained for faction operations, audit history, and reporting until removed under the account and faction data-retention controls.
Minimum Torn access
Use a Limited Access key, or a Custom key containing only the selections TornChain needs:
- User: basic identity, faction membership, bars, and the user's own battle stats
- Faction: current chain, members, chain report, detailed attacks, ranked wars, and organized crimes
Full Access is not requested. TornChain cannot use selections that the member has not granted to the key.
External integrations
- Discord OAuth and bot credentials are separate installation secrets.
- The payment monitor uses a dedicated recipient key and never a member credential.
- FFScouter uses optional credentials connected by individual members and rotates them only within that member's verified faction. TornStats and BSP use separate provider configuration.
- Stat providers receive only the target identifiers and operational data required to return an estimate.
- Users can choose which available estimates are displayed in their War view.
Provider failures are isolated from chain polling. Integration credentials and sensitive error values are redacted from application logs.
User controls
- Disconnect the stored Torn credential.
- Revoke current TornChain sessions.
- Rotate or revoke the optional Torn overlay connection token, which also expires after 30 inactive days.
- Delete stored TornChain account data.
- Replace or revoke the API key through Torn's settings.
- Control notification and optional integration preferences.