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

(PLEASE NOTE: Of course it's clear that not every, or even (in theory) more than one, attacker has to write such an app. But it is essential that at least one do so, and that it be distributed if other attackers are going to use it. Do not consider this the sole source of security and it's all over once such an app is written; consider also how other difficulties listed below contribute to the overall level of difficulty of the attack and how many attackers may find it worth mounting such an attack.)

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.

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

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

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.

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

(PLEASE NOTE: Of course it's clear that not every, or even (in theory) more than one, attacker has to write such an app. But it is essential that at least one do so, and that it be distributed if other attackers are going to use it. Do not consider this the sole source of security and it's all over once such an app is written; consider also how other difficulties listed below contribute to the overall level of difficulty of the attack and how many attackers may find it worth mounting such an attack.)

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.