55

A few days ago I purchased a single ticket from Cologne (Köln) to Aachen via the DB Navigator app. The ticket was valid for 6 hours after the purchase, however a timer started from 00:00 and stopped at 02:00 as seen on the image below.

What is the purpose of this timer?

deutsche bahn ticket

P.S. I returned to Cologne with a different ticket, the same timer appeared again.

  • 2
    Makes me wonder if you have 2 minutes to stop the sale, after commiting? – Willeke May 4 at 20:05
  • @Willeke There was a button "Edit Order", it looked active both before and after the timer expired. I haven't tried, but your guess might be a case. – ahmedus May 4 at 20:16
  • @Willeke: AFAIK unfortunately, no. – cbeleites May 4 at 22:30
  • 1
    This timer is not specific to Deutsche Bahn app, you can see it in (almost) every app of local transport companies too. – Neusser May 4 at 22:48
  • 3
    Or cheap, sufficient enough solution when looking at what the attack vector is. If you use local transit, and you look at the people who would cheat and not buying tickets, honestly the majority of them will most likely not know how to hack a mobile app. – dunni May 5 at 16:40
101

According to this link (only in German), it is to check if you have bought the ticket just right now or a sufficient amount of time before. The rules usually are, that you have to buy a ticket before you get on the train. Now, with mobile tickets, some "clever" people thought, they just need to buy a ticket when they see the conductor, and to ride free when they don't see one. In local transit (especially trams, and more and more regional trains) you don't have a regular conductor in every train anymore, but just ticket checking teams, which go around the city. Obviously they can only cover a small part of the available transit vehicles.
This is most likely the reason why the operators introduced this timer, so that it's visible for the conductor if you have bought the ticket just right now or more than 2 minutes ago.

  • 20
    @Alexis_FR_JP a hacked version of the DB app forcing the timer to always show 02:00 is probably available somewhere already. Its a security theater. – JonathanReez May 5 at 2:12
  • 7
    @JonathanReez This is not at all security theatre; see my answer below for why. – Curt J. Sampson May 5 at 5:26
  • 7
    So do even more "clever" people try to see the ticket checker coming, quickly buy the ticket, and then stall for a little bit until the two minute timer runs out? If you spend a little bit of time arguing with the ticket checker, then a bit of time fumbling for your phone, you could probably waste two minutes. – Zach Lipton May 5 at 6:58
  • 3
    @xji: The rules for electronic tickets are no different than for paper ones. You need to be already in posession of a valid ticket in order to be allowed to enter the bus / tram. In my city, some trams have ticket vending machines inside, and on some trams, the conductor sells tickets, but in either case that is just a courtesy to allow you to buy a ticket for your next ride, not the one you are currently on. If you can't finish buying your ticket in time, you need to wait for the next bus / tram (or plan your travel better). – Jörg W Mittag May 5 at 10:20
  • 8
    @xji: Also, if the timer show 45 seconds, and you only entered the tram 30 seconds ago, that is fine. You don't have to stand outside for two minutes before you are allowed to enter. You just need to have the ticket bought before you enter. – Jörg W Mittag May 5 at 10:34
48

@dunni's answer describes the attack that this security measure attempts to mitgate. A comment on his answer claims that this is "security theatre"; I describe in this answer (because this explanation is too long to fit into a comment) why it is not.

Most security measures cannot completely prevent attacks. An effective security measure is one that increases the cost to the attacker significantly while not also increasing costs to the defender beyond reasonable economic return.

This is why spot checks for tickets work though they sometimes allow people to travel for free: though an attacker can simply not buy a ticket and stand a chance of gaining free travel, if the penalty when this is discovered is high enough most potential attackers will choose to buy a ticket rather than run the risk of paying the fine or suffering other punishment

In this case, there are two requirements for an attacker: 1. Write or obtain a version of the app in appears to be the official one and which displays the same result as if the user had purchased the ticket well before the conductor arrived to check it. 2. Side-load this app, since Deutsche Bahn can fairly easily ensure that one appearing in the official store is easily taken down.

Writing such an app is significantly difficult; it involves not only having the skill to duplicate the app itself, but also overcoming any security measures protecting the original app (such as being able to extract any necessary keys from it necessary to instruct the DB servers to purchase a ticket).

Of course, once even one person writes such an app, it could be shared with others incapable of doing so. But finding such an app once it's written is also not completely trivial; DB also may have the ability, even if it's not on the official store, to get it taken down through legal means. If they can't do that, they can also easily change how their app works (different security keys, different network protocols, different display) to require the app's author to update it.

Even should the app be easily available, the user still needs to be sophisticated enough to side-load the app (since it won't be available from the official app store) and must also be willing to run the personal security risk that the app author is malicious and actually wrote the app to attack the users who download it, rather than DB.

All of the above combine to make a fairly high cost to the attacker, whereas for DB to add the timer to their existing app is very little work. Spending a few days of developer and tester time to add this feature to the application thus probably pays itself off very easily even if it prevents only 50% of the potential attackers from executing the attack (though it probably prevents a far higher percentage).

The reason something like American TSA security checks qualify as security theatre is because they impose very large costs on the defenders for very little gain against attackers. These checks exist because the costs are mainly borne by people who can do little about it (airlines and their passengers) whereas the benefits (looking like you're doing something about a problem) accrue only to some government and elected officials who suffer little of the overall cost.

  • 12
    Or perhaps there is already a timestamp and the timer is just for the convenience of the user? – JonathanReez May 5 at 5:54
  • 16
    Isn’t all you need a screenshot of the ticket from the legitimate application, and to draw a new timer box over it? I don’t see why the application would need to talk to the DB servers at all, from what’s presented here. – Michael Homer May 5 at 6:03
  • 14
    If the timer reached 2 minutes, it starts blinking. Forgot to mention this in my answer. So a screenshot will not work. – dunni May 5 at 6:07
  • 10
    Finally, the Barcode reveals if a ticket is just a minute old, and no further information is necessary. Having no valid paper ticket already leads to long discussions. Now, imagine the discussion when the passenger has a technically valid ticket, and the conductor insists it was bought just a minute ago. The timer ends this immediately. I also guess that most passengers would not use any fraud app - but would try to buy a ticket when they spot the conductor. – sweber May 5 at 7:08
  • 9
    It's admittedly tricky to re-write the whole app. It's not tricky to put a graphical element on the screen showing "2:00". – theonlygusti May 5 at 17:52
32

There is already a good answer: It provides an additional quick visual indicator in case the passenger bought the ticket only after entering the vehicle and spotting the conductor.

But let's add some more context.

Ticket controls do not usually pay for themselves with fines. Ticket controls are paid for by getting more people to buy tickets. The goal of ticket controls is not to catch passengers who cheat, it's to encourage passengers to buy valid tickets.

There are plenty of ways to circumvent the timer, starting with "My phone just crashed, the reboot will be done in a minute", and ending with software that creates a forged ticket. But I speculate that the app creators speculated that the timer reminds potential cheaters that purchase time is relevant. That would encourage those people to buy valid tickets.


To address comments to the other answers, which raised the legitimate concern of forged tickets defeating the timer: Purchase time stays relevant even if one of multiple mechanisms that show purchase time is defeated. And being caught with a forged ticket can be way more inconvenient than being caught without a ticket.

  • 3
    This more directly and clearly explains one of the key points I was trying to make in my answer. Excellent answer! – Curt J. Sampson May 6 at 1:15
  • 4
    "It keeps honest people honest" is most likely the best reason behind all these security features. Any software security developed by humans can be defeated by other humans, given enough time & incentive. Increasing the difficulty of defeating the system keeps more people honest. – FreeMan May 6 at 13:13
  • 1
    Just like the old saying - locks don't stop thieves, they stop honest people – llama May 6 at 19:27
  • 3
    @llama With the very important caveat that, absent locks and any credible threat of being caught, an unfortunate number of honest people would act in a dishonest way. – J... May 7 at 11:45
8

This is all about a ticketing system called Proof of Payment.

Historically, conductors walked every train and checked every passenger, selling them a ticket if needed. However, this was expensive to staff, so they looked at ways to automate this.

They came up with a modified "honor system" where people would buy tickets, and carry proof of this. Then, random checks would occur, with expensive fines for violators.

  • In the first cut of this, tickets were sold at machines at stations. The station would put a timestamp on the ticket, and it was only valid for a limited time (so you couldn't use the same ticket over and over and over).
  • You couldn't buy tickets on the train, or else people would simply linger at the ticket machine and buy a ticket if they saw a fare inspector.
  • Then they offered advance sales (e.g. 10-ride ticket books), but you had to "validate" (put a time-stamp on it) at time of use at the station.
  • When smartphones came along, that brought back the problem of people buying tickets only when they see the inspector coming. It's even worse; on the smart device you could go through all the steps to buy a ticket, and pause at the final "Complete sale" button; and click that as the inspector enters the car.

So the timer is an attempt to crack that problem. It shows the inspector that the purchaser bought the ticket seconds ago; but more importantly, it shows the purchaser that the the inspector knows that.

The inspector can already get that information off the barcode; so it's more of a deterrent to the purchaser.

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.