Triplem VIP combines hashed account credentials, optional Authenticator App 2FA, protected Smart PIN and recovery, explicit Web Push consent, visitor Live Support and authenticated in-app care while keeping each trust boundary deliberately separate.
Current account authentication separates passwords, sessions, Remember Me persistence and workspace ownership into distinct security controls.
Current password authentication verifies PostgreSQL pgcrypto-backed bcrypt hashes. Password changes replace the stored hash rather than disclosing the old permanent secret.
Application sessions are server-side records with expiry and revocation state. The active browser credential is represented by a server-side hash rather than stored as a readable live token.
When chosen, returning credentials are stored in an AES-GCM encrypted browser envelope using Web Crypto and a non-exportable IndexedDB key.
Financial records remain associated with the authorized account context and database access path instead of becoming public client state.
When enabled, a correct password creates only a short-lived challenge. A valid Authenticator code or unused recovery code is still required before full workspace entry.
The Authenticator enrollment secret is encrypted server-side with pgcrypto because restricted verification code must be able to reproduce TOTP values.
Recovery codes are normalized, bound to the user and stored as SHA-256 hashes rather than readable copies.
2FA login challenges expire and carry attempt controls, reducing the usefulness of a stale challenge token.
A recovery code that verifies successfully is marked consumed so the same value cannot be reused.
Smart PIN protection, 2FA recovery and administrator-issued temporary passwords use separate guarded paths.
Smart PIN verification uses a username-bound SHA-256 hash and server-managed failure counters with progressive lockout tiers. Normal user profile responses do not expose the stored Smart PIN hash.
When 2FA is enabled, supported Smart PIN and password recovery can verify an Authenticator code or an unused recovery code. Where administrator-assisted recovery is needed, an authorized administrator can issue a high-entropy temporary password that replaces the old hash, revokes previous sessions and forces creation of a new permanent password before ordinary workspace entry.
Support can guide a visitor or registered user without requiring disclosure of passwords, Smart PINs, Authenticator secrets or recovery codes.
A visitor support session uses a guest capability rather than pretending the visitor is an authenticated account holder.
Representative actions remain tied to authenticated support context and assignment rules.
Conversation transfers use explicit states while keeping the inquiry history attached to the same support thread.
Registered businesses and individuals can use private in-app support messaging through a separate signed-in support channel where enabled.
Automated guidance can assist product questions while privileged actions remain behind normal authorization boundaries.
Support does not require a permanent password, Smart PIN, Authenticator enrollment secret or recovery code.
Push subscriptions belong to a browser or device, while a visual theme can safely follow an authenticated account across browsers.
The consent prompt is remembered locally after presentation. Users can later change the browser-level notification switch without altering another device.
The selected theme is stored in the existing authenticated account settings and restored after sign-in elsewhere without changing finance records.
The main administrator controls whether the Accounting workspace appears for each user, adding a role-aware boundary around double-entry books, journals, receivables, payables, reconciliation, tax and reports.
Accounting can be turned on for a user whose work requires formal books without exposing the module to every account automatically.
When Accounting access is off, the Accounting tab is not shown for that user and the related permission path remains restricted.
Inside Accounting, posted journals are protected from ordinary editing and the owner can use Books Lock Date to protect finalized periods.
Enabling Accounting does not silently rewrite legacy Expenses, Wallets, Inventory, Assets or Loans into journal entries. The present separation preserves existing user records and workflows while formal Accounting can be introduced deliberately.
Loans, assets, notes and Bitcoin tools remain first-class operational modules and are not removed when Accounting ERP is introduced.
Given, taken, repayments and settlement history.
Read guideAcquisition, income, costs, depreciation, book value and reports.
Read guideSearchable notes and scheduled follow-ups.
Read guideWatch-only, client-side wallet access, history and PDFs.
Read guideThese answers distinguish hashing, encryption, authentication, browser permissions and support access.
No. Current password authentication verifies pgcrypto-backed bcrypt hashes. Recovery replaces the hash rather than revealing the existing permanent password.
The TOTP secret is encrypted server-side with AES-256 and is decrypted only inside restricted verification functions that need it.
The server stores SHA-256 hashes bound to the account rather than readable recovery-code copies. A successfully used code is consumed.
No support workflow requires disclosure of a permanent password, Smart PIN, Authenticator enrollment secret or recovery code.
Browser push subscriptions are device-specific permissions, while a visual theme is an account presentation preference that can be restored after authentication.
The Technical Security & Infrastructure page explains database, session, permission, 2FA, Smart PIN, Live Support, offline and Bitcoin trust boundaries in more detail.
