Identity Leak Check Module (IdentityLeakPage)

1. Overview

The Identity Leak Check module provides user-driven and scheduled monitoring of identity breaches for a specific email address, plus an optional password compromise check using the HIBP Range mechanism (privacy-preserving, no plaintext password transmission).

The UI is implemented as a GTKmm (GTK4) page and integrates multiple internal components:

  • LeakCheckWorker – executes a manual breach check workflow in a background thread
  • LeakMonitor – runs continuous monitoring when enabled (every 24 hours)
  • IdentityLeakConfig – persistent storage for API keys and monitor settings
  • HibpPasswordProvider – performs password compromise checks via HIBP Range

2. User Interface Structure

2.1 Header

The page header follows the standard BastionGuard secure UI style by using a header box with the CSS class secure-headerbar and a centered title label (secure-header-title):

🛡️ Identity breach check

2.2 Email Entry + Privacy Button

The email entry section consists of:

  • emailEntry – input field for the email address to check/monitor
  • Privacy button – opens a non-modal informational popup (showPrivacyPopup())

The privacy popup explicitly documents the privacy model used by the module (API usage, no password upload, partial hash usage for range queries).

2.3 HIBP API Key

HIBP API key management is implemented through:

  • apiKeyEntry – password-style entry (hidden) containing the current key
  • apiToggleButton – toggles visibility (Mostra / Nascondi)
  • saveHibpButton – persists the key via IdentityLeakConfig::setHibpApiKey()

The value is initially loaded from configuration:

apiKeyEntry.set_text(IdentityLeakConfig::hibpApiKey());

2.4 LeakCheck API Key

LeakCheck API key management mirrors the HIBP key workflow:

  • leakCheckApiEntry – hidden entry containing the configured key
  • leakCheckToggleButton – toggles visibility (Mostra / Nascondi)
  • saveLeakCheckButton – persists the key via IdentityLeakConfig::setLeakCheckApiKey()
  • Info button – opens a non-modal disclaimer popup (showLeakCheckDisclaimer())

The disclaimer explicitly states that BastionGuard is not affiliated with LeakCheck and that API results may differ from the official site.

2.5 Password Check (HIBP Range – Free)

The password verification section provides a privacy-preserving check for compromised passwords:

  • passwordEntry – hidden input (never shown by default)
  • checkPasswordButton – triggers the check via HibpPasswordProvider::checkPassword()

Security behavior:

  • No plaintext password is transmitted by design
  • The password field is cleared immediately after the check completes
passwordEntry.set_text("");

2.6 Monitoring Toggle (24h)

The automatic monitor control is exposed through:

  • monitorToggle – a toggle switch labeled Monitor automatico (ogni 24h)

Its initial state is loaded from configuration:

monitorToggle.set_active(IdentityLeakConfig::monitorEnabled());

When toggled, the setting is persisted and the monitor is started/stopped accordingly.

2.7 Manual Check Button

The Verifica violazioni button triggers a breach check workflow. The action is disabled while a check is already running (running guard).

2.8 Log View

The module provides a log console using:

  • Gtk::TextView logView bound to Gtk::TextBuffer logBuffer
  • A scroll container with automatic policy and full vertical expansion

All log updates are scheduled into the GTK main loop for thread safety via:

Glib::signal_idle().connect_once(...)

3. Threading and Workflow

3.1 Manual Breach Check Execution

The breach check is executed in a dedicated worker thread created inside onCheckClicked(). The main steps are:

  1. Stop any currently running monitor (stopMonitor())
  2. Clear the log buffer and log the start event
  3. Instantiate LeakCheckWorker with:
    • The target email
    • A callback that appends log lines to the UI
  4. Execute worker.run()
  5. If monitoring is enabled in configuration, restart the monitor for the same email

All UI writes occur via appendLog(), which is main-thread safe.

3.2 Password Check Execution

The password check uses HibpPasswordProvider::checkPassword() and logs a structured result:

  • If compromised: logs the number of occurrences and recommends an immediate change
  • If not compromised: logs that the password is not present in known datasets
  • On exception: logs the error reason

After completing the check, the password input is cleared to avoid retention in memory/UI.

3.3 Monitoring Lifecycle

The monitoring subsystem is managed through:

  • startMonitor(email)
    • Creates a LeakMonitor instance bound to the email
    • Installs a callback that logs monitor events with prefix [MONITOR]
    • Starts monitoring and marks monitorActive = true
  • stopMonitor()
    • Stops and destroys the monitor instance
    • Marks monitorActive = false

The page destructor calls stopMonitor() and joins the worker thread if still running, ensuring clean shutdown.

4. Privacy and Compliance Popups

4.1 Privacy Popup

showPrivacyPopup() creates a non-modal informational window with BastionGuard styling (app-dialog, main-window, app-window), including a custom header bar and a close icon loaded via:

resource("icon-close.png")

The message communicates the privacy guarantees of the module (no personal data storage, email checks via official APIs, no password transmission, HIBP Range usage).

4.2 LeakCheck Disclaimer Popup

showLeakCheckDisclaimer() displays a non-modal warning stating:

  • BastionGuard is not affiliated with LeakCheck
  • No partnership or implicit approval exists
  • Results may differ from those shown on the official LeakCheck website
  • The user is responsible for API usage

5. Runtime and Security Considerations

  • Thread safety: all UI writes are marshaled to the GTK main loop through Glib::signal_idle().
  • Non-blocking UI: leak checks run in a worker thread; popups are non-modal.
  • Password handling: the password field is cleared after checks to reduce exposure.
  • Monitor exclusivity: a monitor is stopped before manual checks to avoid overlapping workflows.
  • Configuration persistence: API keys and monitor state are stored through IdentityLeakConfig.
Published on:
Last updated on: