Piracy here just means you can use it to sell your ticket without using their platform, which is analogous to just sending someone the PDF or handing over the piece of paper as always.

While this has the upside of breaking you free from TM's obnoxious practices, it also obviously opens up for scalpers and all.

Scalping is still possible without understanding the tech - you could just stream a video of the bar codes and sell the stream instead of selling the ticket.

The whole point of their system isn't to eliminate the possibility entirely it's to make it impractical to get around for the vast majority of concert-goers, and it clearly succeeds at this.

Recording the ticket with a video is everyone's first thought at defeating their restriction, and is no doubt the first thing they thought of when designing it. Hence, the codes expiring too quickly that you'll need a new video before you get through the line at the entrance of the venue. And messing with videos in a pressured line of people in front of a bouncer, is, as others have said, simply not practical for the vast majority of cases.

So it's kind of irrelevant - practically speaking - that it is possible.

Good luck getting enough signal to play a video stream in a large crowd.

You don't need to truly stream a video capture of the app, you can have a scanner on the server side decode the barcode in the web/virtualized Android app and then only stream a couple hundred bytes, having the client regenerate the barcode

Sure, it's possible, but come on, it's not practical.

Well, it wasn't practical before this blog post.

Piracy here means that you can sell 50k tickets to the same seat with a real valid rotating barcode.

Are you sure you understood the article? The token is supposed to be a secret and the TOTP generation should happen remotely. This is not the case and this suggest a fundamental lack of security practices at the company.

"Should happen remotely" – according to who? What is the security risk for the end-user?

"this suggest a fundamental lack of security practices at the company" – that's a stretch of a conclusion to make. You're being as hyperbolic as the original post.

What didn't I understand about the article? This still offers a slight increase in security over static barcodes, without introducing any new vulnerabilities.

> This still offers a slight increase in security over static barcodes, without introducing any new vulnerabilities

It offers nothing to the user, except taking away their rights, and making it all unreliable

> the TOTP generation should happen remotely.

It says that it is available offline (if you've viewed it in the last 20 hours), so the TOTP generation can't happen remotely

Well it's more like the "security: they want is fundamentally is incompatible with support for ofline use in this case (as long as we have open computing platforms anyway).

Which would increase the problem he described--too many people trying to get in overloading the local bandwidth.

It's enough to defeat screenshotting and the 20 hour bit would defeat large scale malicious use.

Not good security but probably good enough, especially in stopping the resale of stolen tickets.

It's piracy in a way that's analogous to ripping like Netflix content. You are breaking away from DRM which is piracy. They also cite the potential to have multiple tokens valid per one ticket which would let multiple people get in with the same ticket.

I doubt the second bit is true - they will still be marking the ticket as used in their backend.

They are just trying to prevent scalpers printing off tickets 10 times and selling them outside the venues as a scam, which happened at every large concert I have ever been to until recently (so I assume this is working!).

You would hope... But they often run the scanners in offline mode (e.g. at temporary / seasonal events) so there can be lag in the backends being updated.

Heard from a friend who got straight into two events in the same city recently - they presumed the show was at one outdoor venue but the scanners let them straight in at the first (wrong) venue. Went to the correct venue and got in there without any issue too (this suggests one or both venues were offline or using offline scanners).

Hm. So I guess at a small venue that has 3 door people with offline scanners, you have a 2/3 chance of success if you're the second of two people sharing a barcode. Combined with the obvious 3/3 success being the first person, that averages out to 5/6 chance if both of you (oblivious to each other) schedule your arrival similarly.

My experience from visiting many many of them is that 80-90% of small venues don’t even bother with scanners.

not really offline but someone who works in industry here once detailed out that each scanner has it's own copy of a SQLite database that is being updated as fast as possible based on inserts of other scanners since any downtime is a big deal at these venues

i.e., theoretically duplicate tickets would be identified but not instantly but still pretty quickly

> they will still be marking the ticket as used in their backend.

I assume that's true, but it makes me wonder how their scanners are connected to the server.

I mean, if 10,000 people showing up to an event with smartphones overwhelms wireless networks, wont that also kick their scanners off the network?

They'd probably like to have a system where, if a scanner loses its connection, it can still validate tickets. It could store a copy of validated tickets locally, and upload it when the network connection is restored - that would mean a copied ticket would have to make sure they go to a different door/scanner. But it would allow copying.

Simplest answer is a private wifi network for the scanners.

It's also the best answer.

It's all off-the-shelf electronics and standard protocols. Venue provides some wifi with a "Ticketbastard" SSID (or whatever) at entry points, and the COTS-built barcode-validating devices use that. Easy-peasy.

They might also provide other wireless networks for other purposes (definitely for vendors [$$$], but perhaps also for regular house staff, touring staff, and maybe even the guests who pay for it all!), but they'll all be under the venue's control and coordination: Other than the odd personal hotspot that wanders in, there's not necessarily any meaningful outside interference on 2.4/5GHz wifi bands in a big venue.

It's pretty easy to make short-range wifi work reliably in that kind of RF environment, such as the chokepoints where tickets are validated. (Modern apartment dwellers will have worse interference problems than that.)

There’s actually a ton of interference in the 2.4 GHz space, especially at venues like outdoor festivals. However your solution does work. I work at a festival that provides a WiFi network and an Ethernet drop for the ticket scanners. We have to use multiple APs to cover the main entrance area, but it’s feasible.

I was thinking more along the lines of a stadium crowd than an outdoor festival, but yes: I agree. I've had miserable luck with 2.4GHz stuff in festival environments where people camp out for a few days. :)

I don't pay very much attention to the ticket-scanning devices while I'm getting into a big show (which is generally a rather unpleasant experience on my side), but:

Don't they allow usage of 5GHz bands? Unlike 2.4GHz, I've had tremendous success with 5GHz bands in all kinds of environments -- including outdoor festivals.

I have no idea what connectivity options are available in current scanners, but it sounds like a viable solution could be to use an RF band that customers don't overwhelm, similar to wireless microphones perhaps, with a little hub situated nearby that consolidates the list of already-scanned tickets, possibly standalone or possibly on a wired network that includes other far-away entrances.

Was going to say it shouldn't be hard to run a wire around an entire stadium, but maybe some popup outdoor venues that might be complicated. Could use line of sight towers for fun.

900mhz networks like halow or even lorawan should do

Even at huge venues i dont expect requests would be over 5 rps

5 RPS, per scanner, surely?

No way, scanning tickets is slow because it rarely works seamlessly. It's pretty standard to stand there for a few seconds moving your phone back and forth and/or rotating it. Or when one person has all the tickets for their party and has to scroll to the next one between scans.

I think maybe 4-15 seconds between scans per scanner, at best.

Can you imagine 5 people moving thru scanner in 1 second?

Even at 1 rps that's if we assume 1 meter distance that's 3.6 km/h or a normal walking pace. Do you ever see crowd at ticketing move at walking pace?

Not at all, I was imagining over speccing the system.

E.g. this weekend I went to a show at a 70,000 seat arena. Knowing from experience, there are 4 entrances. This time there were 10 people scanning tickets at the gates I entered. Friends reported the same at the one they came in.

5 RPS per scanner is obviously overkill, but if those 10 at one gate were linked to a hub that could issue 5 RPS I would call that adequate, if barely.

If all 4 gate areas were linked centrally to a system that could do 5 RPS, well, actually, that might explain the throughput I experienced getting through lol

I'd argue that a few extra people sneaking in on the same ticket (assuming this is even possible) is more like sharing your Netflix credentials than ripping Netflix content and having it be shareable with the entire world.

You're also walking into a stadium/concert in plain view of security cameras, so the stakes and deniability are different as well.

Not a lawyer, but "subverting DRM" (even if it's trivial or really stupidly designed) can be a crime in and of itself in the US under the DMCA. There are a bunch of exceptions to this, so I have no idea if OP's work is actually illegal.

Security researchers are an exception, but the title of "security researcher" is undefined

Now this is f*cked up, isn't it?

It would be DRM if the barcode was copyrighted material, which it isn't.

The way this is already being exploited in the wild is that a scalper/scammer buys 1 ticket, then resells the same ticket multiple times. Multiple people believe they have a valid ticket, show up at the event, but only the 1st ticket works. The other people who try to use the ticket are turned away saying that their ticket has already been used.

> The way this is already being exploited in the wild is that a scalper/scammer buys 1 ticket, then resells the same ticket multiple times. Multiple people believe they have a valid ticket, show up at the event, but only the 1st ticket works. The other people who try to use the ticket are turned away saying that their ticket has already been used.

That is one of many ways this is already exploited in the wild.

Do you have a source for this? What platform are they selling multiple copies of the ticket through, and what app are the buyers using that allows multiple buyers to receive and show the same animated barcode?

This way you can sell and have the ticket completely off of ticketmaster. That is a vulnerability. It lets users do something they explicitly don't want to allow.

Assuming that you can actually do that.

If the seller re-opens the TM app and it generates a new token and invalidates the old one, then that's not the case.

Vulnerability to LN business practices. Not a system vulnerability.

He was basically wondering if he could create two tickets each with different tokens. Tokens are valid for 20 hours but it probably doesn’t invalidate the old token (e.g. a request for a new token makes it to the internet but due to congestion, the response never comes back to your phone before timing out) and this could trigger multiple tokens for the same ticket and are all valid.

Thank you for posting this. This article left me super unsatisfied too.