Ttdfjt

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?

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

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.

@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.

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.

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.