1Share security statement

This document describes the security controls implemented in 1Share, operated by File Pty. Ltd.. It is the public security statement for this production instance.

1Share is a system for sending credentials and other sensitive text or files using time-limited, view-limited links. Security is designed so that a stolen database dump or file store is not enough to read a secret.

Design principles

• Encrypt before storage. All message content is encrypted in the application before it is written to the database or disk.
• Split keys. Each message has a data key that is split in two. One half lives in the link fragment (#k=), which browsers do not send to the server. The other half is stored wrapped with a server key. The database never holds a complete decrypt key.
• Least data on the server. Plaintext, URL keys, passphrases, passwords, and authenticator codes are not written to the audit log.
• Fail closed on links. Missing or malformed keys, unknown identifiers, expiry, and exhausted views do not leak which condition occurred beyond a generic holding page or invalid-link warning.
• No surprise decrypt. Opening a link (including chat unfurls) does not consume a view or decrypt the payload. Decrypt is an explicit action.

Encryption (application-based, at rest)

Message encryption is performed in the application (PHP libsodium). Database-engine encryption functions are not used for message content. A database dump without each message’s URL key (and passphrase if set) cannot be decrypted. A server wrapping key only unwraps the stored half of each split key and wrapped account authenticator secrets.

While running: the application can decrypt a message when a client presents the URL key (the Decrypt action). A compromised live server that observes that request can see that plaintext. That is the model chosen so recipients do not need special client software.

Transparent Data Encryption (TDE)

The production database is expected to enable InnoDB tablespace encryption (TDE). TDE is a host control for stolen volumes and offline files. It is independent of, and does not replace, application encryption.

When TDE is on:

• Application tables are encrypted at rest on disk.
• Redo and undo logs should also be encrypted.
• The database decrypts pages for authorised queries. An administrator with SQL access still sees compliance columns (IP addresses, file names, fingerprints) and ciphertext blobs; they still cannot read message plaintext without the server wrapping key and the URL key.
• Encrypted attachment files on disk are not covered by database TDE. They remain protected by application encryption (and optional disk encryption on the host).

Transport and browser

• This service is served over HTTPS only. HTTP is redirected. Session and CSRF cookies include the Secure flag.
• Pages and API responses send standard browser hardening headers, including a Content-Security-Policy that allows scripts and styles from this origin only (no inline scripts). If Cloudflare Web Analytics is enabled on the site, that product’s scripts are also permitted.
• HTTP Strict Transport Security is enabled.
• robots.txt disallows crawling of the application. Compose, retrieve, account, and history pages are noindex. Security and privacy statements may be indexed.
• Decrypt keys are placed in the URL fragment (#k=), which is not sent to the web server, reverse proxies, or Referer headers.
• Access logs record the URL path, not the query string, so keys are not written to log files if they were ever mistakenly put in a query.

Access control

Abuse resistance

• Invalid decrypts (wrong key or passphrase) are counted per client and message, then temporarily blocked.
• Uploads, login, signup, and MFA checks are rate-limited per client. Repeated failures also impose a temporary block. If Redis is unavailable, login and signup are refused. Creating a secret without an account still works within the anonymous size cap.
• Failed decrypts are presented as an invalid link. Unknown, expired, deleted, and view-exhausted messages share the same “not found” copy to limit enumeration.
• Chat and preview bots that fetch a link receive metadata or a holding page only.
• Size, view, lifetime, attachment, passphrase, and reply rules are enforced on the server, not only in the browser.

Application firewalling of the filesystem

• Only the public web directory is served. Application source, configuration, and data directories are not web-accessible.
• Directory indexes are disabled.
• Encrypted files are written outside the web root.
• Wrapping keys and database credentials are kept in server configuration that is not published under the web root.

Production host

This instance runs on Red Hat Enterprise Linux 9.8 with SELinux enforcing, Apache httpd, PHP-FPM, Percona Server for MySQL, and Redis.

• Redis and the database listen on the local host, not on the public network.
• Encrypted attachments are stored outside the web root.
• The public document root contains only web assets.

Audit without content

Compliance events are append-only (create, decrypt granted or denied, delete, purge, reply-link create, reply received). They record timestamps, IP addresses, original file names, and keyed HMAC fingerprints of text and files. They do not record plaintext, URL keys, passphrases, passwords, or authenticator codes. With TDE, those audit rows are encrypted on disk; they remain readable through SQL to operators who can query the database. Detail is in the privacy statement.

What this does not claim

• It is not end-to-end (browser-only) encryption. The server performs encrypt and decrypt.
• TDE does not make the database zero-knowledge. It protects files on disk, not live SQL sessions.
• It cannot protect a message if the full link (and passphrase) is forwarded to an attacker.
• It cannot reconstruct a secret if the recipient loses the #k= fragment.
• Replacing the server wrapping key without a planned rewrap makes existing ciphertext and wrapped authenticator secrets unreadable to the application.
• Losing the TDE keyring makes encrypted tablespaces unreadable after restore, even if application configuration is intact.

Contact

This instance of 1Share is provided by File Pty. Ltd.. Questions about these controls can be directed to that organisation.