0

I'm building a ticketing system which is mobile-first. Which means that people will need to download and register (using phone authentication like WhatsApp) in my app before they can buy tickets either on the web or through the app. The web-platform will be like WhatsApp Web wherein the user has to scan a QR code on the web-browser with his mobile phone before he can buy a ticket.

For the web-platform:

User arrives on the webpage to buy a ticket. He'll have to sign-in by scanning a QR code on the login page with the mobile app. After this, when he decides to buy a certain number of tickets for a concert/event, my Firebase backend will make sure that he cannot buy a large number of tickets(greater than 25) with a simple check on the cloud-side when he requests a ticket block. After successfully specifying the number of tickets, before he's taken to a payment page, he's asked to scan another QR code on the browser to proceed and finally, the payment is done successfully and the respective tickets are added.

For the mobile-devices:

Nothing special here. Just that he'll have to register with his OTP and won't have a 'Sign-out' feature (Much like Whatsapp) in his app. One account also can't hold more than 25 tickets. So, 25 tickets per mobile phone for 1 event will be the check.

Can you think of a way to beat this system and buy more than 25 tickets?

Improve this question
9
  • What does scanning the QR codes do?
    – Limit
    Feb 27 '18 at 15:31
  • Ensures that it is a registered user who is indeed proceeding to book. Much like Whatsapp-Web which asks you to scan in order to verify that you are accessing the appropriate portal from your phone. Basically, once you scan, the webpage will proceed to the next page.
    – Arjun Ram
    Feb 27 '18 at 16:23
  • Your question is very broad, mobile first means there's an API. As a pen tester, i'd be looking at that, i'd be be running packet captures on the mobile device to see how it communicates and i'd be reverse engineering your mobile app to see if i can figure out how your authentication works. Make sure your mobile app is solid and your api auth works properly!
    – iainpb
    Feb 27 '18 at 16:33
  • I'll be using Firebase Phone Authentification with automatic SMS-read capabilities which means the user can't input the OTP. This ensures that the user hasn't input a SIM card which isn't currently loaded on the mobile phone. Is that good enough?
    – Arjun Ram
    Feb 27 '18 at 16:43
  • 1
    If you're using the same phone to register multiple SIM cards, that can be handled in a manner similar to this: faq.whatsapp.com/en/android/27585377/?category=5245246. However, if you're talking about multiple phones and multiple SIM cards, location can perhaps set off red flags but I don't have a concrete answer for that as yet. My intention is to first make it bot proof and after that, human scalpers. Because, bots are the ones that are wreaking havoc on the ticketing industry at the moment.
    – Arjun Ram
    Feb 27 '18 at 17:44
4

Virtually everything you've described is susceptible to a smurf attack. Cell phones are too cheap relative to the profit to be made.

A burner phone costs $40 cash. If tickets cost an average of $100 and I can scalp them for an average of $200, I stand to make $2460 on that $40 investment. For $400 I can buy 10 phones, and make $24,600. (I might have to hire 9 people to help me, but I can do that by offering $100 each for 30 minutes of work.) Plus, I can reuse the phones for the next hot ticket.

If you really want to limit scalping, you can do it the old fashioned way: open a box office, have people stand in line to buy tickets, and don't sell them online. Attackers will ignore you and go for the easy online targets they already know how to exploit. Of course, so will your customers.

EDIT: I'm not saying that there is no way to protect an online environment from attacks; what this is concluding is that cell phones are inadequate sources of unique identities for this problem. I also am not saying there is an easy or even a possible solution. Approaches might include:

  • Find a more effective way to identify your users so you can better enforce the limits.
  • Reduce the per-purchase ticket limit to increase the cost-per-user to the attackers.
  • Raise ticket prices to the point where scalping is too risky to be profitable.

Something else to do is accept that scalping will exist no matter what you do, and explore other ways to offset the problems scalping causes:

  • Offer additional value to official ticket buyers by way of purchase-time-only perks, like access to an exclusive music videos that can only be downloaded from your site within one hour of the ticket purchase. (Think of download/access codes to a site like Vudu or Netflix.)
  • Offer unrelated additional perks with rapidly expiring real-time value, such as a code redeemable for a restaurant meal that has to be used within 24 hours of purchase.

Be ever aware that scalpers will simply hire more smurfs when there is profit to be made. They'll probably resell the restaurant codes, for example, but advertising this would help build resentment against buying scalped tickets, reducing their appeal.

Improve this answer
4
  • So, do you mean to say that there is virtually no way to protect an online environment from such attacks?
    – Arjun Ram
    Feb 28 '18 at 2:12
  • @ArjunRam, I've added some additional info to the answer.
    – John Deters
    Feb 28 '18 at 22:13
  • Another (likely unpopular, potentially slow and impractical to enforce option) is to require the ticket purchaser to be present when allowing entry to the event by providing ID. You can also use this information to correlate across multiple events, looking for outliers.
    – Stephen Touset
    Feb 28 '18 at 23:08
  • Thanks so much for the detailed answer! I've developed a new form of online identity which I'm testing out in very small events/concerts at the moment to make the whole thing more solid. I haven't filed for a patent yet. That's why I just wanted to get a general view of how secure the booking system by itself would be when implemented in this manner. Thanks so much for your time and answers!
    – Arjun Ram
    Mar 1 '18 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.