Locked, Hidden and Sent: Passwords, Encryption and Email Analysis

What you'll be able to do

By the end of this lesson you will be able to explain how investigators deal with locked, encrypted and emailed evidence.

• Describe brute-force, dictionary and rainbow-table attacks, and why salting and slow hashing defeat the easy ones.
• Explain why modern encryption is usually opened with keys rather than broken.
• Read an email header to trace a message's route and check its authentication results.

Password Cracking, Under Legal Authority

The book describes password cracking as decrypting or bypassing password protection to access locked devices or files, under proper legal authority. It names three techniques:

• Brute force: trying every possible combination. Guaranteed to succeed eventually, but the time grows enormously with each extra character.
• Dictionary attacks: trying common words, phrases and previously leaked passwords first, because people choose predictable passwords.
• Rainbow tables: large precomputed tables that map hash values back to passwords, so a stored password hash can be looked up quickly instead of guessed.

Why these work, or do not, comes down to how systems store passwords. Lesson 2.1 explained hashing. A well-built system stores a salted hash: a random value (the salt) unique to each password is mixed in before hashing. Because every salt is different, precomputed rainbow tables are useless against salted hashes. Modern systems also use deliberately slow password-hashing algorithms, which make each guess expensive. Guidance such as OWASP's Password Storage Cheat Sheet recommends exactly these defenses. So in practice, recovery succeeds mainly against weak passwords, unsalted or fast hashes, and older systems.

Devices add another layer. An iPhone, for example, imposes escalating delays after wrong passcodes and can erase itself after ten failures if the owner has turned that on (Lesson 1.3 warned about guessing). The passcode check is protected by dedicated security hardware, which limits how fast anyone can guess.

Encryption and Decryption

The book's encryption technique is to decrypt data that users or attackers encrypted to hide its contents: using decryption keys or cryptographic methods, analyzing the encryption method used, and applying the right tools.

The modern reality: strong, correctly used encryption, such as the AES-based full-disk encryption in Windows BitLocker, is not broken by brute force in practice. Investigators get in through the key:

• Recovery keys. Microsoft documents that Windows device encryption backs up the recovery key to the user's Microsoft account, Microsoft Entra ID or Active Directory, depending on how the device is managed. Those records can be requested through proper legal process.
• Memory. A running, unlocked system holds keys in RAM (Lessons 2.4 and 3.4).
• Weak passwords. If the protection depends on a password, the password may be guessable.
• The law. In some countries a person can be required to provide a key. In the United Kingdom, for example, Part III of the Regulation of Investigatory Powers Act 2000 allows this in specified circumstances.

Email and Communication Analysis

The book's email techniques are analyzing headers to track the origin and route of messages, and recovering deleted or hidden email content with forensic tools. Every email carries a header that most programs hide; Gmail calls it Show original, and other programs have equivalents.

Here is a simplified, fictional header. All the names, domains and addresses use ranges reserved for examples:

Received: from mx.example.net (mx.example.net [198.51.100.25])
        by mail.lawfirm.example; Tue, 9 Jun 2026 07:42:18 +0000
Received: from [203.0.113.45] (unknown [203.0.113.45])
        by mx.example.net; Tue, 9 Jun 2026 07:42:15 +0000
Authentication-Results: mail.lawfirm.example;
        spf=pass; dkim=pass; dmarc=pass
        (domain checked: lawfirm-payments.example)
From: "Managing Partner" <partner@lawfirm-payments.example>
Reply-To: partner@lawfirm-payments.example
To: accounts@lawfirm.example
Date: Tue, 9 Jun 2026 07:42:10 +0000
Subject: Urgent: approve transfer today
Message-ID: <a81f2c@lawfirm-payments.example>

How to read it:

• Read the Received lines from the bottom up. Each server adds a line at the top as it passes the message on, so the lowest line is closest to the sender. Here the message entered at mx.example.net from 203.0.113.45. A sender can insert fake Received lines below the real ones, so trust begins at the first server you control; lines below it are leads to check against that server's logs.
• The From line can be anything the sender typed. The display name says "Managing Partner", but the address is at lawfirm-payments.example, a look-alike of the real firm's domain.
• Authentication results test the domain, not honesty. SPF, DKIM and DMARC passed, but for the look-alike domain the attacker controls. A pass shows the message really came from that domain, not that the domain is trustworthy.
• Times and IDs connect evidence. The Message-ID and timestamps let you match this message to server logs and to copies in other mailboxes.

Real-World Example

Imagine (a fictional scenario) the law firm whose accounts team received the email above. The examiner preserves the original message with its full header, and the mail server's logs. The header shows the look-alike domain and a sending IP address from a hosting provider. The server logs show the same message reached three staff members. The firm's lawyers use legal process to ask the hosting provider about 203.0.113.45. The examiner's report states the facts: the message came from a domain that imitates the firm, passed authentication for that domain, and was sent from a specific server. It does not claim to know who the attacker is. An IP address identifies a connection, not a person.

From the Book to 2026

What the book teaches. Password cracking (brute force, dictionaries, rainbow tables) under legal authority; decrypting data with keys and cryptographic methods; analyzing email headers and recovering deleted email.

Why it made sense. All three remain standard techniques.

What has changed. The balance has moved toward keys and defenses. Salted, slow password hashing makes rainbow tables ineffective against well-built systems. Hardware-protected devices limit the speed of guessing. Strong full-disk encryption is turned on by default on many devices, so access depends on recovery keys, memory or lawful disclosure rather than on cracking. DMARC also moved onto the IETF Standards Track as RFC 9989 in May 2026, replacing the informational RFC 7489. But look-alike domains can pass authentication perfectly, so examiners must check which domain passed.

What to do now. Think key first: where could the key or recovery key lawfully be obtained? Preserve emails in their original format with full headers, and never judge a message by its display name or by a "pass" result alone.

Watch: How NOT to Store Passwords

This Computerphile video explains how systems should, and should not, store passwords. It is the defensive side of password cracking.

Questions to keep in mind as you watch:

• Why is storing passwords in plain text, or with a simple fast hash, so dangerous?
• How does adding a salt change what an attacker can do with precomputed tables?
• What does this mean for an investigator trying to recover a password lawfully from a well-built system?

The video complements what you just read. The lesson is complete without it. For an optional walk-through of email header analysis, see the further-study link on this lesson.

What Would You Do?

An accounts clerk forwards you a suspicious payment request "as an attachment" and also pastes its text into a chat message for you. A colleague says the pasted text is enough to investigate. What do you need, and why? Decide, then compare with the model answer in the note below.

Knowledge Check

Key Takeaways

• Brute force, dictionaries and rainbow tables recover weak or poorly stored passwords; salting and slow hashing defeat the easy routes. Use them only under legal authority.
• Strong modern encryption is opened with keys (recovery keys, memory, lawful disclosure), not broken.
• Read email headers bottom-up. Display names can be faked, and authentication passes prove the domain, not the sender's honesty.
• Preserve original messages with full headers. IP addresses identify connections, not people.

Sources

• Dr. Tahseen Al-Doori — IT Forensics Essentials: Concepts, Tools, and the Practice of Digital Investigation, Chapter 5 (e, f, h)
• OWASP — Password Storage Cheat Sheet
• Apple Platform Security — Passcodes and passwords
• Microsoft Learn — BitLocker overview: device encryption and recovery key backup
• UK legislation — Regulation of Investigatory Powers Act 2000, Part III
• Google Gmail Help — Trace an email with its full headers
• IETF — RFC 5322: Internet Message Format
• IETF — RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (May 2026)