Security

Primary application data is provisioned in Sydney, Australia (Google Cloud australia-southeast1), verified at go-live. Static assets are served via our CDN.

All traffic is served over HTTPS with HSTS. Data is encrypted in transit and at rest by our cloud provider. We set a Content-Security-Policy (including frame-ancestors ‘none’ and object-src ‘none’) and standard security headers on every response.

By default you sign in with an email and password managed by HAMANI. Passwords are stored only as a one-way PBKDF2-SHA256 hash (600,000 iterations), never in plaintext. Sessions are signed (HMAC-SHA256), HttpOnly, SameSite=Lax cookies, and sign-in is rate limited against brute force.

A new account must confirm its email before the first sign-in: we send a single-use verification link (valid 24 hours). A password reset works the same way (single-use link, valid 1 hour) and does not sign you in — you sign in with the new password. Tokens come from a cryptographically secure generator and are stored only as a one-way SHA-256 hash; requesting a new link invalidates the old one, both flows are rate limited per account and per IP, and responses never reveal whether an address is registered.

Enterprise customers can federate their own identity provider (SAML 2.0 or OIDC). Even then, HAMANI is the system of record: there is no shared identity provider across products — your identity provider proves who a user is, while your account, sessions and roles stay with HAMANI. Multi-factor authentication for password accounts is on our roadmap; SSO customers can enforce MFA at their own identity provider today.

You can also sign in with Google or Microsoft / Entra (RS256 ID-token verification against the provider’s published keys, with nonce, audience and expiry checks; Microsoft is bound to a single directory). These federate identity into our own auth — HAMANI remains the system of record.

Passkeys (WebAuthn / FIDO2) let you sign in with your device’s biometrics — Face ID, Touch ID, Windows Hello or an Android biometric. The biometric is checked on your device and never reaches HAMANI; we store the credential’s public key, its signature counter, and the label and date you add it with — erased with your account on deletion. Every sign-in is verified (origin, single-use challenge, user-verification and the signature) before a session is issued. Passwords remain available as a fallback.

Every record is scoped to your workspace (tenant). Database rules are deny-by-default: the client can only read your own tenant’s data, and all writes go through the server.

We use vetted sub-processors only: Google (Firebase/Firestore), our CDN, Stripe (billing), AWS SES (email, via HAMANI's own Email engine), and Anthropic (HAMANI CONCIERGE AI). See the Privacy Policy and the full list on the Trust Centre.

We are not SOC 2 or ISO 27001 certified and do not claim to be — our controls are built to support such a program, which can be initiated on an enterprise engagement. The Trust Centre answers the standard security questionnaire from implemented controls, and lists honestly what is still on the roadmap (e.g. native MFA, an independent external penetration test and uptime monitor, a formal DR plan). For a data-processing agreement see the DPA template.

You can delete your workspace and request erasure of your personal information from Settings → Account (Privacy Act 1988). A record of the deletion request is retained as the law allows.

Found a vulnerability? Email security@hamanimarketing.com.au. We’ll acknowledge and work with you in good faith.