DEV Community: Malik B. Parker

Bypassing 2FA in Web Scraping: Why iMessage is a Local SQL Database and How That Changes Everything

Malik B. Parker — Mon, 16 Mar 2026 23:46:07 +0000

The Problem

Two-factor authentication kills web scraping. Every automated login flow hits a wall when the site says "we just sent you a code." Traditional approaches fall into two camps:

Email-based: Spin up an IMAP listener, poll for the email, parse the code. Requires an LLM or regex to extract from HTML emails. Adds 10-30 seconds of latency and another API call.
Authenticator apps (TOTP): Easy if you have the secret key. Most credential managers expose TOTP generation. But many sites only offer SMS or email — no TOTP option.

SMS is the worst of both worlds. You'd think you need a Twilio number, a webhook endpoint, some cloud infrastructure to receive and parse incoming texts. Or you do what most people do: give up and mark the site as "can't automate."

But if you're running on a Mac with iMessage, there's a third option that's almost embarrassingly simple.

iMessage is Just a SQLite Database

Here's the thing nobody talks about: every iMessage and SMS message that syncs to your Mac is stored in a plain SQLite database at:

~/Library/Messages/chat.db

That's it. No API. No authentication. No webhook. Just a .db file sitting on your filesystem. You can open it with sqlite3 right now and query your entire message history:

SELECT m.text, h.id as sender, m.date
FROM message m
JOIN handle h ON m.handle_id = h.ROWID
WHERE m.is_from_me = 0
ORDER BY m.date DESC
LIMIT 5;

When a 2FA SMS arrives on your phone, iMessage syncs it to your Mac within seconds. It lands in chat.db as a new row. No polling an external service, no waiting for email delivery, no parsing HTML. Just a SQL query.

The Architecture Decision: Why macOS?

When I was building Bill Analyzer — an agent-based bill scraper that logs into utility company portals, handles authentication, and extracts billing data — I made a deliberate choice to target macOS as the runtime environment. Here's why:

The scraping stack already assumes a desktop environment. We're using Playwright with a visible Chromium instance (stealth mode, anti-detection). This isn't a headless cloud scraper — it's a local automation tool that needs to handle complex SPAs, Angular dashboards, and JavaScript-heavy login flows. A Mac with a display is already the natural home for this.

iMessage gives you SMS 2FA for free. If you have an iPhone paired with your Mac, every SMS verification code lands in chat.db within 2-5 seconds. No infrastructure needed. No third-party services. No API keys.

The credential pipeline stays local. We pull credentials from 1Password via the op CLI, fill them directly into the browser via Playwright (the agent never sees them), and now SMS codes flow through the same local-only pipeline. Nothing leaves the machine.

How the SMS Tool Works

The implementation is ~100 lines of Python. Here's the flow:

1. Baseline Snapshot (Before Login)

Before the agent starts clicking anything, we capture the ROWID of the most recent message in chat.db:

def _get_latest_message_rowid() -> int:
    conn = sqlite3.connect(CHAT_DB)
    row = conn.execute("SELECT MAX(ROWID) FROM message").fetchone()
    conn.close()
    return row[0] or 0

This is our baseline. Any message with a ROWID higher than this arrived after we started the session.

2. Agent Triggers SMS

The agent navigates the 2FA page — clicks "Send via text," clicks "Send Code." These are normal click actions, recorded for replay caching just like any other step.

3. Poll for the Code

When the agent calls fill_sms_code, we poll chat.db for new messages:

def _get_sms_code_after(after_rowid, sender, code_pattern):
    conn = sqlite3.connect(CHAT_DB)
    cursor = conn.execute("""
        SELECT m.text, h.id as sender_id
        FROM message m
        JOIN handle h ON m.handle_id = h.ROWID
        WHERE m.ROWID > ?
          AND h.id LIKE ?
          AND m.is_from_me = 0
        ORDER BY m.date DESC
        LIMIT 5
    """, (after_rowid, f"%{sender}%"))

    for row in cursor:
        match = re.search(code_pattern, row["text"])
        if match:
            return match.group(1), row["sender_id"]
    return None

We poll every 2 seconds, up to 60 seconds. In practice, the code arrives in 3-5 seconds.

4. Fill and Continue

The code gets filled directly into the verification input via Playwright. The agent never sees the code value — it flows opaquely, just like credentials. The tool records a FillSmsCodeStep with the discovered sender number for replay caching.

The Race Condition Problem

The naive approach has a subtle race condition. The timeline looks like this:

Agent clicks "Send Code"
SMS is dispatched by the 2FA service
Agent processes the click result, decides to call fill_sms_code
fill_sms_code starts polling

The code might arrive at step 2, before the poll starts at step 4. If you use a timestamp-based filter ("only messages from the last 5 seconds"), you'll miss it.

The ROWID approach eliminates this. We snapshot the highest ROWID before the agent starts any actions — before step 1. Any message arriving after that point, whether at step 2, 3, or 4, will have a higher ROWID. We catch it regardless of when the poll starts.

The only remaining edge case: what if the SMS arrives before the baseline snapshot? This would mean the SMS arrived before we even started the login flow — which doesn't happen in practice. But as a safety net, we could subtract a small buffer from the baseline ROWID if needed.

Staying PII-Safe

A key design constraint: the agent should never see sensitive data. The SMS tool follows the same opaque pattern as credential filling:

fill_secure_credential: Fetches username/password from 1Password, fills directly into the page. Agent sees only "Filled 'password' into #password."
fill_sms_code: Reads the code from iMessage, fills directly into the page. Agent sees only "Filled SMS verification code into #verificationCode."

The code value exists only in the tool's execution scope. It never enters the LLM context. The recorded cache step stores only the sender number and selector — never the code itself.

For page content, everything the agent sees goes through Presidio PII redaction. Names, addresses, account numbers, SSNs, phone numbers — all replaced with placeholders. Dollar amounts and dates are preserved because those are the extraction targets.

Replay: Zero-LLM 2FA on Subsequent Runs

The first run uses an LLM agent to navigate the login flow. Every action is recorded:

{"action": "click", "selector": "#chooseText"},
{"action": "click", "selector": "#sendCodeButton"},
{"action": "fill_sms_code", "selector": "#verificationCode", "sender": "69525"},
{"action": "click", "selector": "#continueButton"}

On subsequent runs, the replay engine executes these steps with pure Playwright — no LLM. When it hits the fill_sms_code step, it polls iMessage using the cached sender number. The only wait is for the SMS to arrive (~3-5 seconds).

Total replay cost: $0.00 in LLM calls. The entire login + 2FA + extraction happens with Playwright + SQLite + regex.

What Makes This Work

The approach works because of a few converging factors:

iMessage is a local database. Apple doesn't expose an API for reading messages programmatically, but they don't need to — the data is right there in SQLite. Full Disk Access permission is the only gate.
SMS 2FA codes are predictable. They're always 4-8 digit numbers in a short text message. A simple \b(\d{4,8})\b regex catches them reliably.
The sender is consistent. PECO always sends from 69525. Once discovered on the first run, we cache it and filter by sender on replay — no false positives from other messages.
ROWID is monotonically increasing. SQLite ROWIDs are sequential. This gives us a reliable "messages after this point" filter without dealing with timestamp formats, timezone issues, or Apple's nanosecond epoch offset.

Limitations

macOS only. This requires a Mac with iMessage syncing enabled. No Linux, no cloud VMs (unless you're running macOS VMs, which has its own licensing implications).
Full Disk Access required. The terminal or Python process needs FDA permission to read chat.db. This is a one-time system preference toggle.
SMS sync latency. iMessage typically syncs within 2-5 seconds, but network conditions or iCloud delays could extend this. The 60-second polling timeout handles edge cases.
Not all 2FA is SMS. Sites that only offer email or authenticator apps need different approaches. Email could use a similar local technique with Mail.app's database, but that's a future project.

The Bigger Picture

The real insight here isn't about iMessage specifically — it's about treating local system databases as APIs. Your Mac is full of SQLite databases that applications use for storage: Messages, Safari history, Contacts, Notes, Calendar. When you need data from these apps programmatically, you don't need to build integrations or scrape UIs. You just query the database.

For automated web scraping that needs to handle 2FA, this collapses what would normally be a complex infrastructure problem (SMS webhook service, message parsing, code extraction) into five lines of SQL and a polling loop.

This is part of an ongoing series on building agent-based web scrapers with PII safety. Previously: PII Redaction for AI Pipelines.

How to Strip Sensitive Data Before It Hits Your LLM

Malik B. Parker — Sun, 15 Mar 2026 16:46:50 +0000

You built an AI agent that logs into your bank, navigates to billing, and extracts your bill amount. Smart. But now Claude is reading your full name, home address, account numbers, and partial SSN — all sent through an API you don't control. That's not a pipeline. That's a liability.

Here's how I solved it with four regex patterns and an open-source library most people have never heard of.

The Context

I'm building Bill Analyzer — an agentic system that automatically logs into utility and financial sites, navigates to billing pages, and extracts what I owe and when it's due. It uses:

Playwright for browser automation
Claude (Haiku) as the AI agent for navigation and extraction
1Password CLI for credential management

The architecture has two phases:

Login Agent — navigates login flows with credentials handled opaquely (the agent never sees passwords)
Extract Agent — reads post-login pages to find billing data

The extract agent needs to read the page to find dollar amounts and due dates. But those pages also contain names, addresses, SSNs, account numbers — PII that has no business being sent to any external API.

The constraint: the agent must understand the page well enough to extract billing data, without ever seeing personal information.

Why This Matters Beyond My Project

Any time you're feeding real user data into an LLM — customer support transcripts, medical records, financial documents, scraped web content — you face the same problem. The model needs the structure and relevant content, not the identity.

This isn't just good practice. Depending on your industry, it's GDPR, HIPAA, or CCPA compliance.

The Tool: Microsoft Presidio

Presidio is Microsoft's open-source PII detection and anonymization library. It combines:

spaCy NER (Named Entity Recognition) for names and locations
Pattern-based recognizers (regex) for structured PII like SSNs, phone numbers, credit cards
Custom recognizers you can add for domain-specific patterns

Install:

pip install presidio-analyzer presidio-anonymizer
python -m spacy download en_core_web_lg

Basic usage:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

text = "John Smith, (555) 123-4567, john@example.com"
results = analyzer.analyze(text=text, language="en")
redacted = anonymizer.anonymize(text=text, analyzer_results=results)

print(redacted.text)
# <PERSON>, <PHONE_NUMBER>, <EMAIL_ADDRESS>

What Presidio Catches Out of the Box

Entity	Example	Method
`PERSON`	John Smith	spaCy NER
`PHONE_NUMBER`	(555) 123-4567	Regex
`EMAIL_ADDRESS`	john@example.com	Regex
`CREDIT_CARD`	4532-1234-5678-9012	Regex + Luhn
`US_SSN`	123-45-6789	Regex
`US_BANK_NUMBER`	4829184729	Regex
`LOCATION`	Springfield (city names only)	spaCy NER

What It Misses: Street Addresses

This is where I hit a wall. Presidio's LOCATION entity catches city names sometimes, but full street addresses? Completely invisible:

IN:  John Smith, 123 Main St Springfield IL 62701, Balance: $142.37
OUT: <PERSON>, 123 Main St Springfield IL 62701, Balance: $142.37
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                Address passes through unredacted

Bare addresses are even worse:

IN:  3498 Ebenezer Ave
OUT: 3498 Ebenezer Ave    ← completely missed

For a billing extraction pipeline, this is unacceptable. Your home address is on every utility bill page.

The Fix: Four Custom Regex Patterns

US street addresses follow predictable patterns. I built a custom PatternRecognizer with four patterns, ordered from most specific (highest confidence) to least:

from presidio_analyzer import Pattern, PatternRecognizer

US_STATES = (
    "AL|AK|AZ|AR|CA|CO|CT|DE|FL|GA|HI|ID|IL|IN|IA|KS|KY|LA|ME|MD|"
    "MA|MI|MN|MS|MO|MT|NE|NV|NH|NJ|NM|NY|NC|ND|OH|OK|OR|PA|RI|SC|"
    "SD|TN|TX|UT|VT|VA|WA|WV|WI|WY|DC"
)

STREET_SUFFIXES = (
    r"St(?:reet)?|Ave(?:nue)?|Blvd|Boulevard|Rd|Road|Dr(?:ive)?|"
    r"Ln|Lane|Way|Ct|Court|Pl(?:ace)?|Cir(?:cle)?|Pkwy|Parkway|"
    r"Ter(?:race)?|Hwy|Highway|Loop|Run|Path|Trail"
)

address_recognizer = PatternRecognizer(
    supported_entity="ADDRESS",
    patterns=[
        # 1. Full: "123 Main St, Apt 2, Springfield, IL 62701"
        Pattern(
            "us_address_full",
            rf"\d{{1,5}}\s+[\w\s.]+?(?:{STREET_SUFFIXES})\b"
            rf"[,.\s]+(?:[\w\s#.,]+[,.\s]+)?"
            rf"(?:{US_STATES})\s+\d{{5}}(?:-\d{{4}})?",
            0.85,
        ),
        # 2. With state: "123 Main St, Springfield, IL"
        Pattern(
            "us_address_state",
            rf"\d{{1,5}}\s+[\w\s.]+?(?:{STREET_SUFFIXES})\b"
            rf"[,.\s]+(?:[\w\s#.,]+[,.\s]+)?"
            rf"(?:{US_STATES})\b",
            0.7,
        ),
        # 3. With ZIP: "123 Main St 62701"
        Pattern(
            "us_address_zip",
            rf"\d{{1,5}}\s+[\w\s.]+?(?:{STREET_SUFFIXES})\b"
            rf"[,.\s]+[\w\s.,#]+\d{{5}}(?:-\d{{4}})?",
            0.6,
        ),
        # 4. Bare: "3498 Ebenezer Ave" or "789 Elm Dr, Apt 4"
        Pattern(
            "us_address_street_only",
            rf"\d{{1,5}}\s+[\w\s.]+?(?:{STREET_SUFFIXES})\b"
            rf"(?:[,.\s]+(?:Apt|Suite|Ste|Unit|#)\s*[\w-]+)?",
            0.4,
        ),
    ],
    context=[
        "address", "street", "mailing", "billing",
        "home", "residence", "service"
    ],
)

analyzer = AnalyzerEngine()
analyzer.registry.add_recognizer(address_recognizer)

How the patterns work

All four share a common prefix:

\d{1,5}\s+[\w\s.]+?(?:STREET_SUFFIXES)\b
│          │              │
│          │              └─ Street suffix (St, Ave, Blvd...)
│          └─ Street name (lazy match)
└─ House number (1-5 digits)

Key regex decisions:

Lazy +? on the street name prevents overmatching into surrounding text. Without this, 123 Main St Springfield IL 62701, Balance: $142.37 matches all the way through $142.37.
Word boundary \b after the suffix prevents partial matches like "Driveways" matching Drive.
Context words ("address", "billing", "mailing") boost confidence for borderline matches — a bare 3498 Ebenezer Ave at 0.4 confidence gets boosted when near the word "address".

The Results

IN:  3498 Ebenezer Ave
OUT: <ADDRESS>

IN:  123 Main St
OUT: <ADDRESS>

IN:  789 Elm Drive, Apt 4
OUT: <ADDRESS>

IN:  Service address: 3498 Ebenezer Ave. Your balance is $142.37
OUT: Service address: <ADDRESS>. Your balance is $142.37

IN:  John Smith, 123 Main St Springfield IL 62701, Balance: $142.37
OUT: <PERSON>, <ADDRESS>, Balance: $142.37

IN:  Jane Doe, 456 Oak Avenue, Apt 2B, Chicago, IL 60601, Amount: $98.50
OUT: <PERSON>, <ADDRESS>, Amount: $98.50

IN:  789 Broadway New York NY 10003, Phone: (555) 123-4567
OUT: <ADDRESS>, Phone: <PHONE_NUMBER>

IN:  1234 W Elm Blvd, Suite 100, Los Angeles CA 90001
OUT: <ADDRESS>

IN:  55 Park Dr, Unit 3, Denver CO 80202. Your bill is $75.00 due May 1.
OUT: <ADDRESS>. Your bill is $75.00 due May 1.

IN:  Your bill of $200.00 is due May 1. No address here.
OUT: Your bill of $200.00 is due May 1. No address here.

Every address caught. Every dollar amount and date preserved. No false positives on non-address text.

What Survives Redaction (By Design)

The whole point is that the LLM still gets what it needs:

$142.37 — the bill amount (not PII)
April 15, 2026 — the due date (not PII)
Balance Due: — structural labels (not PII)
<PERSON> — the agent knows a name was there without knowing whose

The redacted text preserves enough structure for the AI to do its job while stripping everything that identifies the person.

Known Limitations

PO Box addresses (PO Box 1234, Springfield, IL) — not covered, would need another pattern
International addresses — US only; other countries need separate recognizers
No-suffix streets (123 Broadway works, 123 Maple does not)
Account numbers — Presidio sometimes tags these as PHONE_NUMBER due to digit patterns; close enough for redaction purposes

The Bigger Picture

PII redaction isn't just about regex. It's an architectural decision. In my pipeline:

Login phase — the agent never sees credentials (opaque tool fills them, snapshots redact filled fields)
Navigation phase — the agent sees only links and buttons, not page content
Extraction phase — the agent sees Presidio-redacted text (this article)

Three layers of privacy enforcement. The LLM is powerful but sandboxed. It can read a page without knowing who you are.

If you're building any pipeline that sends real-world data through an LLM, ask yourself: does the model actually need to see the PII to do its job? Usually the answer is no.

DEV Community: Malik B. Parker

Bypassing 2FA in Web Scraping: Why iMessage is a Local SQL Database and How That Changes Everything

The Problem

iMessage is Just a SQLite Database

The Architecture Decision: Why macOS?

How the SMS Tool Works

1. Baseline Snapshot (Before Login)

2. Agent Triggers SMS

3. Poll for the Code

4. Fill and Continue

The Race Condition Problem

Staying PII-Safe

Replay: Zero-LLM 2FA on Subsequent Runs

What Makes This Work

Limitations

The Bigger Picture

How to Strip Sensitive Data Before It Hits Your LLM

The Context

Why This Matters Beyond My Project

The Tool: Microsoft Presidio

What Presidio Catches Out of the Box

What It Misses: Street Addresses

The Fix: Four Custom Regex Patterns

How the patterns work

The Results

What Survives Redaction (By Design)

Known Limitations

The Bigger Picture

Resources