56

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 04 '19 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. –  May 04 '19 at 20:16
  • @Willeke: AFAIK unfortunately, no. – cbeleites unhappy with SX May 04 '19 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 04 '19 at 22:48
  • Dumb, insecure and easealy hackable solution to a world with lesser humans operating machines. – Pedro Lobito May 05 '19 at 07:23
  • 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 05 '19 at 16:40
  • 1
    This is not a DB ticket, it is a ticket for the regional transportation tariff (VRS), which have the 2-minute rule. For DB tickets, there is no such rule (or counter), though the app will refuse to sell tickets for a specific connection 2 (or so) min. before departure. – npl May 13 '19 at 22:31

4 Answers4

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.

dunni
  • 9,039
  • 2
  • 31
  • 35
  • 2
    Don't you need to scan the QR code like any other paper tickets? That timer seems a pretty bad solution against fraud... It same as buying the ticket and waiting for the operator to punch it. – None May 05 '19 at 02:08
  • 21
    @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 05 '19 at 02:12
  • 7
    @JonathanReez This is not at all security theatre; see my answer below for why. – cjs May 05 '19 at 05: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 05 '19 at 06:58
  • You can also "faint" for 2 minutes :) – Pedro Lobito May 05 '19 at 07:17
  • IMO two minutes is a bit long. For trains it might be fine, but what if you see a tram/bus coming already and you need to catch it before you can finish buying the ticket. Hope the conductor wouldn't stick to the rigid time limit. – xji May 05 '19 at 09:42
  • 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 05 '19 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 05 '19 at 10:34
  • @JörgWMittag I see. Thanks for the clarification. I've certainly done it multiple times where I only bought the ticket after I entered. I didn't want to buy the ticket too early in advance, as many one-way tickets expire in a couple of hours. I could use more care the next time. – xji May 05 '19 at 11:52
  • With the new comfort check-in, which only requires you to click on "yeah, I'm here" in the app, and the conductor will simply ignore you, what's the point? See the conductor coming, buy your ticket, and click "yeah, I'm here". – Damon May 05 '19 at 15:07
  • 2
    Comfort Check In is only available in DB trains (and there AFAIK also only in ICEs). Here we are talking about tickets for local transit, which you can also buy in the DB Navigator App. For DB tickets the DB already has a mechanism in place, that you cannot buy a ticket for a specific train less than 10 minutes before departure. You can still buy a flex ticket for a later train, which is also valid for immediate departure, but then you can't use Comfort Checkin. For IC, EC and ICE trains you can still anyway buy tickets on the train, so the fare rules are different to local transit operators. – dunni May 05 '19 at 15:08
  • 1
    @JörgWMittag that is not true. You can enter busses without a valid ticket and buy it directly from the driver. – infinitezero May 05 '19 at 23:47
  • @JonathanReez would you have a link or any references to a hacked version of the DB app existing? – Ivan McA May 06 '19 at 13:20
  • 1
    This is common enough that the Dallas, TX area trains and busses use a similar technique for mobile tickets. The ticket flashes yellow for a time after it is activated so fare enforcement knows you just activated the ticket. Stops people from only activating a ticket when they see fare enforcement. – JPhi1618 May 06 '19 at 15:01
  • @IvanMcA it looks like there is indeed a timestamp in the ticket, so a hacked app won't be too helpful. – JonathanReez May 06 '19 at 15:33
  • 1
    Yes, the timer shown in the picture is just an additional, quickly viewable indicator. – dunni May 06 '19 at 15:49
  • What happens if you change the clock while the timer is still running? It the timer does not change, then how will it work when the phone does a reboot while the timer is running. If the timer changes, then it is broken. – 12431234123412341234123 May 06 '19 at 17:27
  • @JörgWMittag "You don't have to stand outside for two minutes before you are allowed to enter. " -- Do you have evidence for that? – npl May 13 '19 at 22:33
49

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

cjs
  • 658
  • 4
  • 8
  • 2
    "Writing such an app is significantly difficult" -> only 1 person has to do this, after which tens of thousands could use it. Is there a reason why they couldn't just encode a timestamp within the ticket itself? You would not be able to fake the timestamp, presuming the entire ticket is signed. – JonathanReez May 05 '19 at 05:51
  • 12
    Or perhaps there is already a timestamp and the timer is just for the convenience of the user? – JonathanReez May 05 '19 at 05: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 05 '19 at 06: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 05 '19 at 06:07
  • 6
    Pretty much every remotely competent transit ticket app has some kind of dynamic design element to defeat screenshots (since tickets are often checked visually without using a barcode scanner) including animations or something you tap to make the display change colors. It doesn't have to be perfect, just something that deters people from trying to trick the process with a screenshot. – Zach Lipton May 05 '19 at 06:56
  • 12
    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 05 '19 at 07:08
  • 1
    Do they always scan the barcode, or do conductors sometimes just glance at the screen because it's faster? If the latter, the timer still serves a verification purpose (though obviously not as strong as checking the bar code against sales records on the server). Also, even if they always do check the barcode when they check a ticket, simply making it more clear that certain security systems are in place may deter attackers, much like an audible alarm that may convince a burgler to leave immediately upon hearing it, whether or not anybody responds to it. – cjs May 05 '19 at 10:27
  • 10
    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". – minseong May 05 '19 at 17:52
  • 2
    My original objection was to this passage, which still appears completely unjustified: "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).". It's just absurd to insist that this application would need to buy the ticket itself in order to imply that a passable fake is "significantly difficult". There are other actually valid points in the answer – Michael Homer May 05 '19 at 23:26
  • It doesn't matter whether you've actually purchased the ticket through the app; if it was purchased via other means you still have the security problem of making sure that only the correct person/account using the app can display that ticket. If anybody using the app can display any ticket, someone who didn't purchase a ticket could simply display someone else's ticket, thus "stealing" it. – cjs May 06 '19 at 01:13
  • 6
    Creating and sharing a screen overlay app is trivial. 1. Search Stack Overflow. 2. Write a tiny little app which displays 02:00. 3. Build an APK and share it with your friends. I imagine this was done on day 1. – Aaron F May 06 '19 at 08:35
  • 5
    @AaronF I'm a developer who has even built a (very simple) Android app, and what you describe is decidedly not trivial for people who are not experienced mobile app developers. You may imagine that this was already done on day one, but do you have any evidence of this? (E.g., can you point to a a copy of a program that does this, along with installation instructions?) – cjs May 06 '19 at 13:14
  • Your arguments towards difficulty assume that DB did a decent job building the app and that they care about frauds. However I do know that in China, there is a town that mandates their citizens have a certain app installed on their phones. An app that reports the complete state of the phone to the authorities. That app uses plain-text communication. Not a custom-built encryption, not HTTPS with baked-in certs, Not even self-signed HTTPS. Not even a binary file. Plain text. – John Dvorak May 06 '19 at 16:46
  • @CurtJ.Sampson Why limit consideration to people who aren't experienced app developers? Surely Germany has thousands upon thousands of experienced app developers. – reirab May 06 '19 at 18:27
  • 1
    @reirab If you read my analysis carefully, you'll note I don't limit consideration to people who aren't experienced app developers (and don't limit it to developers in Germany, either). But it makes a huge difference whether 50% of the passengers or 0.05% of the passengers have the technical capability to make that app. You don't leave your house unlocked just because there are some people out there capable of picking the locks, do you? – cjs May 07 '19 at 02:07
  • @JohnDvorak Actually, my arguments do not rest completely on DB doing an effective implementation of the apparent security measures. Even measures that just appear to exist can deter attackers, in the same way a "Beware of Dog" sign will prevent some attackers even if there is no dog. For all we know, even were the two minute timer always ignored by all conductors, that people can see it and know that it could be implemented properly will have some deterrent effect. – cjs May 07 '19 at 02:11
  • @Curt Luckily I don't have to be an experienced developer to simply double click on an apk. Hell Fortnite which has millions of android users (which I'm going out on a limb and claim are not all experienced android developers) requires exactly the same steps. (also are you really arguing that "beware of dog sign" without a dog is not security theatre?) – Voo May 07 '19 at 15:18
  • @CurtJ.Sampson I cannot. My German is very basic, and also I wouldn't know where to even start looking (German hacking forums or IRC channels?) A quick search returns source code for such an app, though the less technically inclined might first try a generic overlay app from Play Store. – Aaron F May 07 '19 at 16:32
  • "...are you really arguing that "beware of dog sign" without a dog is not security theatre?" @Voo Yes, that is precisely what I'm arguing (unless it's a really expensive "Beware of dog" sign).Please re-read this answer again carefully. To see how effective this DB security measure is, I suggest you actually perform the attack yourself (staying short of actually getting on a train without a ticket) on a standard Android install and carefully document everything you had to do, how long it took and what knowledge you needed to do it. – cjs May 07 '19 at 23:33
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.

Peter
  • 1,849
  • 1
  • 14
  • 21
  • 3
    This more directly and clearly explains one of the key points I was trying to make in my answer. Excellent answer! – cjs May 06 '19 at 01:15
  • 5
    "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 06 '19 at 13:13
  • 1
    Just like the old saying - locks don't stop thieves, they stop honest people – llama May 06 '19 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 07 '19 at 11:45
  • @llama Locks and other security measures stop crimes of opportunity. – Kyralessa Dec 17 '19 at 14:24
7

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.

Harper - Reinstate Monica
  • 35,577
  • 4
  • 65
  • 144