Skip to content
MyAlg.

Security

How your credentials are held

Connecting a broker account means handing over the keys to real money. This page says what happens to them, how a session works, how one organization is kept out of another, and what has not yet been proven.

Broker credentials

The most sensitive thing this system will ever hold.

  • Encrypted at rest with AES-256-GCM

    Each credential field is stored as ciphertext with its own initialisation vector and authentication tag. GCM is authenticated encryption, which means a tampered ciphertext fails to decrypt rather than quietly producing a different value — the failure mode matters as much as the secrecy, and it is covered by tests that deliberately corrupt each part of a stored credential to check the failure actually happens. The application refuses to start without its encryption key rather than falling back to storing anything in plain text.

  • Never rendered in the browser

    A broker credential is not sent to the page in a property, not returned by an API response, not written to a log line, and not shown as "just the last four". There is no screen in this application that can display one, which is the only version of this promise that survives a future feature request.

  • Logs are redacted centrally

    Redaction is configured once, in the logging package every process shares, and it is on by default. A redaction rule that each caller has to remember is a rule that will be forgotten by the one caller that matters.

Sessions and sign-in

A session is a row in a database, not a signed token floating around the internet.

  • Revocable, because it is a row

    Signing out deletes the row, and so the session is over everywhere immediately. A self-contained token cannot be taken back before it expires; a row can. Each session records when it expires, and the address and browser it was created from.

  • The raw token lives only in your cookie

    What the database holds is a SHA-256 hash of it. A leaked copy of the sessions table therefore cannot be replayed as anybody, because the values in it are not the values a cookie has to present.

Invitations

There is no public sign-up, so the invitation is the entire front door.

  • An invitation is bound to one email address and cannot be forwarded to another.
  • It expires. An invitation from eight months ago is not consent.
  • It can be accepted once, and the membership it creates is written in the same transaction that consumes it.
  • The token itself appears only in the email. It is stored as a hash, and it is never returned to whoever sent the invitation — handing the raw token back to the inviter would turn accepting an invitation into a way to take over someone else's account.

One organization cannot see another

Multi-tenancy is a data-access rule, not a filter in the interface.

  • Scope comes from your session, never from the request

    Every query for tenant-owned data carries the organization it belongs to, and that value is taken from the signed-in session rather than from anything the browser sent. A client that can name its own organization is a client that can read somebody else’s orders.

  • "Not found" and "not yours" are the same answer

    Deliberately indistinguishable. If a record that exists but belongs to someone else answered differently from one that does not exist, the difference between the two answers would itself be a way to enumerate other people’s data.

  • Two kinds of role, kept apart

    What you may do on the platform — manage invitations and feature flags — is a separate axis from what you may do inside an organization, where the roles are owner, trader and viewer. A platform administrator does not thereby gain access to another organization’s trading data.

The audit trail

Append-only rows in the database, not only lines in a log.

Logs rotate, and "who raised that limit, and when" is a question asked months later. So security-relevant events — sign-in failures, order submissions, changes to risk limits — are rows: what happened, who did it, against which record, with the before and after value of what changed, and how serious it was.

Loosening a limit is recorded at a higher severity than tightening one, because the two are the same form submission and completely different events. An audit entry never carries a secret value.

Trading is off by default

Every switch that can cause a real order to be sent ships in the off position.

There are kill switches at four levels — the whole system, your organization, a single broker account, and one strategy — and any one of them stops an order. They are checked by the worker immediately before submission rather than when you pressed the button, because by then the request has already happened and a switch checked at request time is decorative.

What has not been proven

This is a pre-launch system

MyAlg has had no independent security review and has no production history. Sign-in and session handling have been exercised end to end against a real database, and the credential encryption has its own tamper tests. The invitation path has not: no invitation email has ever been sent from this application.

Everything on this page describes how the system is built. None of it is a warranty, and it should not be read as one. There is no published security contact yet; when access opens, there will be.