Security and data practices

Accounts and sessions

• Passwords are hashed with scrypt (N=2¹⁵, r=8, p=1, 16-byte salt) and compared in constant time. Minimum 10 characters, checked against a list of 1,000 common passwords and against your own email.
• Sessions are server-side records referenced by an HttpOnly, Secure, SameSite cookie with a 30-day sliding expiry. The database stores a hash of the cookie value, never the value. Sessions rotate on login and can all be revoked from the account's security page.
• Login is rate-limited per address and per email. Unknown emails cost the same time as a wrong password.
• Reviewer, vendor, client and auditor links are single-purpose tokens of 32 random bytes, stored hashed, with an expiry. Every use records the time, IP address and browser, and the page says so before anyone acts.

Requests and browsers

• Every state-changing form carries a CSRF token bound to the session; in production the request origin must match the app's own host. JSON endpoints require a same-origin fetch header.
• Content Security Policy allows only the app's own origin: no inline scripts, no third-party scripts unless you turn on analytics, no framing by other sites. HSTS, Referrer-Policy and nosniff are set on every response.
• Global rate limit of 300 requests per minute per address; 10 per minute on authentication endpoints.
• Every request carries an id that appears on error pages and in logs. Logs never contain passwords, tokens, cookies or full bank numbers.

Uploads and evidence

• Uploads are accepted only when their content matches an allowed type (PNG, JPEG, WebP, PDF, CSV, text, EML, XLSX), 10 MB per file. Files are stored under random names with their SHA-256 recorded, served only through authenticated or tokenized routes, and never rendered as HTML.
• Every account has a hash chain of events: each record's hash covers the previous one, so editing or deleting history is detectable. Evidence PDFs print their own SHA-256, the chain head and a public verify URL, so a document can be checked after you leave.
• Apps that handle payment details store the bank name and the last four digits only. Validators reject longer digit strings and the free-text scrubber redacts them.

Data location, retention and deletion

• Each app has its own database on servers operated by InfiniHash LLC in the United States. Apps do not share databases with each other or with this store.
• Databases are backed up nightly and backups are kept for 14 days. The status page shows each app's last backup time.
• You choose a retention period inside each app; expired data is removed by a scheduled job. Account deletion is a hard delete of your records and uploads. Generated PDFs are purged after 30 days unless you downloaded them.
• The store itself keeps no user accounts. Its Billing Hub stores the email address given at checkout, Stripe customer and subscription identifiers, and the Stripe events it received. Card numbers never reach us.
• Optional third parties: Stripe for payments; Google Analytics only if it is enabled on an app, configured without advertising features and with IP anonymization.

Responsible disclosure

If you find a vulnerability in any InfiniHash app, email [email protected] with "Security report" in the subject. We acknowledge within two business days, keep you informed while we fix it, and credit you if you want. Please do not access other people's data, and give us time to fix before publishing.

Per-app security pages

• AttestProof — security
• BankChangeProof — security
• ControlLedger — security

We produce evidence and records. We do not give legal, tax or audit advice, and we never claim that you or your organization is compliant with a standard.