deny.sh
Security Posture Overview
An overview of deny.sh’s security architecture, compliance status, and cryptographic implementation for enterprise evaluation.
AES-256-CTR with scrypt KDF (N=16384, r=8, p=1). XOR composition layer enables multiple plausible decryptions from a single ciphertext. 4-byte length prefix inside encrypted zone.
scrypt (RFC 7914) is the memory-hard KDF used by every deny.sh SDK and the API. We chose it over Argon2id for two reasons. First, byte-exact cross-implementation compatibility: scrypt has stable, audited reference implementations in all four target SDK languages (TypeScript, Python, Rust, Go) that produce identical 32-byte output for identical inputs. Argon2id implementations across these languages are less uniformly audited, and library availability inside browser bundles without WebAssembly fallback is patchier. Second, browser performance: deny.sh runs the KDF inside a browser tab during interactive operations, and scrypt at N=2^14 (8 MB memory, ~2^14 iterations) returns sub-second on commodity hardware without WebAssembly. Argon2id's tuneable parallelism (p) is harder to bound predictably across browser engines. The N=2^14 parameter matches the RFC 7914 (2009) interactive-login recommendation. OWASP 2024 guidance recommends N=2^17 (128 MB memory) for at-rest storage with indefinite lifetime; deny.sh defaults to the interactive parameter to keep browser flows responsive. CLI and SDK callers can pass higher parameters today; an opt-in "archival" preset (N=2^17 baseline) for high-value seed-phrase and long-term storage is on the post-launch roadmap. Stronger passwords compensate for lower N: a 64-bit-entropy passphrase costs more to brute-force at any N than a 32-bit-entropy passphrase at any N.
22 automated cryptographic tests: chi-squared distribution, Kolmogorov-Smirnov, Shannon entropy, serial correlation, avalanche effect, ciphertext invariance, and correctness verification. All tests run in-browser at deny.sh/verify.
8.4KB TypeScript, zero runtime dependencies. Also available in Python, Go, and Rust. Published as deny-sh on npm. Full source on GitHub under Apache License 2.0 (free for commercial and proprietary embedding; no copyleft).
Zero-knowledge design. Browser tools run entirely client-side. API processes in memory only. No plaintext logging, no key storage, no payload persistence. All sensitive data is ephemeral.
| Control | Status | Detail |
|---|---|---|
| Encryption at rest | ✓ Active | Full-disk encryption on all servers. |
| Encryption in transit | ✓ Active | TLS 1.3 enforced, HSTS preload, A+ SSL Labs rating. |
| API authentication | ✓ Active | Bearer-token auth. Keys hashed with SHA-256 before storage; raw key never persisted. |
| Login brute-force defence | ✓ Active | Per-IP limit (5 attempts / 15 min) plus per-account lockout (5 wrong passwords on one email → 60-min lock, regardless of source IP) to defend against distributed credential stuffing. |
| Rate limiting | ✓ Active | Per-key burst (10 req/s) + monthly quota, per-IP registration limits. |
| Audit logging | ✓ Active | IP, timestamp, action type, and API-key hash on every operation. |
| Input validation | ✓ Active | Strict validation on all endpoints, body size limits (5 MB), CSP headers. |
| DDoS protection | ✓ Active | Cloudflare proxy with WAF rules. |
| Backup & recovery | ✓ Active | Automated daily backups, tested restore procedures. |
| Dependency scanning | ✓ Active | Zero runtime dependencies in core SDK. Server dependencies audited regularly. |
| Supply-chain publish path | ✓ Hardened | All npm, cargo, and Go publishes done by hand from one IP-pinned machine. No CI in the npm publish path. Zero pull_request_target workflows in any repo. npm tokens are Granular Access, package-scoped, IP-allowlisted. PyPI publish workflow uses OIDC trusted publishing on push: tags only. Full audit response to Mini Shai-Hulud (May 2026): /blog/mini-shai-hulud-and-deny-sh. |
| Penetration testing | Scheduled | Independent third-party review scheduled for 2026. |
deny.sh sets a strict same-origin Content Security Policy on every response. script-src
and style-src currently permit 'unsafe-inline' in addition to 'self',
required for per-page initialisation snippets across our static site. Billing uses
Stripe Checkout (server-side redirect to checkout.stripe.com), not Stripe.js
or Elements, so no third-party script or frame origins are whitelisted: script-src
is 'self' 'unsafe-inline' only, and frame-src 'none' blocks all iframe
embedding. The 'unsafe-inline' carve-out is mitigated by:
same-origin enforcement on every other directive, X-Frame-Options: DENY,
frame-ancestors 'none', strict server-side input validation on every
endpoint, output escaping in all email templates, and SHA-256 hash-only API-key
storage so a hypothetical injection cannot exfiltrate raw credentials.
Long-term roadmap: extract all inline scripts to external files served with
Subresource Integrity hashes and a CSP nonce, removing 'unsafe-inline'
from script-src entirely. Tracked as a post-launch hardening item.
HSTS with preload; X-Content-Type-Options: nosniff;
Referrer-Policy: strict-origin-when-cross-origin;
Permissions-Policy denies camera, microphone, geolocation, USB, and
payment APIs site-wide. Cookies on authenticated consumer sessions are
HttpOnly; Secure; SameSite=Strict.
| Standard | Status | Detail |
|---|---|---|
| GDPR | ✓ Compliant | UK-registered data controller. Privacy policy covers all processing. Data deletion within 7 days on request. |
| SOC 2 | In progress | Architecture designed with SOC 2 principles. Hash-only key storage, full audit logging. |
| ISO 27001 | Mapped | Security controls mapped to Annex A. Documentation available for enterprise customers. |
| PCI DSS | ✓ N/A | No payment-card data processed. Stripe handles billing under PCI DSS Level 1. |
| Export controls | Aware | Encryption software. UK OGEL covers most commercial use. Customer responsible for local compliance. |
deny.sh is operated by Treehouse in Valhalla Ltd, a private limited company registered in England and Wales (company number 15770209). Our primary infrastructure, registered office, and operating team are located in the United Kingdom. UK law applies to deny.sh's contracts and operations, and UK GDPR governs our processing of personal data.
Operating from the UK means deny.sh sits within the regulatory perimeter of the Investigatory Powers Act 2016 (IPA 2016). Under section 253 of the Act, the UK Secretary of State may issue a Technical Capability Notice (TCN) to a UK-based operator requiring it to maintain capabilities to assist with investigatory-powers warrants. To date, deny.sh has not received any TCN, secret data-retention notice, technical-assistance demand, or undisclosed warrant of any kind. We commit to a transparency report with cumulative disclosure counts (or a continued zero) at each subsequent annual update.
Two structural points limit what any such notice could compel. First, the deny.sh primitive runs client-side: the browser tools and SDKs derive keys, encrypt, and generate decoys without those operations passing through our infrastructure. We never see plaintext, passwords, or control files for the open-source primitive.
Second, the cryptographic deniability of the construction is a property of the algorithm: even with cooperation from us, an adversary cannot determine which of two valid plaintexts is "real" from a ciphertext + control-file pair, because that distinction does not exist in the bits. Any TCN that demanded we modify the SDK or API to weaken this property would be visible in the open-source repositories, and the SDKs (TypeScript, Python, Go, Rust) are mirrored publicly so customers can pin and audit specific versions.
Customers requiring jurisdictional separation from the UK should evaluate the open-source SDKs deployed in their own infrastructure rather than the deny.sh hosted API or managed vault. The primitive is the same; only the operator changes.
The cryptographic primitive (TypeScript, Rust, Go, Python SDKs) is licensed under Apache License 2.0. Free for commercial and proprietary embedding. No copyleft obligation, no licence fee, no legal review required.
The deny.sh vault, dead-man's switch, inheritance dispatcher, MCP server orchestration, hosted-API server source, and browser-tool source code remain under AGPL-3.0. Self-hosting these components is permitted; self-hosting them as part of a proprietary commercial service requires the application-layer commercial licence below.
From $25,000/year. Embed the deny.sh application-layer code in proprietary products without the AGPL copyleft obligation. Includes priority support, architecture review, and multi-language SDK access (Apache-licensed and free regardless). See /licensing.
For enterprise inquiries, security questions, or to request a full architecture
review under NDA:
Email: hello@deny.sh · Web: deny.sh/enterprise