9/10Confidentiality
Restrict one account from reading another account's private finance workspace.
Technical Security & Infrastructure
Security is a system, not a screen.
Triplem VIP is structured as a private browser-based finance workspace with database-enforced ownership, bcrypt password verification, encrypted Authenticator App 2FA, protected Smart PIN and account recovery, authenticated sessions, visitor Live Support, signed-in in-app care and deliberately separated Bitcoin key handling. This page explains what the project actually implements, where each trust boundary sits, and what users remain responsible for protecting.
Supabase PostgreSQL
Owner-isolated data
Server-verified sessions
Encrypted Authenticator 2FA
Visitor + In-App Support
Offline queue & recovery
Client-side private keys
9/10Google Gemini AI assessment of Triplem VIP
Security posture
A layered control model built around identity, ownership and recoverability.
The production project does not treat a hidden frontend control as a security boundary. Access decisions are reinforced by server-side session checks, database ownership, permissions and guarded administrative functions.
Triplem VIP combines personal and business finance workflows in one authenticated application. Wallets, expenses, loans, installments, inventory, customers, assets, notes, invoices, reports and saved Bitcoin addresses all live behind an account-aware workspace rather than a public shared ledger.
The current project uses a Supabase-backed PostgreSQL data layer, explicit user and session records, owner identifiers on domain data, row-level security policies and controlled RPC functions. The migration history extends through the current production schema line, including security hardening, password policy, encrypted Authenticator App 2FA, 2FA-backed password and Smart PIN recovery, temporary-password administration, guarded Live Support routing, session behavior, storage management and Smart PIN lockouts.
Security is intentionally divided into boundaries. Password verification and authorization belong to the server and database layer. Browser persistence is limited and encrypted when Remember Me is chosen. Offline finance writes use a constrained local queue. Sensitive Bitcoin key material is generated or imported in the browser and is not written into the saved-wallet database record.
Integrity
Use controlled create, edit, delete, restore and administrative flows instead of unguarded data mutation.
Least privilege
Module permissions and protected administration reduce the need to expose every capability to every user.
Recoverability
Backups, recycle behavior and a bounded offline synchronization queue support operational continuity.
System map
From interface to database, each layer has a distinct responsibility.
The architecture is intentionally browser-centric at the presentation layer and database-centric at the trust boundary.
HTML, modular CSS and JavaScript render the landing experience, authenticated dashboard, forms, overlays, charts, PDF tools and device-specific layouts.
The client presents the active session credential, resolves the current account and respects role, module and action permissions.
Data operations pass through Supabase REST endpoints and database functions that validate account or protected-admin context.
Domain tables carry owner context while row-level policies and security functions enforce access at the data layer.
Uploaded branding assets, backups, exports, analytics storage controls and local offline recovery serve distinct operational roles.
Identity & access
Authentication is more than accepting a password.
The project separates account identity, password verification, session state, permissions, Smart PIN protection and protected-administrator unlocks.
Account identity
Password hashing and managed users
User records store password hashes rather than readable account passwords. The database uses pgcrypto-backed bcrypt operations for password verification and includes a dedicated password-policy layer.
- Database-driven usernames and account status.
- Hashed password verification rather than plaintext comparison.
- Role, active status and protected-admin state are separate account attributes.
Session boundary
Opaque, revocable application sessions
Successful authentication creates a server-side session record with expiry and revocation state. The client holds an opaque credential while the database retains a hash, avoiding direct storage of the live session token in the session table.
- Expiry and revocation are first-class session fields.
- Logout can revoke the current server session.
- Administrative unlock state is bound to the same active session.
Remember Me
Browser persistence uses AES-GCM
When Remember Me is enabled, the production client encrypts the saved username and session credential using a non-exportable AES-GCM 256-bit key stored through IndexedDB. Without Remember Me, durable credential persistence is deliberately removed.
- Fresh random IV for each encrypted envelope.
- Key material is created by Web Crypto and kept non-exportable.
- Legacy credential storage is explicitly cleared by current code paths.
Authorization
Module and action permissions
Permissions are modeled separately from account identity. The production schema supports view, create, edit, delete, export and import decisions across core finance modules, while the UI also respects team-member and owner context.
- Permission checks can vary by module and action.
- Team context is distinguished from the workspace owner.
- Protected administration is not equivalent to ordinary user access.
Cryptographic control map
Different secrets receive different protection because they have different jobs.
Triplem VIP does not describe every security value as encrypted. Passwords and recovery material that only need verification are hashed. TOTP enrollment must be recoverable by the server for code verification, so that secret is encrypted. Session and guest credentials are represented by server-side hashes while the live bearer value remains with the authorized client.
Account password
bcrypt via pgcryptoVerification against a one-way password hash. Current account views do not expose a readable permanent password.
TOTP secret
AES-256 via pgcryptoThe Authenticator enrollment secret must be available to restricted verification code, so it is encrypted with a server-side wrapping key.
Recovery code
SHA-256 + user bindingOnly the hash is persisted. The supplied recovery code is normalized, bound to the account and compared without storing the readable code.
Smart PIN
Username-bound SHA-256The PIN verification hash is paired with progressive server-side failure counters and timed lockout tiers.
Application session
Opaque bearer + revocationThe browser presents the live credential while the session table tracks a hash, expiry and revocation state.
Visitor chat capability
SHA-256 guest token hashThe public browser receives the guest capability; the database stores its hash with inquiry expiry and usage controls.
Authenticator App 2FA
A second factor that is verified before a session is created.
Triplem VIP uses standards-based TOTP codes from authenticator applications. For accounts that opt in, a correct password alone does not create an application session: the server issues a short-lived challenge and requires a valid Authenticator code or unused recovery code first.
Secret protection
AES-256 encrypted TOTP secrets
Authenticator secrets are encrypted inside PostgreSQL with pgcrypto AES-256 before storage. The wrapping key is generated server-side in a table denied to browser roles, and internal encrypt/decrypt helpers are not exposed as public browser RPCs.
Recovery material
One-time recovery codes are hashed
Recovery codes are generated from cryptographically random bytes and persisted only as SHA-256 hashes bound to the user ID. A successfully used recovery code is marked consumed so it cannot be reused.
Login challenge
Short-lived, revocable verification
The password stage produces a server-side 2FA challenge rather than a live session. Challenge tokens are stored as hashes, expire, track attempts and are invalidated when no longer usable.
Account recovery
2FA-backed password and Smart PIN recovery
When 2FA is enabled, password recovery and Smart PIN recovery can require the Authenticator App or a remaining recovery code. Password reset replaces the bcrypt password hash, revokes existing sessions and clears outstanding login challenges.
Opt-in by design
Existing accounts are not silently enrolled. Authenticator App 2FA remains off until the account owner enables it and confirms a valid TOTP code. Enabling it revokes other existing sessions so those devices must authenticate again through the second factor.
Live Support security
Real-time assistance without making the support surface a public doorway.
Triplem VIP Live Support combines visitor chat, authorized support agents, controlled transfers, transcript tooling, AI assistance and Web Push notifications. The guest and agent sides use different authorization boundaries.
Hashed guest capability
A landing-page visitor receives an ephemeral chat capability token. The raw token is returned to that browser while only its SHA-256 hash is stored server-side, with expiry and message limits attached to the live-chat session.
Agent authorization
Accepting, replying to, ending or transferring a live conversation is guarded by authenticated user context and Live Support assignment. A chat accepted by one representative is protected from being silently taken by an unauthorized account.
Controlled handoff
Transfers use explicit pending, accept and decline states. The receiving representative is validated before ownership changes, while the conversation history remains attached to the same inquiry for continuity.
Transcript continuity
Administrative chat records and transcripts are exposed through guarded support/admin workflows rather than public table access. Delivery and read-state reconciliation keep the support record consistent across the visitor and representative views.
AI-assisted support
The semantic AI layer assists the support experience with contextual guidance and intent handling, while chat routing and privileged actions continue to depend on the application’s server-side authorization model.
Background notification path
Web Push can surface new support activity when permitted by the user’s device. Notification delivery is separate from authority to read or act on the underlying conversation; the application still validates the active account or guest capability.
Authenticated in-app care
Registered businesses and individuals use the signed-in support channel where enabled. Public guest access does not automatically become authority to enter or inspect an authenticated user workspace.
Support never needs core secrets
Normal support does not require disclosure of an existing password, Smart PIN, Authenticator enrollment secret or recovery code. Recovery verifies or replaces credentials through controlled account functions instead.
Consent belongs to the device
The Web Push prompt is remembered locally after it is presented so visitors and signed-in users are not repeatedly interrupted. A visitor can later change the public-page preference from the notification switch, while authenticated users keep a separate device notification control.
Preference boundaries
A device permission and an account preference should not be synchronized the same way.
Triplem VIP keeps browser notification consent local because Web Push subscriptions and browser permissions belong to a specific device. The authenticated workspace theme, by contrast, is a safe account-level presentation preference and can be restored from the existing user settings record on another browser or device.
Device-scoped
Notification preference
The consent prompt is shown once per local browser context and its preference is remembered locally. Users can later change the switch without altering their finance data or another device’s browser permission.
Account-scoped
Workspace theme
The selected theme is stored in the existing account settings JSON through the authenticated settings RPC, then restored after login on another device. Financial records and permissions are not changed.
Database security
The browser is the interface. The database is the enforcement layer.
Triplem VIP uses owner-aware domain records, PostgreSQL row-level security and guarded functions so that hiding a button is never the sole control protecting financial data.
Owner-scoped domain rows
Core finance tables carry an owner context so wallets, expenses, loans, installments, inventory, notes, assets and related records can be resolved against the correct workspace.
Row-level security
Security migrations enable and harden RLS policies across application data, reinforcing access control below the presentation layer.
Guarded privileged functions
Administrative backup, restore, security and storage operations use server-side identity checks before performing privileged work.
Team ownership model
Team members can operate within a company workspace while underlying ownership remains tied to the authorized owner context rather than becoming a second public data copy.
Soft-delete and recovery patterns
Several domain workflows preserve recoverable states or recycle-bin behavior before permanent deletion, reducing accidental loss while keeping explicit destructive actions available.
Controlled backup paths
Administrative exports and imports are implemented as explicit protected flows with table allowlists and restore safeguards rather than arbitrary SQL execution from the browser.
Resilience & continuity
Operational continuity without pretending the browser is a database.
The application includes bounded offline behavior, storage visibility, backup tooling and cleanup controls designed for practical day-to-day reliability.
Constrained local queue
Supported finance writes can be queued locally during connectivity failures. The queue is owner-scoped and stores sanitized fields rather than arbitrary application state.
Sensitive-key exclusion
The offline queue explicitly rejects rows that appear to contain Bitcoin private keys, seed phrases, mnemonics, WIF material or extended private keys.
Retry with backoff
Failed synchronization is retried with bounded exponential delay and jitter. Online, visibility and manual retry events can restart synchronization.
Per-account usage visibility
Admin Storage Management estimates data usage across ledger, expenses, inventory, notes, assets, Bitcoin address records, profile data and uploaded photo assets.
Targeted analytics cleanup
Analytics storage can be measured and cleaned independently. Cleanup operations are scoped to analytics tables instead of touching user financial ledgers.
Backup and restore
Protected administration supports structured backup export and controlled restore. The implementation preserves the current administrative session during restore and strips inappropriate protected flags from imported data.
Bitcoin boundary
Saved addresses and private keys are deliberately different things.
Triplem VIP can generate or import Bitcoin material through WIF, hexadecimal private keys, seed phrases, brain-wallet phrases and watch-only addresses. The sensitive derivation work occurs in the browser.
When a wallet is saved to the application's database, the persisted record contains the public address, label, network and watch-only status. The save payload does not include the WIF, seed phrase or private-key hex. This separation is fundamental to the product's Bitcoin security boundary.
Users can intentionally export wallet PDFs that contain sensitive recovery material. Those files must be treated like physical keys. Anyone who obtains a private key or seed can control the associated Bitcoin independently of Triplem VIP.
WIF / private keyUsed locally for derivation and signing workflows.
BrowserSeed phraseDerived through Web Crypto-compatible client logic.
BrowserPublic addressSaved wallet records retain the public address together with its label, network and watch-only state.
DatabaseWallet PDFA user-requested wallet export can contain recovery secrets and must be protected as sensitive private material.
User custody Sensitive administration
High-privilege actions receive their own security state.
The project separates ordinary sign-in from controls intended for protected administration and sensitive user operations.
Admin Security Key
Session-bound privileged unlock
The admin-security migration stores verification material server-side and creates unlock records tied to the current application session. Logout revokes that unlock relationship.
- Verification occurs on the server side.
- Repeated failures can trigger a timed administrative lockout.
- Protected-admin identity is checked separately from ordinary role labels.
Smart PIN
Progressive server-side lockout and 2FA recovery
Smart PIN protection includes server-managed failure counters and lock tiers. Repeated failed attempts advance through timed lockouts. For 2FA-enabled accounts, recovery can be verified with the Authenticator App or a one-time recovery code without exposing the old PIN.
- Lockout state is shared across devices through the database.
- The lockout table stores counters and timestamps, not plaintext PIN material.
- Accounts without 2FA retain the established protected recovery path.
Temporary access
Administrator-issued one-time recovery password
For users who cannot use 2FA password recovery, the protected Main Admin can verify username, email and mobile number before issuing a high-entropy temporary password. The old password hash is replaced, prior sessions are revoked and the temporary credential expires after 24 hours.
- The previous permanent password is never revealed.
- Temporary access forces a new permanent password before workspace entry.
- 2FA still applies at sign-in when it is enabled on the account.
Analytics & storage observability
Operational visibility is kept distinct from financial records.
The Admin area contains dedicated Analytics and Storage Management surfaces. Their database functions distinguish site-traffic telemetry from owner financial data and expose controlled cleanup rather than broad data deletion.
Sessions & visitsAdmin analytics can summarize visits, unique visitors, page views and interactions.
Device mixTraffic summaries distinguish mobile, tablet and desktop usage.
Traffic sourcesDirect, search, referral, social and campaign sources can be aggregated.
Storage footprintAdmin storage reporting estimates database and uploaded-asset usage by account and module.
Scoped cleanupAnalytics cleanup targets analytics tables only and leaves financial ledgers untouched.
Photo managementAdministrative storage tooling can identify image-heavy accounts and support photo-compression workflows.
Theme-aware chartsStorage charts inherit the active application theme for labels, grids, legends and tooltips.
Admin-only accessStorage and analytics summary functions require administrative context before returning privileged data.
Google Gemini AI assessment
Google Gemini rated Triplem VIP 9/10.
The linked Google Gemini share confirms a 9/10 AI assessment for Triplem VIP based on the product material evaluated in that conversation.
Google Gemini AI
9/10
The linked Google Gemini assessment rates Triplem VIP 9/10.
Open confirmed Gemini assessmentA confirmed Google Gemini AI rating, presented with the right technical context.
The linked Google Gemini share records a 9/10 assessment of Triplem VIP. This is a confirmed AI rating from that Gemini evaluation, while remaining distinct from an independent penetration test, regulatory certification or formal security assurance opinion.
The technical statements on this page are grounded in the current project implementation: authentication and session migrations, owner isolation, security hardening, admin-security controls, offline synchronization, storage management, analytics, backup logic and browser-side Bitcoin workflows.
The source is the linked Google Gemini share. The 9/10 rating is confirmed by that AI assessment and should be read in the context of the product material evaluated there.
Technology surface
A deliberately lightweight web stack with a strong database core.
Triplem VIP avoids a monolithic client framework in the current production structure. Presentation, domain behavior and data access are split across modular browser files and PostgreSQL migrations.
HTML5Semantic application shells, overlays, forms, reports and public product content.
Modular CSSTokenized themes, responsive layouts, glass surfaces and module-specific styling.
JavaScriptUI state, domain interaction, synchronization, charting, exports and Bitcoin tooling.
PostgreSQLUsers, sessions, permissions, finance records, assets, notes, analytics and security state.
SupabaseHosted database access, REST/RPC integration and object storage used by uploaded branding assets.
Web CryptoAES-GCM browser credential protection and cryptographic support for Bitcoin derivation flows.
Chart.jsVisual reporting in the workspace and administrative storage analysis.
Client exportsPDF, JSON, CSV and spreadsheet-oriented workflows support reporting and authorized recovery.
Security FAQ
Precise answers to the questions that matter at the trust boundary.
These answers describe the current production design and deliberately distinguish hashing, encryption, authentication, authorization and user-controlled secrets.
Does Triplem VIP store readable account passwords?
Current account authentication verifies pgcrypto-backed bcrypt hashes. Existing permanent passwords are not returned through normal user or administrator account views. Password recovery replaces the stored hash instead of revealing the old secret.
Why is the TOTP secret encrypted rather than hashed?
The server must reproduce TOTP codes to verify an Authenticator App response, so the enrollment secret must be recoverable by restricted server-side code. It is therefore protected with pgcrypto AES-256 encryption and a server-side wrapping key.
Are recovery codes readable in the database?
No. Recovery codes are normalized, bound to the user ID and stored as SHA-256 hashes. A code that verifies successfully is marked consumed.
What happens after an administrator issues a temporary password?
The previous password hash is replaced, existing sessions are revoked and the temporary credential has an expiry. Normal workspace entry is blocked until the user chooses a new permanent password. Authenticator 2FA still applies when enabled.
Can a public Live Support visitor access a registered user workspace?
No. Visitor chat and authenticated application access are separate boundaries. The guest capability authorizes only the corresponding support conversation, while workspace access still requires the account authentication path.
Why does the notification choice stay local but the theme follows the account?
Notification permission and push subscriptions belong to a browser or device. Theme is only a workspace presentation preference, so it can be stored in authenticated account settings and restored after sign-in elsewhere.
Boundaries & disclosure
Security transparency should explain controls without pretending risk disappears.
No financial application can eliminate risks created by compromised devices, exposed passwords, unsafe exports or disclosure of cryptocurrency secrets. Triplem VIP's controls work best when users preserve their side of the trust boundary.
What Triplem VIP controls
Account and session architecture, database ownership, permission-aware modules, protected administration, Smart PIN lockout state, constrained synchronization, backup structure, storage observability and the separation of saved Bitcoin addresses from browser-held private keys.
What the user must control
Password secrecy, device security, browser integrity, exported backups, downloaded wallet PDFs, seed phrases, WIF/private keys, recovery copies and any third-party system to which data is intentionally exported.
Responsible security communication
If you believe you have identified a security issue, avoid posting sensitive technical details publicly. Use an official Triplem VIP support channel so the report can be evaluated without unnecessarily exposing users or infrastructure.
Architecture reviewed against the supplied production project as of 4 September 2026. This page is a technical transparency document, not a warranty, penetration-test certificate or promise that software can never contain a defect.