Month: May 2026

NFTs for ticketing: when scarcity matters

Often the first application of a technology turns out to be its worst proving grounds. During the 2021 crypto craze, NFTs have achieved dubious notoriety as one of the more inane use-cases of blockchains. Pixelated images of primates trading for outsize sums invited comparisons to the Dutch tulip mania. Once prices crashed many of the so-called “collectors” were left holding the bag as schadenfreude spread in other quarters. As difficult as it may be to suggest resurrecting NFTs with a straight face today, there is a good case to be made for ticketing. This application has not been tried on any commercial scale outside of limited trials. More importantly recent landmark litigation officially labeling Ticketmaster a monopoly may finally provide an opening for new entrants in an otherwise concentrated industry.

Solid foundations: fungibility and on-chain tokenization

Sometimes the first application of a technology an industry gets wrapped around the axle on turns out not to be the optimal one. (See QR codes before the pandemic, secure-elements on mobile devices for NFC payments…) The original enthusiasm around NFTs for digital art follows that pattern. Before NFTs, there were FTs— fungible tokens, without the leading negative. As one of the earliest standards building on Ethereum, these had already proven useful in the issuance of secondary assets on the Ethereum blockchain, especially those intended to mirror an existing fiat currency such as the US dollar. Tether and Circle already boasted billions of dollar-equivalent stablecoins as ERC-20 fungible tokens in circulation before the pandemic. With the passage of the GENIUS act officially recognizing and regulating stablecoin issuers, these tokens are ever more tightly coupled with the traditional financial system, much to the chagrin of cryptocurrency detractors.

Stablecoins are meant to be fungible in the same way cash is: a dollar bill in paper currency has no unique properties to differentiate it from another bill. That also holds for bars of gold or shares of stock. But there are other types of assets where this is not true: real-estate is an example. If there are two adjacent houses in some suburban planned community with cookie-cutter construction that are identical in every aspect including their selling, the titles for those houses are still not interchangeable. The buyer of the house on the left can not legally move into the one on the right by arguing they are indistinguishable. Non-fungible tokens standardized by ERC-721 took the next logical step for tokenization— mirroring real-world assets on-chain— by introducing a variant of ERC-20 intended for one-of-a-kind objects. There is nothing fundamentally unsound about this step. It still requires the present of a trusted third-party to enforce the correspondence between on-chain representation and real world possession, but this is no different than stablecoins. One USDC stablecoin is accepted as a substitute for one traditional dollar on DeFi markets because of the belief that Circle— the company issuing USDC— is willing and able to exchange the virtual dollars for real ones in a bank account. That belief is not enforced by any consensus rules of Ethereum: it requires positing the existence of those dreaded trusted-third parties that blockchains were supposed to eliminate. Putting aside the irony, it is clear that network participants have been willing to make that leap of faith— even in the presence of evidence suggesting the stablecoin issuer has less-than-stellar reputation. Once that level of confidence exists, it is only an incremental jump to believe that some other trusted third-party can also enforce the connection between real-world property ownership and their virtual representations on chain.

Nonexistent scarcity

It was not the failure of a trusted-third party that resulted in the first NFT gold-rush turning into an easily ridiculed tulip-bulb craze. (At least, not a failure in the traditional sense of failing at their primary responsibility: maintain the correspondence between the real-world and its on-chain reflections. Investigative journalists have uncovered plenty of cases of digital art purveyors acting with less than stellar ethical standards in marketing and price-manipulation.) The fundamental problem with encapsulating public digital art in an NFT is that by definition such art has no scarcity. There is exactly one authentic instance of The Birth of Venus. It is located at the Uffizi. Laying eyes on the original involves a non-virtual trip to Florence. Any one can create a copy of that original, complete with the appearance of age by using paint and materials approximating their 15th century equivalents. Those copies are decidedly not interchangeable with the original. An art museum could conceivably create an exhibition out of replica paintings to spare visitors the inconvenience of having to travel to Italy. But no one could mistake that for actually seeing the real thing by Botticelli, any more than walking down the Las Vegas strip qualifies as having “visited” the pyramids, the Eiffel Tower and the Statue of Liberty all in the same day because simulacrums of these objects have been recreated there.1

What the proponents of digital-art-as-NFT have struggled to articulate is the answer to the question: what distinguishes one copy of the image from another? When anyone can visit the same web-page to view the exact same image— pixel for pixel identical to what all other viewers are observing— what benefit does “ownership” of the associated NFT exactly confer? It is not even bragging rights about patronage of the arts or demonstrating refined personal aesthetic, even if one takes the cynical view of modern art as a Veblen good. Having an original Picasso on the wall creates an experience that is not available to anyone else not in possession of that specific artwork, for example being able to admire said painting while having dinner with friends. If the painting is later sold, that experience is no longer available. What benefit accrues to the present “owner” of a digital-art NFT that is not accessible to anyone else who accesses the same image and downloads it locally?

Artificial scarcity

When there is no intrinsic scarcity, producers are motivated to artificially prop-up prices by creating the appearance of scarcity. This is why new mints of NFTs must be carefully controlled in quantity: there is no reason a batch of NFTs could not feature a million variations on the same theme, but justifying sky-high valuations is (relatively) easier when the marketing collateral can drum up FOMO by predicting the “limited run” will sell out in a matter of hours.

Other NFT projects attempted to sidestep this problem in a creative fashion: make-up new benefits exclusively available to holders of their NFT line. For example, events where attendance is conditioned on current ownership of a BAYC. While this type of red-velvet-rope treatment certainly creates a distinction between the NFT-haves and have-nots, it raises a question on what digital artworks have anything to do with the benefits. Why not simply auction off attendance rights to the event directly? Having a low-resolution simian image attached to the on-chain representation of that right does not appear to add any value, certainly not one to justify the large difference in price based on the exact characteristics of the same image.

Ticketing

That brings us to the pedestrian business of event ticketing, back in the headlines briefly after a federal jury in New York officially branded Ticketmaster/LiveNation an illegal monopoly. It is unclear whether any structural remedies will follow from this decision but there is a fighting chance that new entrants may be able to challenge this incumbent monopoly now operating under the watchful eye of regulators. Ticketing turns out to be a much better fit for NFTs for several reasons:

  1. Real scarcity. There are only so many seats at Madison Square Garden and so many calendar days in a year when Bruce Springsteen can perform. This is the ultimate constraint event promoters must contend with, even if they are constantly trying to create additional scarcity to squeeze even more profit. (Why are there only 100 “VIP packages” that come with mass-produced souvenir schlock when one could just as well have made 1000 copies? Why is that benefit a function of seating close to the stage when it could have been decoupled from location and made available to all fans even in the nosebleed sections?)
  2. Unsolved trust problem. It is difficult to resell tickets in a peer-to-peer manner without a centralized platform to coordinate the transactions. Direct sales between individuals would be rife with fraud because the recipient can not verify the authenticity of what they are paying for. Anyone can create a PDF or even print a piece of paper that looks like a valid ticket to a highly-coveted World Series game. But can a seller convince prospective buyers that this piece of paper is authentic? Even if it is authentic, what if they had already “sold” the same ticket to multiple people already? (This is the real-life version of the double-spend problem that bitcoin has solved elegantly.) In economics this type of information asymmetry between buyers & sellers is known to result in an inefficient dynamic called “the market for lemons” inspired by the used-car sales dynamic. Buyers artificially discount the price they are willing to pay for a car when there is a significant chance it will turn out to be a lemon worth much less than the asking price— a condition that only the seller has visibility into. This is the problem SeatGeek, Stubhub and other online market places for ticket resales solve for. It allows buyers to transfer the risk: they will be made whole for the occasional counterfeit ticket purchased from the platform, a guarantee that does not exist when directly transacting with the seller.
  3. Lack of transparency in secondary-markets. While Stubhub and its ilk have built lucrative businesses around this risk-transference model, consumers are worse off from a pricing perspective. These secondary markets thrive on opacity: while a buyer may know exactly which seat they are paying for— and thanks to federally mandated all-in pricing, how much the platform is earning in fees— they have no clue about the original face value of that ticket, much less its resale history. Is this a professional scalper charging triple price for a random batch of tickets they purchased mechanically using a bot? Or die-hard fan trying to recoup the cost of their tickets after some unforeseen life-event derails their plan to watch their favorite artist live? The distinction matters even when we acknowledge the supply/demand dynamics: artists often deliberately underpricing tickets for good-will result in a secondary market closer to fair value. Opacity props up the demand side: knowing that they are about to get ripped off by a seller demanding a ridiculous multiple of the face-value is likely to influence how much one is willing to bid. (Of course Ticketmaster and Stubhub have zero incentive to “fix” that problem and make the market more efficient: buyers getting ripped-off is good for business when the revenue depends on collecting a fraction of the sale price.)

What NFTs can and can not solve

Looking at each of the structural problems with the market, NFTs obviously can not solve the intrinsic scarcity problem: minting more NFTs on-chain does not create more seats in the stadium. Virtual tickets can only mirror this scarcity. But they solve for the trust problem in a very robust, cryptographic manner, far better than what paper tickets or animated QR codes can achieve. It would be trivial to check that a given address is the official holder of a particular NFT. Since each NFT is associated with a URL, it is also possible to look up exactly what that NFT corresponds to in real life: attendance rights for a specific seat at a particular event. Crucially that URL may hold the piece of information Ticketmaster and its ilk desperately strive to withhold from consumers: the original face-value. With some standardization around how tickets are encoded, it becomes possible to index inventory on-chain and track distribution in real-time.

To be clear: there is still a trusted third-party involved— the issuer of the NFT must be authoritative for real-world allocation of those tickets. They are in a position comparable to stablecoin issuers: they guarantee interchangeability between the virtual construct on-chain and the real life privilege of sitting at that seat. Initially this role may well end up being the same Ticketmaster/LiveNation monopoly, resulting in no structural market change for primary sales. (Just because tickets can be issued on-chain does not mean the Boss will throw away all existing distribution channels and farm out this crucial side of the music business to random upstarts.)

But the existence of tickets in NFT format could drastically reshape the secondary sale market. It is no longer necessary to have Stubhub sitting in the middle of every transaction to guarantee the authenticity of tickets, or more accurately, to refund buyers in case those tickets turn out to be counterfeit. This lowers the barriers to entry for creating true peer-to-peer marketplaces, including potentially ones operating entirely on-chain. Just as decentralized exchanges allow trading cryptocurrencies directly with a smart-contract, a decentralized ticket resale platform can enable buyers to bid on inventory. Interestingly none of the usual criticisms of DeFi platforms—that they are too slow, too expensive per transaction and susceptible to front-running compared to centralized exchanges— apply to this scenario. On-chain transaction fees are significant for an automated strategy executing thousands of trades with gains/losses are measured in cents. That is not how ticket resales work; hedge-funds are not built around high-frequency trading of tickets. If anything, introducing additional friction to handicap professional scalpers is arguably a feature. It is not possible to arbitrage across different markets: there is no “hedging” one’s exposure to holding Bruce Springsteen tickets by “shorting” Taylor Swift tickets for a different date.

Limits of transparency

For all these advantages, there is still no guarantee that NFTs can bring about full transparency or efficiency around secondary-sales. There are two reasons, one that is fundamental to all unregulated peer-to-peer sales and one contingent on the exact structure of these hypothetical marketplaces that emerge.

The intrinsic limitation is around the possibility of manipulating prices with bogus sales. Seller Alice can collude with her friend Bob to “sell” her ticket at an artificially inflated price, paying Bob under the table for his costs. (If all activity is taking place online, there is no need for Bob the co-conspirator: Alice can just create a second wallet address to bid on her own listings. This is the standard practice for artificial pump-and-dump schemes.) Bob can then list the ticket himself or hand it back to Alice: rinse and repeat. Or if Alice has a batch of tickets in the same row, inflating the price of one may now justify a higher price for the others. No money has exchanged hands and no meaningful economic activity has taken place here. But this fraudulent transaction distorted the price signal, by creating the appearance of those tickets being worth more than their fair market value. In regulated markets this type of activity is strictly illegal; the market operator is tasked by law with surveilling their platform and reporting on questionable trading patterns. Ticketing already plagued by a class of professional bottom-feeding scalpers, is unlikely to merit any significant scrutiny around market integrity.

The second limitation is a function of how much transparency the new platforms choose. Even today there is no reason that Ticketmaster could not disclose the entire transaction history associated with a ticket: issued at this face value, resold on such date for a second price, that buyer then turning around to sell it again later for a different price. To the extent that such prices are known to platforms, they are not surfaced publicly. It is possible that no single platform has necessary visibility to reconstruct that timeline: in a competitive marketplace, each resale could have taken place on a different service, each one jealously guarding its internal hoard of transactions. In reality, given the highly concentrated oligopoly that exists today, chances are a single ticket spends its entire lifetime within the confines of the same platform. The challenge is not lack of information; incentives favor keeping consumers in the dark. Those exact incentives operate even when tickets are represented as NFTs: while the object being traded exists on-chain, the transaction itself can still take place off-chain on a garden-variety website. This is very similar to how NFT sales were often conducted: buyers escrow their NFT with the platform, buyer pays the platform which arranges for transfer. While the blockchain will record the change of ownership, there is no guarantee that it will also reflect exactly how much money changed hands in the other direction. Such transparency is more likely if the platform operates entirely on-chain and each NFT transfer is accompanied by some other visible record of cryptocurrency movement in the other direction.2

CP

1 In fairness, the Vegas simulacrums are not identical in dimensions or construction to the real object either.

2 It would be possible to hide the payment using smart-contracts if buyer and seller can agree on a specific condition to be enforced by the contract for releasing the NFT. This is not quite the same as outright price manipulation. It can be rational for both parties if the seller is trying to save face and move inventory without signaling declining prices to the broader market.

Reckoning with address reuse: the post-quantum challenge for Bitcoin

Backed into a corner

Blockchains are confronting the challenge of quantum computing with renewed urgency as more researchers continue to sound the alarm. Denial is giving way to anger and bargaining. As the first and largest cryptocurrency, Bitcoin has always benefited from a certain immunity against criticism over its original design decisions and selection of features— or lack thereof, as critics frame it: rudimentary scripting language and stubborn refusal to accept even simple improvements that restore pre-existing functionality. Defenders see the intransigence and allegiance to 2008-vintage design as a virtue: sound money must be resistant to fads, very difficult to change except by near unanimous consensus of the community. Constantly hard-forking to jump on the latest smart-contract bandwagon or implementing the most fashionable signature algorithm of the day is the last thing users need. In the extreme, this becomes a version of the originalism doctrine from US jurisprudence: every contentious question is adjudicated by deference to historical pronouncements from Satoshi.

The specter of cryptographically relevant quantum computers (CRQC) is bringing some of those ancient design relics back into sharp relief. If the engineering challenges around quantum computers are overcome anywhere as quickly as optimists are predicting, the security guarantees of Bitcoin and virtually every other cryptocurrency will be immediately undermined. That often-repeated self-custody mantra “your keys, your coins” starts to ring hollow when a quantum computer can turn your keys into their keys. This is the problem every blockchain must contend with. There are some incremental solutions such as minimizing address reuse. These are not realistic, for reasons discussed in following sections. There is widespread agreement on principle that the only long-term defense against CRQC is the adoption of new signature algorithms purpose-built to resist known quantum capabilities. The engineering challenge is deciding which one— or which options, if one fully embraces cryptographic agility and giving users an option among multiple competing algorithms— and exactly how these new capabilities will be phased into an unruly system with no formal governance model. The challenge for Bitcoin is that all options on the table pose the same problem: signatures or public-keys will take up significantly more space on chain, cutting into already scarce limits for the number of transactions that can be accommodated in each block. It turns out one of those original design assumptions will greatly aggravate that problem.

Address reuse in the original vision

To explain how 2008-era decisions have backed Bitcoin into a corner today, it is helpful to highlight one aspect of the original design. Satoshi expected that addresses would only be used once. This also implies underlying cryptographic keys are also not reused, since there was a strict one-to-one mapping between them originally.1 Every Bitcoin wallet could generate an unbounded list of new addresses from a single “seed” secret. Each time the owner of that wallet needs to receive funds, they generate a fresh address with no previous history on-chain. That would be true even when sending funds back to oneself, as part of the so-called “change output.” If Alice has an unspent output of 10 bitcoins and needs to send Bob 1 bitcoin, the remaining 9 bitcoins would be sent back to a brand-new address Alice controls, not the original source address where the funds originated.

It was privacy and not the distant threat of quantum computers that underpinned this original avoidance of address reuse. CRQC remained very much in the realm of academic research during the 2000s when core ideas underlying Bitcoin were brewing in the cypherpunk community. Regardless of the motivation, some key decisions followed from this assumption:

  • Every transaction input is signed independently. If there are 10 inputs, there must be 10 signatures. It would not make sense to have a single signature authenticating multiple inputs, since they are all going to be coming from different addresses controlled by different keys. (In theory there is another, more advanced optimization possible: called “signature aggregation,” it allows combining multiple signatures into a single signature that is in turn verified against a combination of public-keys. But this is not supported by the consensus layer either.)
  • Each signature must be accompanied by the associated public key, since there is no other way to verify whether that address is controlled by that key. Later this would extend to revealing the full redeem script, which may include multiple public keys in the case of multisig. Again this makes sense if addresses are never reused. That specific public-key or redeem script has never appeared on-chain before, so it is not possible to refer back to a previous occurrence or waste space on storing that for future use, since that address will never appear in a future transaction again.

Address reuse in reality

In actual usage of Bitcoin, it turns out address reuse has become the norm. It is not some exceptional case of opsec failure. In fact later blockchains even made a virtue of address stability. For example, Ethereum and Solana group funds by address, not by chunks of coins (“UTXO” for “unspent transaction output”) as with Bitcoin. There are good reasons for this:

1. Enforcing transaction policy. The easiest way to lose control of assets on a blockchain is key compromise— when the threat actor gets hold of the private key. A close second is when the legitimate owner is tricked into wielding that private key to sign the “wrong” transaction: one that sends funds to the threat actor instead of the intended recipient. The difference between a right and wrong transaction comes down to a handful of factors, with the most significant one being the destination address. When addresses are stable, it is easy to determine whether a given address is friend or foe. Given a list of known addresses for every potential recipient, including other wallets belonging to oneself, it becomes trivial to determine what the effect of a transaction will be: how much funds are being sent to another party, how much is returned back to the sender as “change” and what fees are paid to miners for the privilege of transacting.

This concept of address whitelisting is now table-stakes for custodial services: users commit to a list of known safe addresses ahead of time and the system does not allow transfers outside of that set. (Of course there has to be some way of adding new entries to the list, and that process is made deliberately high-friction, for example by requiring out-of-band authentication or mandatory 7-day waiting period. The threat model is that even if an attacker can impersonate the legitimate customer or attempts to coerce them into executing a transfer, they can not succeed.)

2. Proof-of-reserves. In PoR a custodial service proves to its customers that they have control of all digital assets entrusted to its safekeeping. This involves two pieces:

  • Proof of liabilities: committing to the BTC balance of every customer in a verifiable manner, including the total balance across the entire customer base
  • Proof of assets: proving that the custodian controls an amount of BTC on the blockchain that is equal or greater than the liabilities.

For all practical purposes, this second step requires not only disclosing addresses but proving that the custodian still has possession of the private keys associated with that address by signing with them. While there have research proposals for doing semi-private proof-of-assets by mixing in an additional “cover” set of addresses to obfuscate the ones controlled by the custodian, it turns out the privacy improvements are limited. A satisfactory proof also requires keeping funds at the existing addresses over which the proof was conducted. If one were to conduct the PoR by moving all funds to new addresses, it would leave open the question of whether the custodian accidentally moved funds to some address they can not control, until the next PoR demonstration when they can be moved again.2

Signature bloat

As noted, the Bitcoin transaction signing format lacks any optimizations to reduce the cost of signing multiple inputs with the same public key. This is hardly noticeable when using ECDSA because both signatures and public-keys are short: public-keys take up 33 bytes with point compression while signatures are around ~70 bytes depending on encoding.

That calculus changes with post-quantum signatures. All of the algorithms standardized as part of the NIST post-quantum cryptography effort have either large signatures, large public-keys or both. NIST Signature Zoo provides a convenient way to compare these schemes, including an option to sort by total size of public-key plus signature. That is the relevant metric for Bitcoin’s existing design where every input is signed independently and contains the full public-key. Among algorithms standardized by NIST so far, the “winner” according to that criteria is ML-DSA. At 3723 bytes for one signature and public-key, it still represents a almost 40-fold expansion in space required— and that is at the lowest acceptable security level by NIST standards. Slightly more promising is Falcon/NTRU scheme, currently pending standardization. It would reduce that overhead to ~1600 bytes, a meaningful improvement over ML-DSA but far from the status quo.

Hash-based signature schemes such as SLH-DSA fare much worse on this metric. Their public-keys are qiute compact— effectively the size of one classical hash— but signatures run into multiple kilobytes. In a world where address reuse is common, this is exactly the wrong trade-off: a public-key can be “cached” on chain to amortize the storage cost of a public-key, but every transaction must still be signed independently. Note these figures assume funds are controlled by a single key: the overhead gets worse when starting to compare more complex configurations such as multi-signature schemes where all possible public-keys must be included in the signature script. 3

Reckoning with address reuse

For Bitcoin to achieve post-quantum security without further degradation of its throughput, there are two paths forward:

  1. Double-down on the hope that address reuse can be eliminated or at least strictly bounded. If one assume only a limited number of transactions are permitted out of each address, there are purpose-built stateful hash-based “few-time” signature algorithms that are more compact than the general NIST-sanctioned stateless hash-based signatures. The trade-off is a highly brittle security model: if the number of transactions is exceeded or state is mismanaged (for example, restoring from a backup resulting in reuse of previously “spent” private-key) the result is a catastrophic failure.
  2. Accept that address reuse is going to be the norm and implement difficult protocol changes to optimize for block space given the demands of post-quantum signatures. This will likely involve a hard-fork to improve transaction verification:
  • Cache redeem scripts in unpruned UTXO, to avoid outputting the same public-key over and over again
  • Allow one signature to cover multiple inputs. This could involve consolidating inputs when they share a redeem script or supporting signature aggregation across inputs. Aggregation is a more generic, powerful technique: it works across messages signed with different keys. But it is also highly dependent on the choice of signature algorithm; not every scheme lends itself to efficient aggregation. Having a “batched” signature cover multiple inputs is more straightforward from a cryptographic perspective as it does not depend on the mathematical structure of the algorithm. On the other hand, it is more complex for interoperability with Bitcoin script, since the spending conditions encumbering an input may include additional logical constraints in addition to a signature check.

CP

1 Interestingly that is no longer true: with the introduction of Bitcoin script, it is possible to generate infinite variants of a script that effectively expresses a spending condition involving the same key. Each of those variants would result in a unique address that looks independent, until the script is revealed at the time of spend.

2 Interestingly the proof-of-reserves requirement also complicates attempts to defend against quantum computers by hiding public-keys until they are spent.

3 Incidentally this discussion ignores speed of signing and verification. As things stand, the Bitcoin blockchain can only sustain a handful of transactions per second. One modern, low-end embedded device can handily out-sign and out-verify the entire network, even with the increased computational requirements of post-quantum algorithms.

Mix-and-match: risks of serial two-factor authentication

Here is a case study from a financial institution that implemented “two-factor authentication” for remote access. Our setting is the type of old-school, on-premise, Windows shop that is nearing extinction: fixed workstations managed through Active Directory, which would have felt right at home in the 1990s along with the Macarena. In a rare concession to the novel idea of employees having to access their work PC while they are not physically in the office (credit COVID for this modern epiphany) the IT department has rolled out a VPN and enabled remote-desktop access. In order to access their assigned workstations, employees jump through two layers of access control:

  1. First, they connect to the corporate VPN, authenticating with their AD domain credentials (username + password) augmented by TOTP two-factor authentication
  2. Once on the VPN, they can use one of the standard remote-desktop clients to connect to their specific workstation, again authenticating with domain credentials.

When this enterprise is going through their ritualistic yearly review of IT controls, an auditor is very likely to ask:

“Does remote access to internal systems require multi-factor authentication?”

Based on the above description, one expects this IT department to confidently respond in the affirmative and the auditors to quickly rubber-stamp that answer after cursory validation.  The subtle flaw in this model— common to legacy systems where second factor authentication has been bolted-on to satisfy some compliance requirement without much consideration for the relevant threat model— is likely to escape notice.

Mix-and-match authentication

The core issue is a disconnect between the two different authentication steps performed in series. There is no consistency check verifying whether the user connected to the VPN is the same one connecting to a specific workstation. In other words, one can connect to the VPN as Alice using Alice’s domain password & OTP credentials, then login to Bob’s workstation using Bob’s domain password. While that may look like an edge case, it points to an intrinsic weakness: once an attacker can fully impersonate any account (second factor included) every other account is only protected by a password alone.

From the threat actor perspective: if the objective is getting access to the documents on the CEO’s workstation, it is not necessary to compromise the CEO’s second-factor authentication. Instead this “mix-and-match” combination is sufficient:

  • Password + 2FA for any random employee
  • Password for the CEO

Does this qualify as two-factor authentication? Under a charitable interpretation, the answer is yes: the attacker still has to satisfy 2FA for some employee. Under a more strict interpretation, it falls short of the intended security guarantee: they did not have to defeat the 2FA associated with the CEO account. Viewed in terms of probabilities, the situation looks much better for the attacker: in a company with thousands of employees, there is a good chance some employee will get phished for both factors or have their device compromised by malware. (At which point, even phishing-resistant authentication is useless; the threat actor can ride the active session once the legitimate user completes authentication using as many convoluted steps as necessary– tapping the hardware security dongle, connecting their smart-card or performing an interpretive dance.)

Mitigations

As with most security challenges, correctly enforcing multi-factor authentication is more challenging than bolting on the half-baked version. There are a few options here, ranging from window-dressing to fully robust:

  • Alerting after the fact: correlate VPN events against remote desktop access events. This will not prevent mix-and-match authentication but it can detect unauthorized access after the fact. Depending on the latency of aggregating logs, detecting anomalies and the maturity level of incident response for the enterprise, there is a fighting chance the breach can be contained before significant damage is done.
  • Enforce two-factor authentication on endpoints. Third-party offerings such as Duo Authentication for Windows Logon allow enforcing MFA as part of the remote-desktop logon, where the presence of the second factor counts the most. (Depending on what is accessible once on the VPN, one could even argue the original design had it completely backwards: if the only thing employees can do is access their own workstation over RDP, they would have been better off with a single-factor VPN while saving the proper MFA enforcement at the endpoint.)
  • Implement proper two-factor authentication at Active Directory layer. This is the most comprehensive solution, based on a little-known fact: AD has supported phishing-resistant two-factor authentication with cryptographic hardware for 20+ years— long before consumer-grade/watered-down FIDO & its ilk existed. Based on the standardized PKINIT extension to Kerberos and smart-cards, this is widely used in high-security environments including the US government CAC & PIV programs. Realistically, the complexity of operating a PKI and issuing smart-cards places this far outside the meager capabilities of most IT departments likely to exist within the confines of a traditional financial institution.

CP