Diskussion:Online-Ticket

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 365 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 5 Abschnitte.

Archiv

seit 2007

Wie wird ein Archiv angelegt?

Also doch ne Datenbank...

Ich habe gerade hier in einem Forum von Daten-Speicherung.de Infos zu den im Barcode gespeicherten Daten gefunden. Dort wird aus einem Schreiben der DB zitiert. Der Text ist CC-BY-lizensiert, daher kopiere ich ihn mal hierher:

[…] Ihre Kreditkarte dient zur Identifikation Ihrer Person im Zug. Im Barcode werden Abgangsbahnhof, Zielbahnhof, Strecke, Züge, Anzahl der reisenden Personen, der Tarif (bspw. mit oder ohne BahnCard, Sparpreis….), das Reisedatum und die Wagenklasse in einem Datensatz gespeichert. Mit dem korrelierenden Kontrolldatensatz im Mobilen Terminal des Zugbegleiters überprüft der Zugbegleiter im Zug die Gültigkeit des Online-Tickets. Die Kontrolldaten enthalten Informationen zum Zug in dem das Online-Ticket kontrolliert wurde, aber keine personenbezogene Daten. Auch wird die Nummer der Ausweis-ID (hier Ihre Kreditkartennummer) werder erfasst noch gespeichert. Die personenbezogenen DAten werden nicht an Dritte übermittelt. Wir hoffen Sie Ihrem Wunsche entsprechend informieren zu können.

Mit freundlichen Grüßen

…

Deutsche Bahn AG

stv. Konzerndatenschutzbeauftragter (MZD)

(Datenschutzrecht, Multimediadatenschutzrech

Der Kontrolldatensatz im Terminal kommt (woher auch sonst) offensichtlich aus einer Datenbank. Das können wir dann wohl so in den Artikel einarbeiten. Meine „Erfindung“ war also offensichtlich nicht so Falsch. -- Dr. Schorsch*?*! 10:38, 29. Mär. 2007 (CEST)

Eine Datenbank, ja, aber keineswegs so verwendet, wie vorher beschrieben.

In Deinem Verfahren wurde das Ticket durch die Datenbank für gültig erklärt. Wie oben erklärt, wäre in Deinem Verfahren überhaupt kein Ticket mehr notwendig, sondern lediglich der Ausweis, darüberhinaus müsste ein ständiger Datenbankabgleich stattfinden, wenn man Tickets bis kurz vor Abfahrt kaufen können soll, und es wären Größenordnungen mehr Speicherplatz auf dem Kontrollgerät notwendig. Darüberhinaus wäre die Speicherung personenbezogener Daten notwendig.

Im tatsächlichen Verfahren dient die DB dazu, ein Ticket, das durch das public-key-Verfahren für gültig erklärt wurde, für ungültig zu erklären, um eben Mehrfachnutzung zu verhindern und die Rückgabe von Tickets zu erlauben. Das ist ein substanzieller Unterschied:

1. Es ist keine Speicherung personenbezogener Daten notwendig.
2. Es müssen nur sehr wenige Datensätze gespeichert werden: einerseits die der stornierten Tickets, andererseits die der verwendeten, nicht zuggebundenen Tickets innerhalb des Gültigkeitszeitraumes. :#Die Datensätze müssen nur einmal täglich abgeglichen werden.
3. Im Falle, dass die Datenbank ausfällt, ein Fehler bei der Datenübertragung auftritt oder Ähnliches können die Online-Tickets trotzdem überprüft werden. Der einzige Nachteil für die Bahn wäre, dass Mehrfachnutzer oder Nutzer stornierter Tickets trotzdem fahren können.

Theoretisch kann in diesem Verfahren jemand am selben Tag zweimal die selbe Strecke fahren, aber ich denke, das nimmt die Bahn in Kauf. Daher kommt wahrscheinlich auch die Begrenzung, dass Online-Tickets erst ab 51 km gekauft werden können. Das ein und dieselbe Person am selben Tag mehr als einmal dieselbe Strecke über 50 km fahren will, ist eben recht unwahrscheinlich.

--Olenz 11:27, 29. Mär. 2007 (CEST)

Nein, das nimmt die Bahn nicht in Kauf!! Denn Kreditkarten/BahnCards etc. kann man leicht kopieren und so könnten unzählige Personen an einem Tag die selbe Fahrkarte nutzen ohne das es auffallen würde. Außerdem sind Fahrkarten über 100 km zwei Tage gültig und Rückfahrkarten sogar einen Monat, womit eine Mehrfachnutzung auch nur für eine Person interessant wäre. Deswegen speichern die mobilen Terminals jede kontrollierte Fahrkarte. Alle paar Tage werden die Geräte ausgelesen und dann kommen die Daten in Eure heißgeliebte Datenbank. Dort fallen Doppelbenutzungen natürlich sofort auf und die Bahn reagiert mit Regressforderungen ggf. mit Sperrung des Accounts und Strafantrag.169.229.55.85 11:59, 5. Apr. 2007 (CEST)

Hallo Olenz, Du schreibst, dass die DB der DB (ein Hoch auf Abkürzungen ;-) nur dazu benutzt wird um Tickets für ungültig zu erklären und die Mehrfachnutzung zu erkennen. Das ist eine Möglichkeit, aber das wissen wir noch nicht. Wenn es so wäre kann man allerdings keine gefälschten Tickets (mit gültiger Signatur) vor Ort erkennen, sondern erst wenn man alle kontrollierten Tickets nachträglich mit der DB abgleicht. Technisch sehe ich kein Problem, warum die Kontrollgeräte nicht die IDs aller gerade im Umlauf befindlichen Tickets kennen sollten. Für kurzfristig verkaufte Tickets kann man die IDs ja im vorhinein festlegen. Die IDs wären sogar kürzer als die Signatur. Damit sind wir wieder bei ein paar Megabyte und das ist kein wirkliches Problem. -- Dr. Schorsch*?*! 10:06, 30. Mär. 2007 (CEST)

Ich verstehe nicht, warum Du jetzt auf einmal doch wieder mit Deiner Datenbanklösung kommst. In dem von Dir selbst oben zitierten Schrieb der Fraunhofergesellschaft wird das Verfahren der Online-Tickets doch genau erläutert.

Ich gehe jetzt trotzdem nochmal auf Deinen Kommentar ein: Was meinst Du mit der "ID", von der einige vorherberechnet werden könnten?

Wenn Du damit das Zertifikat meinst, dann ist es klar, dass man solche nicht vorherberechnen kann, weil man ja die personenbezogenen Daten, die darin stecken, noch nicht kennt.

Wenn du den Kontrolldatensatz meinst, dann hier ein Zitat von dem von Dir genannten Forum: Die Kontrolldaten enthalten Informationen zum Zug in dem das Online-Ticket kontrolliert wurde, aber keine personenbezogene Daten.. Sprich, der Kontrolldatensatz wird erst dann erstellt, wenn ein Ticket kontrolliert wird, und nicht vorher.

Schliesslich verstehe ich nicht, was der Vorteil der Datenbanklösung sein sollte, und welchen Nachteil die digitale Signatur bietet, und warum angesichts dieser klaren Vorteile die Bahn eine Datenbanklösung wählen sollte. Wenn Du mir dafür einen Grund nennst, denke ich auch gerne nochmal darüber nach.

--Olenz 12:25, 30. Mär. 2007 (CEST)

Also nochmal Klartext: Mit ID meine ich eine eindeutige Nummer für das Ticket. Die hat nichts mit Personen oder Reiseweg zu tun. Das Zertifikat ist davon völlig unabhängig und erfüllt seinen bekannten Zweck. In dem zitierten Brief von der Bahn steht nicht drin was sonst noch für Informationen im Kontrolldatensatz sein könnten. Dagegen steht dort ausdrücklich, dass die Gültigkeit mit dem korrelierenden Kontrolldatensatz im Zug (also vor Ort und nicht erst später) geprüft wird. Wenn das so gemeint ist wie es dasteht wird zumindest ein Teil des Kontrolldatensatz im vorhinein erstellt, eben der der das Enthält was ich oben „ID“ genannt habe. Das ist ja auch sinnvoll, da man nur so gefälschte (aber gültige) Zertifikate erkennen kann.

Die Fraunhoferpublikation bezieht sich übrigens nicht auf Bahn-Tickets, die Bahn taucht auch nicht bei den Anwendungsbeispielen auf. -- Dr. Schorsch*?*! 14:16, 30. Mär. 2007 (CEST)

Verstehe ich das jetzt richtig, dass Du glaubst, dass zumindest die Bahn glaubt, dass jemand ein digitales Zertifikat fälschen kann, und sie gegen diesen Fall zusätzliche Sicherungen eingebaut hat?

Wenn ja: Du weisst, dass das gleichbedeutend damit wäre, dass jemand ein Verfahren gefunden hat, mit dem er die Primfaktorzerlegung effizient durchführen könnte? Und das es für ein solches Verfahren wirklich bessere Anwendungsmöglichkeiten gäbe, als ausgerechnet Online-Tickets zu fälschen? Im Grunde beruhen sämtliche mir bekannten asymmetrischen Verschlüsselungsverfahren genau darauf. Ich glaube, wer ein solches Verfahren findet, ist entweder ganz schnell tot, oder Nobelpreisträger. Ich würde Dir raten, Dich mal über digitale Signaturen kundig zu machen.

Also, ich gehe mal davon aus, daß eine digitale Signatur von der Bahn als sicher eingestuft wird. :Damit wäre eine solche zusätzliche "Sicherung" sinnfrei, zumal diese "Sicherung" tatsächlich relativ einfach zu umgehen wäre, denn an eine solche ID zu kommen, sollte nicht besonders schwer sein: einfach am Vortag beim Sitznachbarn abschreiben (die IDs müssen ja mindestens zwei Tage gültig sein), oder einen Kontrollcomputer klauen, oder eine der zahlreichen Verbindungen vom Server zu den Kontrollcomputern anzapfen, ....

Ich verstehe den Satz oben so:

1. Ein Kontrolldatensatz wird erstellt, wenn ein Online-Ticket mir längerer Gültigkeitsdauer kontrolliert wird. Es speichert die ID des Tickets plus den Zug, in dem kontrolliert wurde.
2. Einmal am Tag aktualisieren die Kontrollcomputer die gespeicherten Kontrolldatensätze.
3. Wenn ein Ticket kontrolliert wird, und das Zertifikat gültig ist, dann wird ausserdem noch überprüft, ob es einen Kontrolldatensatz für dieses Ticket gibt. Wenn ja, dann wurde das Ticket bereits in einem anderen Zug kontrolliert, und ist damit ungültig.

Diese Methode erklärt die Bedeutung des Satzes oben: der Kontrolldatensatz wird im Zug kontrolliert, und er wird tatsächlich auch vorher erstellt, nämlich im Zug in dem das Ticket bereits vorher kontrolliert wurde.

--Olenz 23:11, 31. Mär. 2007 (CEST)

Eine wichtige Prüfung für die Sicherheit eines Systems ist es, sich einen böswilligen Mitarbeiter vorzustellen, und sei er der Chef persönlich (aber Herrn M. will ich natürlich nichts unterstellen ;-), der in der Lage ist die gleiche Technik einzusetzen wie das Unternehmen selbst ohne direkten Zugriff auf die Unternehmensinfrastruktur zu haben. Beim Online-Ticket heißt das, er kennt den Signaturalgorithmus und besitzt den zugehörigen privaten Teil des Schlüssels. Damit kann er eine gültige Signatur erstellen. Diese Form des Angriffs war es die ich oben beschrieben habe. Sie ist wesentlich wahrscheinlicher als das mathematische Knacken des Signaturverfahrens. Als Herausgeber von Online-Tickets würde ich mir wünschen sojemanden auf der Stelle dingfest zu machen und dafür muss ich wissen welche Tickets verkauft wurden oder in kürze Verkauft werden könnten. -- Dr. Schorsch*?*! 18:13, 1. Apr. 2007 (CEST)

Der geheime Schlüssel muß ausschließlich auf einem oder vielleicht einer Hand voll Rechner liegen, die vermutlich alle in einem Hochsicherheitsraum des Rechenzentrums der DB stehen. Zu keinem Zeitpunkt muß der Schlüssel über das Netzwerk gesendet werden.

Deine IDs hingegen müssen auf jedem Einzelnen der etlichen hundert Kontrollcomputer gespeichert werden, die jeder Schaffner bei sich trägt und darüberhinaus einmal täglich über irgendwelche Leitungen an diese gesendet werden.

Jemand, der in der Lage ist, den geheimen Schlüssel aus dem oben genannten Rechenzentrum zu stehlen, soll Probleme haben, an eine gültige ID zu kommen?

Deine IDs als "zusätzliche Sicherung" zu benutzen ist in etwa so, als würdest Du vor die Fenster Deines mit Panzerglas und Alarmanlage ausgestatten Hauses Mückengitter spannen, um vor noch mehr Einbrechern sicher zu sein.

Nun aber nochmal grundlegend: Warum führen wir die Diskussion eigentlich noch? Im Prinzip geht es uns beiden doch nur noch ums Rechthaben. Auf den Artikel hat die Diskussion keine Auswirkung, da wir abschliessend nicht klären können, wie genau der Kontrolldatensatz funktioniert. Einig scheinen wir uns aber mittlerweile darüber zu sein, daß der wichtigste Teil des Online-Tickets ein digitales Signaturverfahren ist, und der Kontrolldatensatz eher eine untergeordnete Rolle spielt, oder?

--Olenz 20:57, 1. Apr. 2007 (CEST)

Schön und ich dachte schon Du merkst das gar nicht mehr ;-) Fazit, der Artikel ist besser als vorher. Das ist doch die Hauptsache. -- Dr. Schorsch*?*! 16:10, 3. Apr. 2007 (CEST)

Ja der Artikel ist jetzt super und beschreibt alles richtig. Nur der letzte Absatz "Anwendungen" kommt noch ein bisschen holprig daher und ist verbesserungsbedürftig. Anstatt (wie vom Leser erwartet) die Funktionsweise des Onlinetickets noch mal anhand des DB-Tickets exemplarisch zu erläutern, ist aufeinmal die Rede von Datenschutz und Kontrollsatz, obwohl diese Begriffe im ganzen Artikel davor nicht vorkommen. In meinen Augen ist der Kontrolldatensatz für den diesen Artikel irrelevant.169.229.55.85 12:10, 5. Apr. 2007 (CEST)

Naja, ich habe an dem Artikel schon noch einiges auszusetzen, aber die Änderungen mache ich wann anders. Zumindest ist jetzt kein Fantasieverfahren mehr beschrieben.

Im Artikel (und auch in der Diskussion) stecken noch zwei Annahmen drin, die ich für falsch halte. Deshalb möchte ich sie hier doch nochmal ansprechen:

Einerseits die Annahme, dass die Identifikation (Kreditkarte, BahnCard oder ec-Karte) leicht zu fälschen oder zu kopieren wäre. Es ist tatsächlich kein Problem, den Magnetstreifen zu kopieren - aber für die Identifikation im Zug wird die Karte selbst verwendet, also das Bild auf der BahnCard und die Hologramme auf der Kredit- bzw. ec-Karte. Und die zu kopieren, ist nun nicht wirklich so einfach. Ich denke, die glaubwürdige Identifikation ist ein zentraler Bestandteil des Onlinetickets.

Andererseits bezweifle ich stark, dass die DB nachträglich Regressforderungen stellen kann, wenn sie beim Datenbankabgleich Mehrfachnutzung feststellt. Eine solche Mehrfachnutzung könnte ja tatsächlich durch Betrug (z.B. Identitätsklau) zustande gekommen sein, oder zumindest könnte der Kunde das behaupten. Die Beweislast liegt dann bei der Bahn, denn sie stellt Forderungen an den Kunden und nicht umgekehrt!

Anders ist der Fall gelagert, wenn der Kontrolleur im Zug eine Mehrfachnutzung feststellt. Der Kunde besitzt ein Ticket, mit dessen Hilfe er den Dienst der Bahn in Anspruch nehmen will. Wenn der Kontrolleur feststellt, dass das Ticket ungültig ist (eben z.B. wegen Mehrfachbenutzung), dann muss in diesem Fall der Kunde den Beweis erbringen, dass es gültig ist - denn er hat ja eine Forderung an die Bahn, nicht umgekehrt.

Der lange Rede kurzer Sinn: die Identifikation ist dafür notwendig, im Zug die Gültigkeit des Tickets festzustellen. Die Datenbank ist dazu da, um zu verhindern, dass jemand ein Ticket zu oft benutzt (also an mehreren Tagen hintereinander oder so), aber eine Mehrfachnutzung durch die selbe Person am selben Tag kann sie IMO nicht verhindern. Meiner Meinung nach kommt genau daher die Einschränkung auf mindestens 51 km.

Nachträglich kann die Bahn nicht mehr machen, auch wenn sie feststellt, dass jemand ein Ticket mehrfach benutzt hat, da sie es nicht beweisen kann.

Wenn niemand von Euch dem widerspricht, werde ich den Artikel entsprechend korrigieren.

--Olenz 17:02, 5. Apr. 2007 (CEST)

Es reicht auch sogar nur die Karte zu kopieren (ohne Magnetstreifen). Denn bei defektem Magnetstreifen kann der Schaffner die Kartennummer auch per Hand abgleichen. Natürlich ist das Fälschen ein gewisser Aufwand. Mehrfachnutzung von ein- und derselben Person (wie bereits erwähnt: Karten über 100 km sind zwei Tage gültig, Rückfahrkarten sogar einen Monat) sind aber wie gesagt auch ohne Fälschung möglich.169.229.55.85 21:57, 5. Apr. 2007 (CEST)

Sorry, aber das zeigt leider Deine Unkenntnis sehr deutlich. Wie oft hast Du denn das Online-Ticket selber schon benutzt? Selbstverständlich erfolgen diese Regressforderungen und es gibt extra eine eigene Abteilung der DB, die sich nur mit diesen Regressforderungen bzgl. Onlinticket auseinandersetzt. Ohne das Mittel der Regressforerung wäre das ganze System nicht möglich. Kunden könnten so z.B. stornierte OT trotzdem benutzen oder aber auch beliebig oft benutzen. Die Tatsache, dass Fahrkarten für Hin-und Rückfahrt für die Rückfahrt einen Monat (und nicht wie von Dir behauptet einen Tag) lang gültig sind, würde viele Mißbrauchsmöglichkeiten eröffnen.169.229.55.85 21:57, 5. Apr. 2007 (CEST)

Der Zugbegleiter hat keine Möglichkeit eine Mehrfachnutzung festzustellen. Das kann nur im Nachhinein geschehen. Anders als von Dir behauptet, enthalten die mobilen Geräte eben keine Infos über bereits benutzte Tickets und anders als von Dir behauptet werden sie nur alle paar Tage ausgelesen, keineswegs täglich.169.229.55.85 21:57, 5. Apr. 2007 (CEST)

Die Identifikation ist nur dazu da, um Mißbrauch durch andere Personen zu verhindern. Bsp: Jemand druckt sich sein OT im Internetcafe aus und speichert es dort. Nun geht jemand anders an den Rechner und druckt sich das nochmal aus und fährt damit. Der ehrliche Kunde würde dann im Nachhinein wegen Doppelnutzung eine Regressforderung bekommen. Und genau um das zu verhindern, gibt es die Identifizierung! Sie ist sozusagen zur Sicherheit des Kunden. Somit ist sichergestellt, dass nur er das Ticket benutzen kann und es ihm nicht gleich zum verhängnis wird, wenn er sein OT an andere Personen (bewußt oder unbewußt) weitergibt. Die Terminals der Zugbegleiter haben keine Infos über bereits benutzte Tickets. Auch eine Mehrfachnutzung an mehreren Tagen hintereinander kann erst im Nachhinein festgestellt werden. Die 51 km Grenze hat damit nichts zu tun.169.229.55.85 21:57, 5. Apr. 2007 (CEST)

Natürlich kann sie die Bahn was machen, sie stellt eine Regressforderung und sperrt im Wiederholungsfall den Account und stellt Strafantrag. Habe ich aber oben auch schon geschrieben. Hab mir mal die Mühe gemacht, ein Beispiel zu finden: [[1]] 169.229.55.85 21:57, 5. Apr. 2007 (CEST)

Erstmal eine kurze Bitte: schreibe bitte nicht zwischen alte Beiträge, sondern hänge Deine Beiträge unten an. Es ist sonst wirklich schwierig, der Diskussion zu folgen, vor allem wenn es mehrfach hin- und hergeht!

Ansonsten geht mir Deine Arroganz langsam echt auf den Nerv. Du nimmst ständig so Dinge in den Mund, wie "das zeigt Deine Unkenntnis", oder "wie allgemein bekannt", aber warst noch nicht einmal in der Lage, eine Quelle für irgendetwas zu nennen. Wenn Du so viel "weisst", wie Du immer behauptest, dann nenne uns Deine Quelle. Bist Du Zugbegleiter? Kennst Du einen? Oder hast Du nur immer gehört, dass es so ist?

Ich bin schon sehr viel mit dem Online-Ticket unterwegs gewesen. An mich ist die Bahn bislang noch nicht mit Regressforderungen rangetreten. Das Schlimmste, was mir passiert ist, war, dass meine BahnCard noch im Portmonnaie meiner Frau steckte, die leider nicht mit mir im Zug saß. Leider musste ich das Ticket zum Normalpreis nachlösen. Tatsächlich hat aber genau dieses Ereignis dazu geführt, dass ich mir diesen Artikel angeschaut habe, und folglich diese Diskussion angefangen habe.

So, jetzt aber nochmal inhaltlich: Wenn die Bahn tatsächlich Regressforderungen stellt, dann heisst es noch lange nicht, dass sie das mit gutem Recht tut. Die Beweislast liegt theoretisch in jedem Fall bei der Bahn. Übrigens sehen es scheinbar auch die Leute im von Dir zitierten Forum so. Ich bezweifle, dass die Bahn sich darauf verlässt, dass diese Regressforderungen alle durchkommen.

Aber betrachten wir das Problem von einer anderen Seite: Wenn der Zugbegleiter im Zug tatsächlich keine Möglichkeit hat, zu prüfen, ob ein Ticket storniert oder vorher benutzt wurde, wozu dient denn dann der Kontrolldatensatz, der oben erwähnt wurde? (Zitat: Mit dem korrelierenden Kontrolldatensatz im Mobilen Terminal des Zugbegleiters überprüft der Zugbegleiter im Zug die Gültigkeit des Online-Tickets [2])

Und wenn die Bahn schon Kontrolldatensätze im Mobilen Terminal speichert, warum dann nicht auch genau diese Informationen, die tatsächlich nützlich wären?

Wie häufig der Abgleich geschieht, weiss ich nicht. Ich hatte lediglich vermutet, dass das täglich geschehen könnte. Wenn Du "weisst", dass das nur alle paar Tage passiert, dann ist es ja gut.

Fazit: So lange Du keine Quelle nennen kannst, glaube ich nicht, dass der Zugbegleiter gar nicht überprüfen kann, ob ein Ticket storniert wurde, oder ob es bereits benutzt wurde. Ich verstehe sonst nicht den Sinn des Kontrolldatensatzes. An Dr. Xorx's These, er dient zur zusätzlichen Absicherung über das digitale Zertifikat hinaus, glaub ich einfach nicht.

Zur Identifizierung: ja, genau so, wie Du das beschreibst, sehe ich es auch. Die Identifikation verhindert den Diebstahl des OT, weil der Dieb sich nämlich nicht passend identifizieren kann. Ich wollte mit meiner Aussage nur der Behauptung aus dem Artikel widersprechen, nämlich dass die Hauptfunktion der Identifikation sei, dass die Bahn weiss, an wen sie Regressforderungen stellen kann. So steht es da nämlich momentan drin, oder zumindest ist es so ausgedrückt. Das korrigiere ich jetzt einfach mal.

--Olenz 23:28, 5. Apr. 2007 (CEST)

Oh, wow, jetzt habe ich sogar die denkbar beste Quelle gefunden: die AGB der DB.

„Das Kontrollgerät speichert einen Kontrolldatensatz, der mit dem gebuchten Ticket verglichen wird. Im Falle des Missbrauchs (z. B. unerlaubte Mehrfachnutzung eines Online-Tickets) liegt eine Reise ohne gültige Fahrkarte vor. In diesem Fall wird dem Reisenden der erhöhte Fahrpreis nach § 12 EVO berechnet und er wird für das Online-Ticket-Verfahren gesperrt. Darüber hinaus wird Missbrauch zur Strafanzeige gebracht. Die Kontrolldatensätze werden mit Ablauf der Frist zur Beantragung von Erstattungen gelöscht.“

– [3]

Zusammen mit der Aussage

„Mit dem korrelierenden Kontrolldatensatz im Mobilen Terminal des Zugbegleiters überprüft der Zugbegleiter im Zug die Gültigkeit des Online-Tickets“

– [4]

ist glaube ich eindeutig, dass die Kontrolldatensätze erstens dazu verwendet werden, die Mehrfachverwendung zu überprüfen, und zweitens, dass sie auf dem Mobilen Terminal gespeichert werden.

qed.

--Olenz 23:50, 5. Apr. 2007 (CEST)

Ok, ich werde nicht mehr dazwischenschreiben und höflicher sein. Eine grundsätzliche Bitte habe ich aber auch an Dich: Bitte hör auf nach dem Motto: "So ist das logisch, so müsste das sein, also wird das wohl so sein" vorzugehen. Entweder Du weißt es, oder Du hast eine Quellenangabe, aber das ist bei den meisten Deiner Punkte leider nicht der Fall. Du vermutest nur und willst diese (falschen) Vermutungen sogar in den Artikel einarbeiten.

Nun nochmal zu den sachlichen Punkten: Der Kontrolldatensatz wird nicht von der Datenbank in das Terminal kopiert, sondern genau umgekehrt. Da liegt das Hauptmißverständnis. Er wird während der Fahrkartenkontrolle erzeugt und dann in dem Gerät abgespeichert. Im Nachhinein (mindestens alle 14 Tage) wird das Gerät mit den Kontrolldatensätzen ausgelesen und dann kommen die Kontrolldatensätze in eine Datenbank und werden aus dem Gerät gelöscht. Dann ist das mobile Terminal wieder "sauber" sprich ohne Daten. Durch die Fahrkartenkontrollen kommen dann wieder neue Kontrolldatensätze rein. Im nachhinein (also nicht während der Kontrolle) werden dann die Kontrolldatensätze mit den Buchungsdatensätzen verglichen. Zu der E-Mail von dem Bahnbeauftragen, die oben zitiert ist: Er drückt sich ein bisschen Mißverständlich aus, er meint folgendes: Der Zugbegleiter gibt die Nummer vom OT in das Gerät ein oder scannt den Barcode ein. Das Gerät erzeugt dann den Kontrolldatensatz und zeigt die Daten auf dem Bildschirm an. Dann kann der Zugbegleiter die Daten auf dem Bildschirm mit den Daten auf der Fahrkarte vergleichen und sehen, ob alles stimmt (und der Kunde nicht z.B. an der Personenzahl, Wagenklasse, oder Strecke retuschiert hat). Das ist mit Gültigkeitsüberprüfung gemeint. Nicht gemeint ist, dass irgendwelche im Gerät abgespeicherten Daten zur Gültigkeitskontrolle herangezogen werden. Hoffe damit die Unklarheiten beseitigt zu haben, falls aber noch nicht alles klar ist, versuche ich gerne es noch ausführlicher zu erklären.169.229.55.85 12:00, 6. Apr. 2007 (CEST)

Um das in Deinen Worten zu sagen: Bitte hör auf nach dem Motto: "Das sage ich, so ist es" vorzugehen.

Ich würde Dir ja wahrscheinlich sogar glauben, wenn Du uns nur einmal mitteilen würdest, woher Du Dein vorgebliches Wissen beziehst. Ich brauche dafür auch keine Belege, aber wenigstens mal eine Aussage. ("Ich hab das Verfahren mitentwickelt!" oder so. Hast Du?)

So wie es zur Zeit aussieht, spielst Du Dich hier zum Richter auf über begründete und belegte Aussagen, dabei könntest Du nach meinem bisherigen Erkenntnisstand ein Elfjähriger sein, der sich ein wenig aufspielen will - mit zugegeben erstaunlicher Ausdrucksweise für einen Elfjährigen. Bevor ich also nicht weiß, woher Dein Wissen stammt, werde ich auf Deine zukünftigen Beiträge nicht mehr eingehen.

So lange Du Dich weigerst, eine entsprechende Aussage zu treffen, werde ich Deine Beiträge ignorieren.

Im Gegensatz zu Dir habe ich oben bereits vier Quellen genannt und beziehe mich auf Quellen, um meine Aussagen zu belegen. Entsprechend baue ich die Sachen in die Artikel ein, beziehungsweise entferne Falschaussagen aus dem Artikel, das ist richtig. Allerdings auch nur, wenn ich mich dabei wirklich ziemlich sicher fühle.

Bislang habe ich lediglich ein komplett unbelegtes, scheinbar selbsterfundenes Verfahren aus dem Artikel entfernt [5], sonst aber noch keine Änderungen vorgenommen.

Ich argumentiere hier nicht nur nach "so ist es logisch, os wird es sein", sondern ich belege meine Theorie durch Quellen, falls möglich.

Die Geschichte mit dem Kontrolldatensatz interessiert mich nur persönlich, und nicht für den Artikel.

Ich glaube ja durchaus, dass der Kontrolldatensatz im Zug erstellt wird. Ich hätte nur auch vermutet, dass einige Kontrolldatensätze danach auch auf andere Terminals aufgespielt werden, um Mehrfachnutzung zu verhindern. Wenn Du - aufgrund welcher Autorität auch immer - "weißt", dass es anders ist, dann bin ich ja sogar geneigt, Dir zu glauben. Aber wenn es so ist, dann ist die Email des Bahnbeauftragten nicht nur missverständlich ausgedrückt, sondern falsch. Da steht ausdrücklich, dass mit Hilfe des Kontrolldatensatzes das Ticket auf Gültigkeit überprüft wird. Dann kann ich nur nocheinmal fragen: wieso sollten wir Dir eher glauben, als der Email des Bahnbeautragten und den AGB der Bahn?

--Olenz 08:36, 7. Apr. 2007 (CEST)

Ich habe ja auch nicht die gemachten Änderungen kritierst, denn erst seitdem ist der Artikel gut. Mir ging es um etwaige Änderungen in der Zukunft. Ich habe keine Quellen für meine Aussagen, aber ich will ja auch gar nichts an dem Artikel verändern. Zu meinem Wissen: Ich gebe nur das wieder, was in der Eisenbahnfachwelt allgemein bekannt ist. Mit allgemein bekannt meine ich, dass es z.B. in bestimmten Foren (in denen auch viele Bahnmitarbeiter schreiben) als unbestritten im Raum steht. Ich selber habe an dem Verfahren weder mitgearbeitet, noch habe ich in anderer Form beruflich damit zu tun. Ich habe mich nur schon mit einigen (auch mir persönliche bekannten) Bahnmitarbeitern ausführlich über die Funktionsweise unterhalten und alle haben mir das gleiche erzählt. Das kann natürlich alles falsch sein, aber ich glaube ihnen mehr als Deinen Vermutungen, vor allem weil es auch viel plausibler klingt. Ich sehe auch nicht, wo die von mir beschriebene Funktionsweise sich in irgendeiner Form mit von Dir erwähnten Quellen widerspricht. Wenn Du das Thema Kontrolldatensatz ohnehin nicht in den Artikel einarbeiten möchtest, brauchen wir uns ja auch nicht weiter drüber streiten. Gibt es denn noch andere Punkte, in denen zwischen uns kein Konsens herrscht und die für den Artikel relevant sind? Dann werde ich mir die Mühe machen und nach Quellen suchen. Ansonsten kann ich z.B. das Forum http://www.drehscheibe-online.de empfehlen, das ist die größte Bahnplattform im Netz. Im dortigen "Allgemeinen Forum" wird man Dir denke ich alle Fragen beantworten können und das aus erster Hand. Die Suchfunktion ist auch hilfreich, da das Thema dort schon öfters behandelt wurde. Leider sind die Foren derzeit etwas langsam.169.229.55.85 11:16, 7. Apr. 2007 (CEST)

Na also! Danke für diese Informationen! Ich hoffe, Du verstehst, dass ich ungehalten war. Ich konnte einfach überhaupt nicht einschätzen, woher Du Dein Wissen hast, und leider finden sich bei Wikipedia zu viele Leute, die sich nur wichtig tun müssen.

Ich komme tatsächlich von einer ganz anderen Seite: ich bin (größtenteils) Informatiker, und habe eine starkes, hobbymässiges Interesse an Dingen wie Datenschutz und Sicherheit, inklusive den zugehörigen Verfahren. Deswegen auch mein Interesse an diesem Artikel - das ist nämlich tatsächlich mal eine funktionierende Anwendung asymmetrischer Verschlüsselungsverfahren.

Ich bin tatsächlich davon ausgegangen, dass das Online-Ticket so funktioniert, wie es mit Hilfe der verfügbaren Techniken am Sinnvollsten wäre, und bin damit schon ziemlich weit gekommen - habe mich aber im Detail der Kontrolldatensätze geirrt. Diese habe ich ursprünglich gar nicht herausgekramt, sondern Dr. Xorx, der darin sein (selbsterfundenes?) Datenbankverfahren wiedzufinden meinte. Und dem habe ich widersprochen.

Jetzt, da ich weiss, woher Du Dein Wissen beziehst, glaube ich Dir durchaus, was den Kontrolldatensatz angeht. Mich überrascht es bloss, dass die Bahn sich scheinbar tatsächlich auf rechtlich problematische Regressforderungen verlässt, um Mehrfachnutzer zu überführen. Zumal eine technische Lösung durchaus machbar wäre, soweit ich das einschätzen kann. Vielleicht frage ich dazu tatsächlich nochmal im von Dir erwähnten Forum.

Ansonsten sollte ich mein Verfahren vielleicht mal der Bahn vorstellen... P-) Oder vielleicht hat die Bahn solch eine Lösung sogar im Hinterkopf, aber noch nicht implementiert. Das würde auch die missverständlichen Formulierungen in der Email erklären.

Was den Artikel angeht, bleibt für mich noch, die Perspektive des Abschnittes "Sicherheit" geradezuziehen und einige seltsame Formulierungen aufzuräumen.

--Olenz 17:54, 7. Apr. 2007 (CEST)

Online-Ticket der Deutschen Bahn

mögliches Verfahren

Als mögliches Verfahren wird oft Patent DE19823907: "Verfahren zur Bereitstellung von Berechtigungsnachweisen", Hüttinger, Stephan, Dipl.-Math., 1999-12-02.‌ angeführt. Dieses gleicht tatsächlich dem wahrgenommen eingesetzten Verfahren, und nimmt sogar selber Bezug auf die Bundesbahn. In Details wie "Die TicketCard hat keine Bezahlfunktion." finden sich aber Abweichungen, wenn man Patent-TicketCard mit Bahn-Ausweis-ID gleichsetzt. Weitere mögliche Verfahren ergeben sich aus zitierenden Patenten.

Außerdem existiert mit UIC 918-3 "International Rail Ticket for Home Printing" ISBN 2-7461-1307-4 ein Standard aus der Branche. Dieser ist leider nicht frei einsehbar, -- Jjaf.de 05:44, 22. Mär. 2009 (CET)

Mobiles Terminal 2 (MT 2)

Im Zug wird das OT durch ein durch die Systemtechnik GmbH Sömmerda modifiziertes und programmiertes Windows-CE basiertes Casio IT-3000 geprüft. S.a. "High-Tech im Verborgenen", Bahn-TV 2006-11-06, 18:40/28:37.

Durch die Ausbaustufe mit Kartenleser und C-MOS-Imager (Barcodeleser, der möglicherweise auch als Digitalkamera verwendet werden kann) dürfte die Basis ein IT-3000M55E sein.

-- Jjaf.de 19:43, 23. Mär. 2009 (CET)

Barcode

Der Barcode des Mustertickets MDB46140 enthält neben dem Start folgende Inhalte. Ein Programm, das die Inhalte des Barcodes entpacken und menschenlesbar darstellen kann findet sich dort: http://itooktheredpill.dyndns.org/public.git/onlineticket/onlineticket.py (nicht signierter Beitrag von 78.46.98.198 (Diskussion | Beiträge) 14:02, 4. Apr. 2010 (CEST))

Start

#	Beschreibung	Bemerkung
1	Header	"#UT" für UIC Ticket
2	Version	"01"
3	Ticketaussteller	"0080"/"1181" (RICS-Code) CIV-/TCV-/UIC-Carrier-Code. DBAG "0080" statt "1080"!
4	key-id	"00001" welcher Schlüssel wurde zum signieren benutzt
5	Signatur	50 Bytes, 0x00-padded. ASN.1 Notation der DSA Signatur über die komprimierten Daten

Signaturen-Block

#	Beschreibung	Bemerkung
1	0x2C	Länge folgender "Signatur-Block"

Signatur-Block

... soviel "Signaturen-Blöcke" wie in die oben angegebene Länge passen (normalerweise 2).

#	Beschreibung	Bemerkung
1	0x02	TBD: Datentyp 2
2	0x14	Länge der folgenden "Signatur"
3-	Daten

TBD: Möglicherweise handelt es sich dabei um zwei Signaturen: Eine vom komprimierten und eine vom deflateden "Ticket-Block". (falsch).

Die Signatur erfolgt nur über die komprimierten Daten, allerdings mit DSA. Die zwei "Signaturen" sind in Wahrheit die r und s Parameter des DSA Algorithmus. (nicht signierter Beitrag von 77.20.193.204 (Diskussion) 13:54, 13. Aug. 2014 (CEST))

Ticket-Block

#	Beschreibung	Bemerkung
0	DWORD-padding	DBAG 0x00, ÖBB "0" ;-)
1	"0290"	Länge der folgenden "Ticket-Daten"
2	0x789C	"zlib-Header"
3-	zlib-Daten

-- Jjaf.de 05:44, 22. Mär. 2009 (CET) -- Jjaf.de 01:01, 4. Jan. 2010 (CET)

komprimierter Datenblock ("Ticket-Daten")

Dieser enthält alle Fahrangaben außer Reservierungen und die Ausweis-ID (hier hervorgehoben), den Zeitpunkt der Ausstellung mit Minutengenauigkeit und Seriennummern nach unterschiedlichen Nummernkreisen für BC und Fahrkarten.

Die intensive Verwendung von "DE" ISO_3166-2:DE und "80" UIC-Ländercode deutet auf eine internationale Ausrichtung hin.

Zur besseren Lesbarkeit wurden Zeilenumbrüche und im Falle der "S-Datensätze" Leerzeichen eingefügt:

U_HEAD
010053
0080
U46CLS
-7
 ��
31012008
1733
0
DEDE
0080
ID
02
0018
04
3864
0080
BL
02
03
31
04
2
20MKGRPHT9V
 65 
31.03.2
31032008
01042008
6024936 
22MXFCUPYZG
           
31032008
30042008
6024937
14
S001 0011 Normalpreis
S002 0001 2
S003 0001 A
S004 0001 A
S009 0006 1-1-78
S012 0001 0
S014 0002 S1
S015 0015 Frankfurt(Main)
S016 0011 Berlin+City
S017 0011 Berlin+City
S018 0015 Frankfurt(Main)
S021 0019 VIA: GOE*(H/BS)*SDL
S023 0014 Mustermann Eva
S026 0002 12

-- Jjaf.de 05:44, 22. Mär. 2009 (CET)

UIC 918.3 Datenblock

Jeder Datenblock beginnt mit dem hier aufgeführten Header.

Die ID beinhaltet bei UIC-Internen Datenblöcken den Präfix "U_" und einen 4-stelligen Typ.

Bei Carrier-spezifischen Datenblöcken besteht die ID aus dem vierstelligen Issuer-RISC code, sowie einer beliebig vergebbaren, zweistelligen Typen-ID.

#	Beschreibung	Datentyp	Bemerkung
1	ID	6AN	Bei UIC-Blöcken: "U_" + Typ (4), Bei Member-Specific Blöcken: RISC-Code (4) + Typ (2)
2	Version	2N	Version des Datenblocks
3	Länge	4N	Länge des Datenblocks inclusive Header (ab #1)

U_HEAD

#	Beschreibung	Bemerkung
1	Header	"U_HEAD"
2	"01"	Version 1 des Datenblocks U_HEAD
3	"0053"	Länge des Blockes ab #1
4	"0080"/"1181"	Ausstellender Carrier (s.o)
5	Auftragsnummer	DBAG = [alphanumerisch], ÖBB = [numerisch]
6	TBD	Prüfziffer der Auftragsnummer? DBAG = "-"[numerisch], ÖBB = [numerisch]
7	TBD	padding auf 20 Byte, DBAG = 0x00, ÖBB = " ", bei älteren DBAG-OT teilweise Daten im padding, evtl. data-sanitation-Problem
8	Datum der Ausstellung	Format: "DDMMYYYY"
9	Zeit der Ausstellung	Format: "HHMM"
10	Flags	"0" (Kombinationen möglich) Internationales Ticket: "1" Bearbeitet vom Schaffner: "2" Testticket: "4"
11	Ticketsprache	ISO 639-1 Länderkürzel ("DE")
12	Zweitsprache	ISO 639-1 Länderkürzel ("DE")

0080-ID

In diesem Block wird die Ausweis-ID abgelegt. Es handelt sich wohl um eine von einem größerem Standard abweichende DBAG-Erweiterung des Ticket-Blockes.

#	Beschreibung	Bemerkung
4	"04"	Art der Ausweis-ID
5	Letzte Ziffern Ausweis-ID

Ausweis-ID

Der Block enthält an Zeilen 13-14 die Art und die letzten Ziffern der der Ausweis-ID.

#	Beschreibung	Bemerkung
01	CC
04	BC
07	ec-Karte	2 Ziffern (BLZ nicht erkannt)
09	Personalausweis

-- Jjaf.de 05:44, 22. Mär. 2009 (CET)

0080-BL

#	Beschreibung	Bemerkung
4	TBD
5	Anzahl der folgenden Auftrags-Blöcke	1 bei BC oder nur Hinfahrt, sonst 2
6	Auftrags-Block/-bBlöcke	ggf. Reihenfolge Hin-, Rückfahrt
7	Anzahl S-Datensätze oder "00" bei BC
8-	ggf. S-Datensätze

-- Jjaf.de 04:45, 25. Mär. 2009 (CET)

Auftrags-Block

#	Beschreibung	Bemerkung
1	Zertifikat	derzeit 11-stellig
2	NULL-Padding auf 22 byte
3	Gültig ab
4	Gültig bis
5	S/N	8-stellig. Derzeit werden durch OT-S/N-Vergleich ca. 72.000 Fahrten/Tag gebucht. Dadurch läuft diese S/N ca. alle 3 Jahre, 10 Monate über. Letzter Überlauf ca. 2010-03-05, nächster ca. 2013-12-25.

-- Jjaf.de 04:45, 25. Mär. 2009 (CET) -- Jjaf.de 02:16, 17. Aug. 2010 (CEST)

S-Datensätze

Das Format ist ...

Saaabbbbd[...]d

... wobei aaa der Feldtyp, bbbb die Feldlänge in Byte, nicht char und d die Daten sind. Diese Unterscheidung ist deshalb relevant, weil zumindest der Personenname in UTF-8 ohne Byte Order Mark kodiert ist. Ob eine Darstellung von z.B. arabischen Namen auf dem Prüfgerät möglich ist ist nicht bekannt.

Unterschiedliche Tickets enthalten je nach Ausstellungszeitpunkt und Art eine unterschiedliche Anzahl und Kombination von S-Datensätzen. Im Falle einer vorläufigen BahnCard gar keine.

Aus ausgelesenen OT lassen sich folgende Feldzuordnungen ableiten:

#	Beschreibung	Bemerkung
001	Preismodell	Normalpreis Sparpreis 25 / 50 Dauer-Spezial Rail&Fly 1.Klasse-Spezial Auftragsnummer RDN7FU: Menschlesbar "Dauer-Spezial, 2. Klasse", maschinenlesbar "1.Klasse-Spezial, 2. Klasse"?!
002	Produktklasse Gesamtticket	numerisch 0 = C, 1 = B, 2 = A
003	Produktklasse H	ABC bei Rail&Fly
004	Produktklasse R
009	[Anzahl Erwachsene]-[Anzahl BC]-[BC-Art]	BC: 49 = BC25, 19,78 = BC50
012	[Anzahl Kinder]
014	{S-[Klasse], [Klasse]}	ohne "S" auf älteren OT
015	H-Start-Bf
016	H-Ziel-Bf
017	R-Start-Bf
018	R-Ziel-Bf
019	Vorgangsnr./Flugscheinnr.	Rail&Fly
020	Vertragspartner	Rail&Fly Partner Airline
021	VIA
023	Personenname	(max. Länge 19)
026	Preisart	12 = Normalpreis, 13 = Sparpreis, 3 = Rail&Fly
027	TBD: CC-#/Ausweis-ID	vollständige(!) CC-#; 2010-01-03/; trotz weiterhin bestehendem Feld Ausweis-ID; Evtl. zum Fahrplanwechsel zur Einführung der ID Personalausweis eingeführt? -- Jjaf.de 11:04, 3. Jan. 2010 (CET)

-- Jjaf.de 05:44, 22. Mär. 2009 (CET)

U_TLAY

Dieser Datentyp kommt bei BC und "Freitext"-Tickets zum Einsatz, welche auf RCT2-Basis ausgestellt werden.

U_TLAY
010305
RCT
2000
5
00120339000
76
BAHNCARD                TYP HK 35
VORLÄUFIGE BAHNCARD 25
inklusive RAILPLUS
00520319000
61
Nur gültig bei Vor-
lage eines amtlichen
Lichtbildausweises
03010150400
45
Gültig vom 14.03.2009 Gültig bis 13.05.2009
06660105000
01
2
08010470000
37


Inhaber(in):Franke, Jano John Akim

#	Beschreibung	Bemerkung
1-3	s. "U_HEAD"	Datentyp hier "U_TLAY"
3	"RCT2"	Rail Combined Ticket 2 UIC 918-2
4	Anzahl RCT2-Textblöcke
6-	RCT2-Textblock

-- Jjaf.de 04:45, 25. Mär. 2009 (CET)

RCT2-Textblock

1	Zeile	"00"-"14"
2	Spalte	"01"-"68"
3	Höhe	"01"-"04"
4	Breite	"000"-"999"
5	Formatcode	0: Normal 1: Fett 2: Kursiv 3: Fett + Kursic 4: Klein 5: Klein + Fett 6: Klein + Kursiv 7: Klein + Fett + Kursiv
6	Länge des Textes

-- Jjaf.de 04:45, 25. Mär. 2009 (CET)

Diskussion zu Format Online-Ticket

Das ist ja alles ganz interessant... aber was sollen wir damit hier jetzt anfangen? Woher kommt das Material eigentlich? Hast Du das Urheberrecht daran?

-- Olenz 10:33, 22. Mär. 2009 (CET)

Was damit anfangen? Der Artikel enthält z.B. einen Abschnitt über die Angaben im Barcode. Dieser ist verkürzt. Nachdem ich die vorherige Diskussion aus 2007 gelesen habe, die IMHO u.a. an dem Mangel an belastbaren Quellen leidete und ich in der Recherche keine spezifischeren Informationen gefunden habe, sondern viel Mystik allein durch den Barcode denke ich mir es könnte bei zukünftigen Definitionen helfen ein wenig auf Fakten am Beispiel des Mustertickets zu basieren.

Außerdem könnten Personen aus "Welche Daten stehen in dem Zertifikat?" das "Zertifikat, dem Code, der auf dem Online-Ticket aufgedruckt ist" mit dem Barcode verwechseln. Letzterer enthält aber entgg. dem menschlich lesbaren Aufdruck teils sehr persönliche Angaben, denn außer dem Namen und ob ich eine "richtige" Kreditkarte besitze kann man ja auch erkennen, ob ich mein Ticket in der Arbeitszeit, während eines Fußball-Länderspiels oder tief in der Nacht gebucht habe. Wenn also jemand vor der Entscheidung steht seinen Ausdruck jemand anderem zu übergeben, kann er ohne technische Hilfsmittel nicht erkennen, dass er mehr Daten aus der Hand gibt als er darauf lesen kann.

Woher stammt das Material? Dieses habe ich selbst ohne Verletzung des Hackerparagraf ermittelt, nachdem ich letzte Woche für einen Hamburg-Besuch ein OT verwendet habe und wissen wollte, welche Daten auf dem Barcode enthalten sind und wie das Prüfungsverfahren technisch realisiert ist. Ich dachte die Quelle wäre in diesem Fall ersichtlich.

-- Jjaf.de 17:10, 22. Mär. 2009 (CET)

Die obigen Abschnitte wurde nachträglich von einem Benutzer ohne Account verändert. Mir scheint diese Änderung gutwillig, deshalb lasse ich sie mal stehen, will aber trotzdem lieber darauf hinweisen. @Jjaf.de: FYI, auch wenn du schon ein Weilchen nicht mehr aktiv bist. --nenntmichruhigip (Diskussion) 20:07, 31. Mär. 2017 (CEST)

Änderungen beim OnlineTicket und die Geschichte passt auch nicht

Heute geht auch die legitimation im Zug über einen Personalausweis bzw. Reisepass. Auch ist die Benutzung durch die Bundeswehr möglich, und da erfolgt die Kontrolle Anhand des Truppenausweises (PKZ).

Auch war es nicht das Surf & Rail Ticket, das als erstes als OnlineTicket erstellt wurde, sondern ein Abkommen zwischen der Bahn und Siemens, die ihrer Firmenreisen so buchte (über die Siemens Corporate AmericanExpressCard) (nicht signierter Beitrag von 79.225.191.143 (Diskussion) 20:50, 24. Aug. 2010 (CEST))

Identifikationsdiebstahl

Zitat "Dadurch gerät der reguläre Käufer in den Verdacht einer Mehrfachnutzung, den er nicht ohne Weiteres entkräften kann." - Den Verdacht kann man sehr einfach entkräften. Wenn jemand meine Geldbörse stiehlt oder auch nur den Personalausweis, die EC oder die Kreditkarte, dann ist dies in jedem Fall Meldepflichtig. Es werden das Einwohnermeldeamt (bei Personalausweis-Diebstahl), die Polizei und/oder die Bank (EC/Kreditkarte) benachrichtigt. Da der Diebstahl der Polizei gemeldet wird und zu Protokoll gegeben wird, kann ein ID-Diebstahl vor der Bahn bewiesen werden. -- Wurde die ID-Karte ABSICHTLICH einem Mitfahrer gegeben, dann liegt in der Regel keine Anzeige bei der Polizei vor und folglich kann die Bahn ihren Verdacht erhärten. --87.165.165.248 23:02, 13. Jun. 2011 (CEST)

Wobei das nicht zwangsläufig ist:

Natürlich musst Du den Verlust des Personalausweises unverzüglich melden, Voraussetzung für die Meldung ist aber, dass Du den Verlust überhaupt erst einmal bemerkt hast. Es lassen sich Fallkonstellationen bilden, bei denen zwischen dem Verlust/Diebstahl und der Meldung Wochen oder gar Monate liegen können. Bei der EC-Karte ist eine Verlustmeldung hingegen überhaupt nicht zwingend vorgeschrieben, hier bewirkt die Meldung lediglich eine Verschiebung des Risikos - ohne Meldung trägt man das Risiko des Missbrauches selber. Ich kenne genügend Leute, die ihre Karte ab und an mal „verlegen“, wenn da kein konkreter Anlass (z.B. Taschendiebstahl oder Einbruch) vorliegt, wird es da regelmäßig zu mindestens einigen Tagen Verzögerung kommen. Zudem wird der Verlust der EC-Karte, allemal wenn diese vermeintlich verloren wurde, nicht der Polizei sondern der ausgebenden Bank angezeigt. Eine nicht vorliegende Anzeige bei der Polizei lässt daher keineswegs den zwingenden Verdacht zu, dass hier eine ID-Karte absichtlich einem „Mitfahrer“ gegeben wurde. Die zitierte und kritisierte Aussage ist daher uneingeschränkt richtig. --Hmwpriv 08:50, 14. Jun. 2011 (CEST)

Annerkennung im Ausland beim Online-Ticket bei der Deutschen Bahn

Es gibt ein Problem mit der Anerkennung des Online-Tickets im Ausland. Habe es jetzt zweimal persönlich erlebt. Der ungarische Schaffner weigerte sich das ausgedruckte Ticket, welches noch nicht von einem österreichischen oder deutschen Kollegen kontrolliert und mit Zangenabdruck versehen war, anzuerkennen. Der ungarische Schaffner hat nach eigener Auskunft keine Möglichkeit die Gültigkeit des Tickets zu überprüfen. Kompromissbereitschaft a la "Wir warten auf den österreichisen Kollegen an der Grenze und lassen den die Gültigkeit bestätigen" - Fehlanzeige. Folge: Normalpreisticket bis zum Grenzbahnhof kaufen zuzüglich der Platzreservierung. Die Platzreservierung kostet sonst nicht viel, ist im internationalen Verkehr sogar gar nicht erforderlich, hier kostet sie dann 10,00 EUR! Also: 21,60 EUR für die Fahrt von Budapest nach Mosonmogyorovár plus 10,00 EUR = 31,60 EUR Nachzahlung. Keine Kartenzahlung möglich, aber in HUF oder EUR... Wow! Ob der jeweilige Online-Ticket-Besitzer von der DB oder ÖBB da wohl was erstattet bekommt?

Frage an die Experten: Wie kann der ungarische Schaffner die Gültigkeit des Online-Tickets überprüfen? Österreichische und deutsche Schaffner wussten erstmal keinen Rat. - MfG M (nicht signierter Beitrag von 88.77.108.196 (Diskussion) 04:24, 7. Jan. 2014 (CET))