Built for records that should not leak

Access and identity

• Role-based access — firm administrator, firm staff, and read-only, each limited to what that role needs, and per-account permissions within a firm.
• Server-side permission checks on every request, not only in the interface.
• Passwords hashed with PBKDF2-SHA256 at an effective 600,000 iterations, compared in constant time, and never stored or transmitted in readable form.
• Session tokens stored hashed, so a copy of the database does not let anyone sign in.
• Cross-site request forgery protection on every action that changes data.
• Rate limiting and account lockout on repeated failed sign-in attempts.

Multi-factor authentication is not yet available in the Shtim portal. It is in development. Until it ships, portal security rests on password strength, so use a long unique password and do not reuse one.

Data separation

• Tenant isolation carried in the database query itself, not only in the interface, so guessing another firm’s identifier returns nothing.
• Automated cross-tenant tests that fail the release if isolation regresses.
• Least privilege for internal accounts and service credentials.

Data protection

• TLS in transit across the site and portal.
• Encryption at rest as provided by our hosting and database platform.
• Point-in-time recovery of the database, plus periodic exports held separately.
• Secrets management outside application code and version control.
• Sensitive values stay out of URLs, public logs, analytics, crash reports, and browser consoles.

Accountability

• Audit logging of imports, edits, assignments, approvals and rejections, matter creation, finalizations and revisions, pricing changes, payments, user changes, and agreement acceptance.
• Revision trails rather than silent edits to finalized reconciliations.
• No third-party code in the application itself — no analytics, no advertising, no external scripts — so there is nothing to scan or patch in the browser.