Security

One standard for the whole ecosystem. The same protections cover every part of Oneway: a person's account, profile and messages in the Oneway App; a community's or a business's Center; the operating side of every Center in Oneway OS, Business OS and Developer OS; every System a Center runs, from a restaurant's floor and a hotel's rooms to a venue, a shop and a casino resort; every website a Center wears; and every integration and app built on the platform. A neighborhood group and a casino's operating floor sit on the same platform, so they are held to the same bar: the one set by the most regulated industry we serve.

What this page is. Oneway is in closed beta and is not yet running as a public service. This page describes the security controls built into the platform today, each exactly as it is implemented. Nothing here claims a certification we do not hold. For how we handle personal information, read the Privacy Policy; for blocking, reporting and the protections teen accounts start with, read Safety.

Identity and sessions

• Passwords are hashed with bcrypt at a work factor of 12, each with its own salt. A password is never stored, logged or returned in plain text.
• Two-step verification uses time-based one-time passwords (TOTP, RFC 6238) from any standard authenticator app. Codes are verified in constant time, and recovery codes are stored only as hashes. We do not offer codes by text message, because SIM swapping defeats them.
• Two-step is available on every account and required where the stakes are highest: the whole operating side of a casino's Center asks for it by default.
• Sessions are held on our servers and referenced by a random token in a __Host- cookie marked Secure, HttpOnly and SameSite=Lax. No session token is ever stored where a script can read it, and signing out ends the session on the server, not only in the browser.
• Changing a password ends every other session on the account at once.
• Signing in reveals no account. A signed-out sign-in or password reset answers the same whether or not an address has an account.
• Rate limits on every endpoint, applied per session and per network address, so one person's traffic never spends another's allowance. Over the limit, a request is answered with 429 and a Retry-After, and nothing behind the endpoint runs.

Between people and between Centers

• Authority comes from the relationship, never from the request. What a person may see or do is decided by their real standing with a Center (owner, admin, staff or member) and by what each person has chosen to share, never by an identifier the caller supplies.
• One Center can never reach another's operating side. An automated test reads every Center endpoint from the application's own route list and calls each one as the owner of a different Center. A new endpoint is tested the day it is added.
• Every change requires a signed-in person. An automated test calls every endpoint that changes anything while signed out; none succeeds, except the few a signed-out person needs, such as signing in and resetting a password.
• Roles each Center defines for itself. Beyond owner, admin and staff, a Center can name its own roles. A role can only narrow what a member of staff may see and do, and every role change is written to the security log.

Encryption and secrets

• Every Center has its own secrets vault. Credentials a Center uses to connect its own systems are encrypted with AES-256-GCM under a data key belonging to that Center alone.
• Envelope encryption. Each Center's data key is itself encrypted under a master key that is never stored in the database.
• Every ciphertext is bound to its place. Each one is authenticated with its Center and its name as associated data (AEAD). A value copied to another Center, or renamed, fails to decrypt, and any altered byte fails the authentication tag.
• Secrets are write-only. No endpoint returns a secret, not even to its owner. Operators see a secret's name, who set it, when, and when an integration last used it. The value reaches only the server code that calls that provider.
• Keys are 256-bit values from the operating system's cryptographically secure random generator, with a fresh nonce for every encryption.
• Key rotation without exposure. Rotating the master key re-wraps each Center's data key. No secret is decrypted to do it.
• Crypto-shredding. Removing a Center's vault destroys its data key, and from that moment the platform can no longer open any secret it held. Encrypted database backups made before the removal still hold the old key until they age out, within 14 days.
• Personal secrets, such as a two-step seed, are sealed under a key derived for that one purpose and bound to the person they belong to.
• In transit: HTTPS everywhere, with HTTP Strict Transport Security for one year across every subdomain.

Integrations and apps

• A business connects its own systems. A provider cannot sign itself in to a Center. Each Center sets up its own integrations, with credentials only it holds, kept in its own vault.
• Every feed has its own key, shown once when it is issued and stored only as a SHA-256 hash. Issuing a new key disables the old one immediately.
• Signed webhooks. Messages from a connected vendor are verified by their HMAC-SHA256 signature in constant time before anything is read, and a signed message is refused once it is too old to be fresh.
• Apps built on Oneway run on their own sandbox host, under their own content security policy.

Outbound requests

Server-side request forgery, where a server is tricked into fetching an address that points inward, is how a vendor's server becomes a way into its customers' networks. Every request an integration makes goes through one guarded fetcher:

• HTTPS only, to the hosts each integration is allowed to reach.
• Publicly routable addresses only. Private, loopback, link-local, carrier-grade NAT and reserved networks, cloud metadata endpoints, and their IPv6 and IPv4-mapped forms are all refused.
• The name is resolved once, and the connection is made to exactly the address that was checked, so DNS rebinding cannot redirect a request after it is checked.
• TLS is verified against the host name, and every redirect is checked again from the start.
• Every request is bounded in size and time, and no proxy is taken from the environment.

In the browser

• X-Content-Type-Options: nosniff: a response is never read as a type other than the one it declares.
• frame-ancestors 'self': no other site can frame Oneway's pages for clickjacking.
• Referrer-Policy: strict-origin-when-cross-origin: no path or query string leaks to another site.
• A Permissions-Policy that allows location, the camera and the microphone only to Oneway's own pages, each only when the person allows it, and shuts Bluetooth, USB, serial ports, HID devices and payment.
• Cross-Origin-Opener-Policy: same-origin, and Cross-Origin-Resource-Policy: same-site on data, so another site cannot embed Oneway's data.

Files and photos

• A file is identified by its bytes (its magic number), never by its name or its declared type. Anything unrecognized is refused.
• Sizes are capped before anything is decoded.
• Photos are stored without where they were taken or by what. GPS position, device and capture metadata are removed before storage, without altering a pixel, and the orientation is kept.
• Content-addressed storage. Every file is stored under its owner and a SHA-256 digest of its contents. An upload cannot choose its path, climb out of its folder or overwrite anyone else's file.

Accountability and disclosure

• A tamper-evident security log records sign-ins, refused sign-ins, changes to how an account is protected, and changes to roles and access. Each entry is chained to the one before it with an HMAC, so an altered or removed entry shows exactly where. It never records a password, a code, a token or a credential's value.
• Dependencies are pinned to exact versions with cryptographic hashes, on a supported runtime.
• Vulnerability reports are welcome at the contact in security.txt (RFC 9116). We read every report.

The standard we hold ourselves to

The bar named at the top of this page, the one the most regulated industry we serve sets for its vendors, is OWASP ASVS Level 3 for every endpoint, mapped to a recognized control framework (CIS Controls, ISO/IEC 27001 or NIST SP 800-53), and GLI-GSF-3, the gaming industry's information security audit for vendors. A SOC 2 Type II report and independent penetration testing are part of that program. This page will say when each is complete, and never before.