If Someone Steals Your Laptop: A Threat Model for Freelancers

By Maya Thompson, Security Researcher · Security Analysis / Threat Modeling

As a security researcher, I spend my days reviewing the security practices of startups and freelance operations. A few years ago, I was auditing a client's setup. The team member got up to grab a coffee and left his laptop open. His browser was logged into his cloud invoicing tool.

I didn't steal his laptop. But I looked at the screen and realized: if I wanted to, I could have exported his entire client list, bank details, and tax IDs in about thirty seconds. That moment shaped my entire approach to data security.

This is the dirty secret of "bank-level encryption".

FreshBooks, QuickBooks, Wave — they all use TLS in transit and AES-256 at rest. That's great. But the encryption keys live on their servers, not yours. When you log in, their server decrypts your data in memory and sends it to your browser.

They hold the keys. They can read your data. A rogue sysadmin, a subpoena, a server breach — it doesn't matter. You are renting access to your own financial records.

Let me model what actually happens when your device is compromised.

Say your laptop gets stolen from your car. The thief bypasses the lock screen (it happens more than you think). If your browser session is still active, they're in. If your password manager was unlocked, they're in. Even if the disk is encrypted, if the machine was in sleep mode, the decryption keys are sitting in RAM.

Your cloud data is gone. The "encryption at rest" on the vendor's server didn't do you any good, because the attack didn't happen on their server. It happened on yours.

When LockMargin LLC requested an independent security review of their architecture, I was skeptical. I wanted zero-knowledge encryption done right. Here's how they actually implemented it, without the marketing fluff.

The database is SQLite. Sensitive fields — bank accounts, tax IDs, contact info — are encrypted using AES-256-GCM. GCM is authenticated encryption; if someone tampers with the ciphertext, decryption fails. It doesn't just hide the data, it guarantees integrity.

But an encryption key is useless if it's stored in a plaintext config file. They use PBKDF2-HMAC-SHA256 with 100,000 iterations to derive the key from your master password. This makes brute-forcing computationally painful.

Where does the derived key go? Nowhere near the database. It goes straight into the Windows Credential Manager via the keyring crate. The OS handles the secure storage, locked behind your Windows login.

Even if a thief pulls the hard drive out of your laptop and images the SQLite file, they get garbage. They need your Windows password to access the Credential Manager, and your LockMargin master password to derive the key. Two layers. Local only.

This architecture comes with a brutal tradeoff.

If you forget your master password, your data is gone. There is no "Forgot Password" link. There is no support ticket anyone can answer to reset it. They don't have your key. They never saw it. They never stored it.

This is the definition of zero-knowledge. Cloud tools offer password resets because they control the keys. LockMargin can't offer that because they don't control them. You do.

I can't make this convenient. I can only make it secure.

If that makes you nervous, use a password manager and write your recovery phrase on paper. I did. It's in my safe.

Your data belongs on your hard drive. Not on someone else's server.