Account and Application Security Documentation

How to read this document

Sections move from purpose → concepts → calculation process → worked examples → edge cases. Formula boxes use plain mathematical notation for clarity; they are conceptual summaries, not API contracts.

• Point lists call out operator-visible behaviour.
• Callouts mark warnings, limitations, or important qualifications.
• Worked examples use round numbers so you can reproduce the arithmetic by hand.

Security model

AccountHouse uses layered identity, session, authorization, device, and data controls. No single layer makes an account risk-free.

• Protect account credentials
• Use optional second-factor controls
• Review sessions and permissions
• Respond quickly to suspicious activity

Passwords

• Use a unique password generated by a password manager.
• Never share it with household members or support.
• Change it after suspected compromise.
• Protect the email account used for recovery.

Two-factor authentication

AccountHouse offers two second factors: an email one-time code, and mobile approve — a push challenge sent to an enrolled phone that you tap to approve or deny. A second factor supplements the password; it does not replace it.

• Email 2FA depends on the security of the mailbox.
• Mobile approve depends on the enrolled device and its active session.
• Read the approval context before accepting.
• Deny requests you did not initiate.

Email verification flow

Mobile approve flow

Mobile approve sends a push challenge to your enrolled phone during sign-in or a sensitive action; you tap approve or deny. Compare the shown context with what you are actually doing, and reject unexpected prompts.

• Keep the enrolled device locked.
• Do not approve from habit.
• Revoke a lost device promptly.
• Maintain a secure recovery path.

Sessions

A successful sign-in creates a session, and sessions are listed per app: the web dashboard, AccountHouse, AH Lite, and AH Split each carry their own identity, so you can see exactly which client each session belongs to. Sessions remain active until expiry, sign-out, revocation, or security action.

• Rename a session to something recognisable ("my laptop", "work phone").
• Revoke any individual session, or use log out everywhere to end them all at once.
• A personal security activity log records your sign-ins, approvals, and security changes for review.
• Sign out from shared machines and do not copy session tokens.
• Password changes may affect sessions according to security policy.

Household authorization

Authentication does not grant universal data access. Server-side authorization should scope every protected action to the appropriate household and role.

PIN, app lock, and biometrics

App lock asks for biometrics or a PIN when the app opens. A successful unlock lasts about 30 minutes, and briefly switching away is forgiven by a roughly 5-minute background grace period. Enabling app lock requires both your account PIN and your account password, so a passer-by cannot switch it on or off. It complements — never replaces — the operating-system lock, account password, session revocation, and encryption.

• Use a strong device passcode.
• Enable biometrics only on trusted devices.
• Avoid predictable PINs.
• Understand recovery behavior.

Account PIN and per-area gates

A 4–6 digit account PIN gates the most sensitive areas of the product independently of sign-in: income figures, card detail reveals, Goals, and DocuVault. Each gate can be turned on or off per area.

• The Goals gate and the My Cards gate are on by default.
• Card sensitive-digit reveals ask for fingerprint or the PIN before showing amounts and digits.
• The PIN is a viewing gate within an authenticated session — it is not a second factor for sign-in and not the DocuVault encryption secret.

Owner access policy and trusted installs

The account owner can write access rules that constrain where and from what the account may be used. Rules match IP addresses or CIDR ranges, device types, browser families, or specific installs, and each rule is set to one of three modes: off, step-up (extra verification required), or hard-deny.

• Trusted installs record why they were trusted and can be revoked at any time; step-up memory for a trusted install is capped at 180 days.
• Guardrails refuse rules that would be dangerous: fingerprints that are not device-specific and overly broad IP ranges are rejected.
• If the owner is locked out by their own policy, the recovery flow is: request recovery, confirm via email OTP, and the change applies within a 15-minute window.
• Automated security locks can freeze an account on suspicious activity, with recovery by email.

Sensitive actions

High-impact actions may require recent authentication, second-factor confirmation, or additional checks. Public documentation intentionally does not enumerate internal risk rules.

Security notifications and login alerts

When a new login is detected, AccountHouse alerts you by both email and push. Alerts also provide context about approvals, sessions, and account changes. Delivery is a supplementary control, not the source of truth.

• Open the official app directly.
• Do not use suspicious links.
• Review sessions and settings.
• Report unexpected changes.

Account recovery and security locks

Recovery balances access and resistance to takeover. Automated security locks that freeze an account are recovered by email; the owner access-policy recovery flow uses an email OTP and applies within a 15-minute window. Keep registered recovery channels current and secure; do not rely on a single unprotected mailbox or device.

For account backup and deletion — exporting a portable .ahbak backup and the deletion flow with its 3-day grace window — see the Account Lifecycle documentation module.

API and webhook security

Creating or deleting an API key is guarded by step-up verification, so a hijacked session cannot quietly mint credentials.

• Treat API credentials as secrets.
• Use least privilege and rotation.
• Verify webhook HMAC signatures.
• Reject stale or replayed requests according to integration guidance.
• Never expose server secrets in frontend code.

Incident response

Administrator checklist

• Require sensible role assignment.
• Review membership.
• Protect admin accounts with 2FA.
• Remove inactive access.
• Audit sensitive exports.
• Separate user and API secrets.
• Keep clients updated.

Privacy, advice limits, and what we do not publish

AccountHouse is a household tracking and organisation tool. It is not a bank, payment processor, tax advisor, or investment advisor. Forecasts, health scores, balances, and alerts are informational.

• Household data is scoped to your household; other families cannot see your ledger.
• Public documentation explains product behaviour and calculation concepts, not proprietary internals.
• Exact scoring weights, anomaly thresholds, cryptography parameters beyond high-level algorithms, and operational detection rules are reserved.
• No security system can guarantee prevention of every compromise, phishing attempt, endpoint infection, or authorized-user misuse.
• Exact detection thresholds, secret constants, token internals, and operational response rules are intentionally omitted.