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 supports high-level second-factor flows including email verification and mobile approval where configured. A second factor supplements the password; its exact availability can depend on account and client state.

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

Email verification flow

Mobile approval flow

An enrolled mobile device can be asked to approve a sign-in or sensitive action at a high level. The user should compare available context 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 with limited credentials and lifecycle controls. Sessions can remain active across web and mobile until expiry, sign-out, revocation, or security action.

• Review active sessions regularly.
• Revoke unfamiliar devices.
• Sign out from shared machines.
• 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

A local app lock adds protection against casual device access. It is not a replacement for the operating-system lock, account password, session revocation, or encryption.

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

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

Alerts can provide context about sign-ins, approvals, sessions, or 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

Recovery balances access and resistance to takeover. Keep registered recovery channels current and secure; do not rely on a single unprotected mailbox or device.

API and webhook security

• 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.