Assume Compromise

An association's ledger has to survive the people who are allowed to touch it. It also has to survive the ones who are not. A board member's password gets reused on a site that later leaks it. A laptop is left unlocked at a property manager's desk. A login is phished by a page built to look exactly like the real one. None of this requires a skilled attacker, and all of it happens, eventually, to someone.

I wrote about the first kind of failure in Bare Metal: enforcement moved out of application code and into the database itself, because a rule that only binds the callers who pass through it does not bind a maintainer who never knew it was there. That piece is about the absence of intent — nobody meant to bypass anything. This one is about the opposite case: somebody who wants in, and has a credential, a session, or a console to try it with. The question is not whether that happens. It is what it is worth once it does.

The Wrong Question

Security pages in this category tend to read the same way: a padlock icon, a claim of "military-grade encryption," and a badge from a vendor most visitors have never heard of. None of it answers what happens after someone gets past the login, and that is the more useful question. The honest starting position for a system that holds other people's money is that a login will eventually be gotten past — not through a flaw in the login itself, but through a password that was never CommunityPay's to protect in the first place, reused or phished somewhere else entirely. The design question is what that buys the person holding it.

Past the Password

A password alone is checked against a lockout: five wrong guesses freezes the account for thirty minutes, which is what stops someone trying passwords one at a time rather than using one that already works.

A refused password, an expired session, a page a role cannot reach — each is written to the same audit log as a payment or a bank change, whichever URL it hit. That does not stop an attempt. It means an attempt leaves a record whether it succeeds or not.

Every connection to this platform is also required to be encrypted, and the requirement does not depend on the browser asking nicely: the domain instructs browsers to refuse a plain connection entirely, for two years at a time, including every subdomain, so a downgrade attempt has no plain-HTTP fallback to land on.

Assume the password still works anyway — stolen, phished, reused, it does not matter which. What it produces is a session, and the session is scoped tightly regardless of how the password was obtained. The server keeps the session; the browser holds only an opaque identifier, so there is nothing in the cookie itself to decode or forge. That identifier cannot be read by a script running on the page, is never sent over an unencrypted connection, and lapses after an hour of inactivity or the moment the browser closes, whichever comes first. Every form that changes something — a payment, a bank account on file, or a vendor record — carries a token bound to that session, and a request arriving without the right one is refused. That is what stops a page open in another tab from quietly submitting a request on the victim's behalf: the browser will still attach the session cookie to it, but not the token, because the token was never handed to that page. A password that works is worth one session, in one browser, for at most an hour of silence, behind a form that checks where the request actually came from.

Nothing to Take

A session, however it was obtained, still cannot reach a card number or a bank routing number, because this database has never held one. Payment credentials go directly to Stripe, a PCI DSS Level 1 certified processor — the top tier that certification has — and what comes back to CommunityPay is a token and the last four digits: enough to show someone which account they connected, not enough to move money anywhere else. That holds even for someone who reaches the database directly, a far larger compromise than a stolen password. There is no field to decrypt, because the number was never written to a field.

The Login Worth Stealing

A stolen resident login reaches one household's balance and payment history. A stolen board or treasurer login is worth more, because that role can approve money moving out — which is the case worth working through, since it is the one with a dollar amount attached.

Eighteen guards evaluate every posting before it can commit, described from the enforcement side in Bare Metal; three of them exist for exactly this scenario. vendor_risk refuses a payment to a vendor with an unresolved compliance issue — an expired license, an unresolved debarment — unless someone records a board override with a documented reason. disbursement_compliance enforces the association's own approval thresholds and dual-signature rules before a payment goes out. connect_balance checks the payment against what the association's payment balance can actually fund, and that guard has no override at all: there is nothing for a board to weigh, because the balance either covers the payment or it does not.

That balance is also kept deliberately small. A board sets a target for how much should sit in the association's payment balance above its next vendor payment; the rest sweeps to the association's own bank account every day. The reason for the buffer is ordinary — it smooths the days between dues arriving and a bill coming due — but its effect does not care why the balance happens to be small on a given day. A compromised login trying to move money out is capped by whatever the buffer holds that day, not by how large a payment it is willing to approve. The rest already left, the day before.

The Worst Case

The scenario that matters most is not a stolen password at all. It is someone who reaches the database directly — through a credential with that level of access, a compromised console, or someone on the inside. Bare Metal describes what that access still cannot do quietly: a posting's decision, once it is part of the hash chain, carries the one before it inside it, anchored outside the table it protects, and Bare Metal is specific about exactly where that chain begins. Someone with database-level access can, in principle, alter a chained row. What they cannot do is alter it and leave the chain looking the way it looked before.

This is the same property Bare Metal describes for a careless bypass, aimed here at a deliberate one instead. The mechanism does not ask, and cannot tell, whether the hand that reached the row meant to be there. It answers the same way either time.

What the Patent Covers

Almost everything above this line is ordinary. Locking out a password after five wrong guesses, expiring a session after an hour of silence, routing a bank number to a certified processor instead of a local database column — none of that is new, and none of it is what is actually on file with the USPTO. What is filed is the choke point: a financial fact cannot exist in this ledger without a decision behind it, recorded before the row lands and checked again after, at the database layer rather than the application's. That is the property that changes what a compromised application is worth. In most breach accounts, an unauthorized transaction is a black box — money moved, and reconstructing exactly how depends on logs the intruder may also have been able to alter. A posting with no decision behind it is not a transaction with weak evidence. It is one this ledger cannot hold at all.

What Is Left

None of this makes a break-in impossible. A patient attacker with enough access and enough time can still do damage, and the honest measure of a security design is not what it claims — it is what stays true once the claim fails somewhere. What stays true here is narrower than "secure." A stolen password reaches one account, in one browser, for at most an hour of silence, behind a form that checks its own origin. A stolen high-privilege login reaches one association's payments, capped by whatever the buffer holds that day and refused wherever a board-configured guard applies. A stolen database connection can write, but cannot write without the chain remembering it. None of that is the same as unbreachable. It is what is left over once compromise is assumed instead of hoped against.

Mandatory Enforcement Choke-Point Architecture — non-provisional application filed with the USPTO, April 2026.