This document describes the known security boundaries of BAR. Users relying on BAR for genuinely high-sensitivity operations must read and understand these limitations before depending on the application.
What BAR does: BAR overwrites deleted file data with multiple passes (DoD 3-pass for temp files, DoD 7-pass for main files) before unlinking the filesystem entry.
The limitation: Solid-state drives use wear-levelling firmware that transparently remaps write operations to spare flash blocks. When BAR writes overwrite passes to a logical address, the drive may route those writes to different physical flash cells, leaving the original data in cells that are outside the visible address space. These cells are inaccessible via the OS filesystem but may be readable by hardware-level forensic tools with direct NAND access.
Mitigation: Enable full-disk encryption (BitLocker on Windows, VeraCrypt cross-platform, FileVault on macOS). When the encryption key is discarded, all data — including data in worn-out flash cells — becomes cryptographically unreadable regardless of what the storage firmware retained. BAR warns you at first launch when SSD storage is detected.
What this limitation does NOT affect: Files that were always kept encrypted at rest (i.e., every .json metadata file and every encrypted blob BAR creates) are already ciphertext on disk. An attacker who recovers a fragment from flash cells recovers encrypted ciphertext, not plaintext.
What BAR does: In Scorched Earth mode, BAR attempts to delete all Windows Volume Shadow Copies (vssadmin delete shadows /all /quiet). This requires local administrator privileges.
The limitation: If BAR is run as a standard user, the VSS deletion step is skipped and a structured failure report is returned. Shadow copies created before BAR was installed, or by third-party backup software, may persist. Selective and Aggressive wipe modes do not attempt VSS deletion.
Mitigation: Run BAR as administrator when using Scorched Earth mode, or disable System Restore / VSS entirely via Windows settings if your threat model requires it.
What BAR does: File expiration dates and deadman-switch intervals are compared against datetime.now() (local system clock). BAR performs a non-blocking NTP comparison at startup and warns if the clock is skewed by more than 5 minutes.
The limitation: An adversary with local administrator access can set the system clock arbitrarily, preventing time-triggered expirations from firing, or accelerating them. BAR cannot prevent this — any software that depends on the local clock shares this constraint.
Mitigation: NTP synchronisation is the practical control. The NTP check at startup catches accidental drift (the more common failure mode); it does not defeat a determined local admin. For files where timing is critical, prefer access-count limits rather than time-based expiration.
What BAR does: BAR accepts passwords as Python str objects through PySide6 text input widgets. The metadata encryption key derived from the password is immediately stored in a SecureBytes object (memory-locked, canary-guarded, multi-pass zeroed on release).
The limitation: Python str is immutable and managed by the garbage collector. Between the moment the user types a password and the moment the str goes out of scope, the raw characters exist at an unpredictable number of memory addresses. A process dump or memory scanner could find them.
Mitigation: This is a fundamental Python runtime constraint. BAR minimises the window by deriving the key immediately and discarding the string reference. For a complete solution, the password entry widget would need to be implemented in C/C++ with direct memory control — out of scope for a Python application.
What BAR does: When launching an external viewer, BAR writes a decrypted temp file to %TEMP% and registers a cleanup handler that calls SecureFileOperations.secure_delete_file() with DoD 3-pass on exit.
The limitation: If the BAR process is killed hard (SIGKILL, power failure, Blue Screen of Death), the cleanup handler does not run and the temp file remains in plaintext in %TEMP% until the OS temp cleaner removes it. This window may be hours or days depending on OS configuration.
Mitigation: BAR performs a startup scan for orphaned .tmp metadata files and recovers or removes them. For temp files in %TEMP%, the mitigation is full-disk encryption: a temp file that is ciphertext at rest provides no meaningful information even if it persists.
| Level | What is wiped | What is NOT covered |
|---|---|---|
| Selective | Session data, clipboard, screen protection state | Encrypted file blobs, metadata, logs, VSS, temp files |
| Aggressive | All BAR data directories, logs, config | Volume Shadow Copies, temp files in %TEMP%, filesystem journal entries |
| Scorched Earth | Everything above + VSS (if admin) + structured Windows trace removal | Hardware-level flash residue (SSD), NTFS journal, OS event logs, third-party backup snapshots, memory dumps |
No software wipe level protects against an adversary with hardware-level access to flash storage or physical memory chips after the device has been powered on.
The device configuration stores a raw SHA-256 hash for integrity verification. This hash is protected by AES-256-GCM encryption, so it is not directly readable. However, HMAC-SHA256 keyed with the derived device key is the cryptographically correct construction for this purpose. Migration to HMAC will be implemented in v2.1.0. This does not represent an exploitable vulnerability in v2.0.0.
| # | Risk | Severity | Mitigation |
|---|---|---|---|
| 1 | SSD flash residue after overwrite | High | Full-disk encryption |
| 2 | VSS recovery after non-Scorched wipe | High | Admin + Scorched mode / disable VSS |
| 3 | System clock manipulation | Medium | NTP sync; prefer access-count limits |
| 4 | Password briefly in Python heap | Medium | Unavoidable in Python; minimised by immediate key derivation |
| 5 | Crash-path plaintext temp file | Medium | Full-disk encryption |
| 6 | Scorched mode limited without admin | Medium | Run as admin for Scorched Earth |
| 7 | Verification hash (v2.1.0 migration) | Low | Encrypted at rest; not exploitable in v2.0.0 |