Die Deutsche Bahn ermöglicht die Nutzung von SMS-Codes oder Authentifikator-Apps für die 2FA. Allerdings gibt es während und nach der Einrichtung einige Fallstricke. Eine besonders kritische Situation entsteht, wenn der Zugang über die Authentifikator-App verloren geht. Ich würde mir wünschen, dass die Bahn eine Möglichkeit zur Sicherung und Wiederherstellung anbietet für die man keine Hotline bemühen muss.

Fehlende Backup-Codes

Ein großes Manko scheint mir die fehlende Möglichkeit zu sein, Backup-Codes herunterzuladen. Backup-Codes sind entscheidend, besonders wenn der Zugang über die Hauptmethode verloren geht. Es sind vorab generierte Codes, die du sicher aufbewahren kannst. Im Falle, dass du keinen Zugriff auf deine Haupt-2FA-Methode (z.B., wenn du dein Handy verlierst oder die Authentifikator-App nicht funktioniert) hast, kannst du diese Backup-Codes verwenden, um dich dennoch anzumelden.

Begrenzte Möglichkeiten nach Einrichtung

Nach erfolgreicher Einrichtung einer der beiden Methoden ist es scheinbar nicht möglich, eine zweite Methode hinzuzufügen. Auf Grund der fehlenden Backup-Codes wäre das eine gute Möglichkeit den Zugriff auf sein Konto sicherstellen zu können. Hilft die Bahn dir im Worst-Case wenigstens mit guten Hilfetexten weiter?

Fehlermeldungen und Support

Wenn man dann doch keinen Zugriff auf seinen zweiten Faktor mehr hat, steht man erst einmal alleine da. Die Login-Maske fordert stur die Eingabe des 2-Faktor-Codes. Gibt man einen falschen ein, erscheint lediglich „Ungültiger Authentifizierungscode“. Der Link „Login-Daten vergessen?“ ist nach Eingabe des Passworts bereits verschwunden – und würde auch nicht weiterhelfen. Zum Glück gibt es ein FAQ zur 2-Faktor-Authentifizierung. Die muss man aber erst einmal finden. Zum Glück erscheinen die relevanten Fragen aber auch dann, wenn man „2-Faktor“ in das Suchfeld der allgemeinen „Hilfe & Kontakt“-Seite für Privatkunden eintippt.

FAQ

Die FAQ spricht in der relevanten Hilfe-Seite zwar nur davon, was man bei verlorenem Zugriff auf SMS-Codes tun kann. Ich gehe aber davon aus, dass die Antwort bei Nutzung einer Authentifikator-App die gleiche wäre: „Bitte kontaktieren Sie unser Service-Team unter 030 2970.“ Dauer der Bearbeitungszeit: Bis zu einer Woche!

Insbesondere die Dauer für die Rücksetzung der 2FA könnte für viele Kunden problematisch sein. Hier muss die Deutsche Bahn die Prozesse optimieren, um eine schnellere Unterstützung zu gewährleisten. Ist man auf Reisen unterwegs und hat sein Ticket nur in der App dabei, verliert aber – aus welchen Gründen auch immer – den Zugriff auf sein Bahn-Konto, wird man im Zweifelsfall ein zweites Ticket kaufen müssen.

Mein Fazit

Insgesamt gibt es großen Raum für Verbesserungen bei der 2FA der Deutschen Bahn. Eine erhöhte Flexibilität bei der Einrichtung durch die Möglichkeit der Einrichtung mehrer 2Fa-Methoden, klare Anweisungen bei Problemen und eine schnellere Unterstützung durch den Kundenservice könnten die Nutzererfahrung erheblich verbessern. Und die Deutsche Bahn würde davon auch profitieren: Durch eine Entlastung ihrer Support-Hotline. Aktuell kann ich die Einrichtung der 2-Faktor-Authentifizierung bei der Deutschen Bahn nur bedingt empfehlen.

Update (07. November 2025)

Ich habe heute noch einmal geprüft, ob es inzwischen möglich ist weitere Methoden in der Kontoverwaltung der Deutschen Bahn hinzufügen. Das ist zwar immer noch nicht möglich, allerdings kann man inzwischen „Ersatzcodes aktivieren“ – also Backup Codes erstellen. Dies sollte man auch unbedingt tun. Ist ein Login mit dem eingerichteten zweiten Faktor z.B. wegen Verlust nicht mehr möglich, kann man mit diesen Codes doch noch Zugriff auf sein Konto erhalten.

Wichtig bleibt: Diese Backup Codes sind letzten Endes TAN-Listen und sollten den gleichen Schutz wie dein Passwort erhalten. Um die Wirkweise als zweiten Faktor zu erhalten, solltest du diese z.B. nicht im gleichen Passwort-Manager wie dein Passwort ablegen. Durchaus empfehlenswert kann es aber sein, die Liste auszudrucken und zuhause an einem sicheren Ort zu verwahren (z.B. in einem Dokumenten-Safe). Bleibt dann nur zu klären, wie man auf einer Reise an diese Codes gelangt.

Mein Fazit bleibt daher unverändert: Die Bahn sollte weitere alternative Faktoren anbieten. Dann könnte ich bei Verlust meines Telefons z.B. noch ganz einfach Zugang über meinen FIDO2-Sicherheitsschlüssel erhalten.

Den MHPG habe ich im Februar 2017 vorgestellt. Er basiert auf einer Idee von Tim Anderson und generiert dir mithilfe eines Master-Passworts dienstespezifische Passwörter, sodass mehrfach genutzte, gleiche Passwörter der Vergangenheit angehören. Das Tool ist komplett in HTML und JavaScript geschrieben, es werden keine Daten an meinen Server gesendet.

Mithilfe der neuen Auto-Copy-Funktion werden erzeugte Passwörter sofort in deine Zwischenablage kopiert. So entfällt lästiges manuelles Kopieren der Passwörter. Zusätzlich ermöglicht dies, dass das Passwort nicht mehr im Klartext ausgegeben werden muss. Stattdessen wird das Ergebnis nur noch mit den klassischen Punkten angezeigt. So kann niemand das Passwort mitlesen, wenn er dir über die Schultern schaut.

Möchtest du das Passwort doch einmal im Klartext sehen, so kannst du es dir mit einem Klick auf das Augen-Symbol ganz einfach anzeigen lassen (und ggf. auch manuell kopieren, falls es mit der Automatik mal nicht klappen sollte).

Warum ist das so? In den FAQ schreibt der DFB:

Es gibt gesetzliche Datenschutzrichtlinien für die Verarbeitung von personenbezogenen Daten. Diese Richtlinien wurden auch in DFBnet umgesetzt. Sofern Sie eine DFBnet-Zugangskennung haben, mit der personenbezogene Daten verarbeiten werden, müssen Sie in regelmäßigen Abständen einen Passwortwechsel durchführen. Je nach Sicherheitsanforderung kann dies im Abstand zwischen 90 bis 180 Tagen sein. Die DFBnet-Kennungen, die kein Recht auf die Verarbeitung von personenbezogenen Daten haben, sind so eingestuft, dass die Passwörter dort nicht ablaufen. Ein Beispiel hierfür sind die Kennungen zur Ergebnismeldung.

Das Argument ist nicht von der Hand zu weisen, denn ich kann dort zum Beispiel von allen Spielern, die an einem Spiel teilgenommen haben oder auf der Auswechselbank saßen Namen, Vornamen und Geburtsdatum einsehen. Ob aber ein häufiger Wechsel von Passwörtern sinnvoll ist, darf bestritten werden.

Nutzer tendieren dazu, ihre Passwörter nur leicht abzuändern, wenn sie dazu gezwungen werden.¹ Aus Me1nGeheimesPasswort wird dann vielleicht Me1nGeheimesPasswort42 und beim nächsten Wechsel aus diesem dann wiederum Me1nGeheimesPasswort73. Solche minimalen Änderungen stellen jedoch kein großes Problem für Angreifer dar. Viele der Passwörter lassen sich so relativ leicht knacken.

Wann wechselt man sein Passwort?

Auch wenn die Wissenschaft heute zeigt, dass ein erzwungener Passwortwechsel allerhöchstens mäßigen Nutzen und manchmal sogar den gegenteiligen Effekt hat, kann es dennoch sinnvoll sein, das eigene Passwort hin und wieder zu ändern. Und zwar in diesen zwei Fällen:

1. Hin und wieder, wenn einem gerade danach ist, denn dann denkt man sich auch ein gutes neues Passwort aus.
2. Wenn man ein schlechtes Gefühl hat, weil man beispielsweise eine unverschlüsselte Verbindung genutzt hat oder das Passwort auf einem fremden oder mit Malware befallenem System genutzt hat.

Vertrauenswürdige Geräte

In unserem Fall ist der zweite Punkt sehr interessant. Dafür musst du wissen, dass das Konzept des DFB für die Eingabe der Spielberichtsdaten vorsieht, dass der Schiedsrichter nach dem Spiel den Computer des Heimvereins nutzt. Das ist meistens ein Notebook oder ein Desktop-PC und kann hin und wieder mal ein Tablet sein. Häufig stehen diese Geräte einfach in der Schiedsrichterkabine, sind manchmal in einem eigenen Geschäftszimmer untergebracht oder werden extra von zu Hause mitgebracht und dann im Vereinsheim neben die Theke gestellt. Die Anbindung an das Internet erfolgt auch bei Desktop-PCs auf Grund mangelndem Festnetzanschluss häufig per Mobilfunk. Ob notwendige Aktualisierungen des Betriebssystems oder Browsers, die häufig einige hundert Megabyte betragen, durchgeführt werden, darf zumindest bezweifelt werden. So oder so, eines haben sie alle gemeinsam: Es sind keine vertrauenswürdigen Geräte.

Möchte ich also dem Datenschutz wirklich genüge tun, müsste ich direkt nach der Eingabe der Spieldaten mein Passwort ändern. Denn es reicht ein installierter Keylogger² aus, um mein Passwort in Erfahrung zu bringen. Dieser könnte in einem besonders krassen Szenario sogar vom Heimverein selbst auf den PC installiert worden sein, um die Daten vom Schiedsrichter oder vom Gastverein, der häufig ebenfalls den PC zur Eingabe der Startelf vor dem Spiel nutzt, abzugreifen.

Viele Schiedsrichter pfeifen nicht nur ein Spiel in der Woche, sondern mehrere. Häufig eines am Samstag in der Jugend und eines am Sonntag bei den Männern oder Frauen. Sie müssten also zwei Mal in der Woche ihr Passwört ändern. Also im Schnitt nicht alle 180 Tage, sondern alle drei bis vier Tage. Das ist offensichtlich, wie meine Mathe-Dozenten gerne sagten, keine gute oder praktikable Lösung.

Der zweite Faktor

Eine gute Lösung für dieses Problem wäre eine Zwei-Faktor-Authentifizierung. Dabei loggt man sich nicht nur mit seinem Passwort (Wissen) ein, sondern es benötigt darüber hinaus ein zweites Merkmal. Du kennst dieses Verfahren sicher von deinem Online-Banking. Dein Smartphone (Besitz) könnte zum Beispiel ein solches weiteres Merkmal sein. Dort würde ein für nur kurze Zeit gültiger PIN generiert werden, dem man ebenfalls zum Anmelden angeben müsste. Dieses Verfahren setzt der Google Authenticator um und es wäre ohne zusätzliche Kosten, wie zum Beispiel beim Versand einer SMS, möglich. Ein Angreifer bräuchte dann nicht nur dein Passwort, sondern auch dein Smartphone, um Kontrolle über dein Benutzerkonto zu erlangen.

Ich habe beim DFB nachgefragt, ob es aktuell geplant ist, eine solche Zwei-Faktor-Authentifizierung einzuführen. Die Antwort war negativ.

Eine Zwei Faktor Authentifizierung ist derzeit nicht geplant.

Dabei wäre das Angebot eines solchen Verfahrens leicht umzusetzen und wäre zumindest als freiwillige Option ein wichtiger Baustein der Sicherheit der personenbezogenen Daten im DFBnet. Freilich, für Schiedsrichter, die ihr Smartphone lieber zu Hause lassen, oder für solche, die keines besitzen³, müsste ein anderer Weg gegangen werden.

Was bleibt?

Du solltest auf jeden Fall für SpielPlus ein einzigartiges Passwort vergeben. Dieses sollte unter keinen Umständen noch irgendwo anders eingesetzt werden und auch keinem deiner anderen Passwörter, wie für dein E-Mail-Postfach oder Instagram-Konto, gleichen.

Unterstützt der Server auf dem die Seite liegt, erst gar keine HTTPS-Verbindungen, so bleibt einem nichts anderes übrig, als die Website nicht zu nutzen (z.B. wenn dort Passwörter oder andere sensible Daten eingegeben werden müssen) oder mit der unverschlüsselten Verbindung vorlieb zu nehmen.

Manche Website bietet jedoch die nötige Verschlüsselung an, leitet aber nicht automatisch dahin um. Tippt man also einfach example.com in die URL-Leiste des Browsers surft man weiterhin – und manchmal völlig unbemerkt – unverschlüsselt durch die Lande. Und selbst wenn man beim Eintippen der Seite auf das nötige https:// vorweg achtet, kann es sein, dass man durch absolut gesetzte Links ganz schnell wieder auf der unverschlüsselten Version surft.

Eine gute Hilfe beim verschlüsselten Surfen bietet seit einigen Jahren bereits das Plugin HTTPS Everywhere (Firefox, Chrome). Entwickelt von der amerikanischen Bürgerrechtsorganisation EFF leitet es für alle Seiten, von denen eine verschlüsselte Version bekannt ist, auf diese um.

Bei allen kleineren Seiten für die keine Umleitungsregeln im Plugin integriert sind, muss man aber selbst Hand anlegen. Bei mir war das letztens erst bei einem Browsergame nötig, welches den Login standardmäßig unverschlüsselt durchführt. Unter Firefox führt dies seit Version 51 zu einer Warnung, die vor dem Login warnt. Und das natürlich völlig zurecht. Die Betreiber der Seite scheint dies indes nicht allzu sehr zu stören. Die Bugmeldung, die ich bereits im Februar dazu aufgemacht habe, wurde zwar von einem Moderator kommentiert, ist bis jetzt aber noch nicht einmal bestätigt worden.

Eigene Regeln in HTTPS Everywhere

Eine eigene Regel hilft dabei auch in solchen Fällen sicher unterwegs zu sein und seine Passwörter nicht unbeabsichtigt, unverschlüsselt durch das Netz zu jagen. Dazu ruft man nach der Installation der Erweiterung die verschlüsselte Version der Seite auf. Dazu reicht die manuelle Eingabe des https:// vor der eigentlichen Domain, also zum Beispiel https://www.example.com. Rechts oben neben der URL-Leiste klickt man dann auf den blauen Button der Erweiterung und dann auf Erstelle eine Regel für diese Seite. Für erfahrene Anwender sind auch erweiterte Optionen vorhanden. Kenntnisse von Regular Expressions sind dann von Vorteil. Für die meisten Fälle reicht aber ein Klick auf den Button Erstelle eine neue Regel für diese Seite. Von nun an sind alle Aufrufe der Seite automatisch HTTPS-verschlüsselt.

In der Linux-Konsole wäre das zum Beispiel so möglich:

$ printf 'Geheim123:twitter.com' | sha256sum
9ffbb90ddd53fd75fd3e885791e030047a21ee57b7a54f03ecca90f9b8eff34f  -

Die ausgegebene Zeichenkette ist die hexadezimale Darstellung des 256 bit langen Hash. Dabei stellt in der Eingabe Geheim123 das konstante Passwort und twitter.com die Domain des Dienstes, in den man sich einloggen will, dar.

Vorteil: Ein Hash ist nicht umkehrbar. Das heißt, wenn das Passwort, zum Beispiel durch einen Datenbank-Hack, erbeutet wird, kann man von diesem Passwort nicht zu dem konstanten Passwort zurückkehren.

Diese Methode hat jedoch auch Nachteile: Zwar dürfte das Passwort durch seine reine Länge als sicher angesehen werden, bei den meisten Diensten im Internet wird es wohl aber nicht akzeptiert, da es die Passwortrichtlinien nicht erfüllt. Grund: Es enthält keine Sonderzeichen. Ein weiterer Nachteil ergibt sich, wenn man einmal ohne Linux-Konsole unterwegs ist, denn einen SHA-2-Hash auf Papier zu berechnen ist recht mühsam. 😉

Beiden Nachteilen begegnet der Hash Password Generator Mobile von Tim Anderson. Zum einen bist du damit nicht auf deine Konsole angewiesen und zum anderen implementiert er den PwdHash-Algorithmus von Collin Jackson. Er gibt Passwörter zurück, die auch ein Sonderzeichen enthalten, sofern das konstante Passwort ebenfalls eines enthält.

Leider ist weder die Website von Tim Anderson noch jene von Collin Jackson responsiv und sie lassen sich somit nur schlecht auf dem Smartphone nutzen. Daher habe ich das einmal selbst in die Hand genommen und den Generator von Tim Anderson nachgebaut. Er enthält ebenfalls den PwdHash-Algorithmus – ich habe allerdings den als gebrochen geltenden MD5-Algorithmus durch SHA512 ersetzt. Das wäre zwar nicht unbedingt nötig, aber es hinterlässt stets einen faden Beigeschmack, wenn man veraltete Krypto-Funktionen nutzt.

Mein Mobiler Hash-Passwort-Generator (MHPG) ist rein in HTML und JavaScript implementiert, du brauchst also keine Angst zu haben, dass ich deine Passwörter mitlesen kann, denn sie werden nicht zum Server übertragen. Wenn du mir nicht traust, darfst du dich im Code gerne selbst vergewissern und den Generator auch selbst hosten.

Wenn du HUGE nicht im Unterverzeichnis, sondern direkt im DocumentRoot aufrufen möchtest, dann kannst du noch die .htaccess-Datei dorthin verschieben und ein wenig bearbeiten.

$ cd ~/html
$ mv huge/.htacess .

Dann musst du nur noch eine Zeile in der Konfiguration ändern.

$ vim .htaccess

Die Zeile URL änderst du zu Folgendem:

'URL' => 'http://' . $_SERVER['HTTP_HOST'] . '/'

Und damit ist HUGE nun direkt unter / verfügbar.

Ich möchte dir in diesem Artikel zeigen, wie du das PHP-Framework HUGE auf einem Uberspace installierst. HUGE ist primär ein Benutzer-Authentifizerungssystem. Das Framework hat zwar sein Soft End Of Life erreicht, wird also nicht mehr mit neuen Funktionalitäten erweitert,  bekommt aber immer noch Sicherheitsupdates und Fehlerbehebungen. Auf Grund seines Fokus als Authentifizierungssystem und des KISS-Prinzips halte ich es aber als Einstieg in die Welt der Frameworks für gut geeignet.

Wem HUGE zu klein ist, dem seien an dieser Stelle die großen Brüder Yii, Symfony oder Laravel ans Herz gelegt.

Voraussetzungen

Für diese Anleitung brauchst du nur ganz wenige Voraussetzungen. Du brauchst einen Uberspace, ein wenig Erfahrung mit der Shell und SSH. In den auf diesen Artikel aufbauenden Tutorials brauchst du dann natürlich auch noch PHP- und MySQL-Skills.

Im Folgenden gehe ich davon aus, dass du dich per SSH auf deinen Uberspace geschaltet hast. Lokal auf deiner eigenen Maschine wird nichts erledigt.

Download per Git

HUGE wird (aktuell) auf GitHub gehostet und kann damit ganz einfach per Git heruntergeladen werden. Um genau zu sein lädst du dir einfach das ganze Git-Repository in dein html-Verzeichnis. Dazu wechselst du kurz dort hin.

$ cd html

Danach klonst du HUGE in deinen Uberspace.

$ git clone https://github.com/panique/huge.git

Composer

Wenn du nun im Browser das Verzeichnis huge aufrufst, erwartet dich aktuell noch ein leere weiße Seite. Du musst erst noch notwendige Abhängigkeiten installieren. Dazu benötigst du Composer. Wie du Composer auf einem Uberspace installierst, das hat zum Glück schon Dominik in seinem Blog erklärt.

Nach der Installation kannst du mittels Composer nun alle Abhängigkeiten von HUGE installieren. Dazu wechseln wir vorher noch in das Verzeichnis von HUGE.

$ cd huge
$ composer install

Avatare

Nun musst du noch kurz dem Avatar-Verzeichnis Schreibrechte gewähren, damit Nutzer dort später ihre Benutzerbildchen hochladen können.

$ cd public
$ chmod 0777 avatars

In dem Avatar-Verzeichnis liegt auch noch eine .htaccess-Datei, welche ein Flag nutzt, dass unter dem Uberspace-Setting nicht funktioniert und bei der Anzeige von Avataren zu einem Internen Serverfehler führen würde. Dazu öffnen wir die Datei mit vim (einen Schnelleinstieg in vim findest du bei scotch.io).

$ vim avatars/.htaccess

Dort findest du die Zeile php_flag engine off. Diese soll eigentlich bewirken, dass keine PHP-Dateien in diesem Ordner ausgeführt werden und so einen Schutz vor unerlaubter Code-Ausführung gewährleisten. Das klappt allerdings nur, wenn PHP als Apache-Modul ausgeführt wird, was bei Uberspace nicht der Fall ist. Wir können diese Zeile aber ersatzlos streichen, da bereits die Zeile darüber (über den Kommentaren) dies bewirken soll. Du kannst die Zeile entweder komplett entfernen oder mit einem # vorweg deaktivieren.

Konfiguration

Danach steht die Konfiguration des Frameworks an. Dazu brauchst du aber noch das Datenbankpasswort. Das findest du so heraus:

$ cat ~/.my.cnf

Unter der Zeile [client] findest du das Passwort. Mit der Maus kannst du es markieren und mittels [Strg]+[Shift]+C kopieren.

Dazu wechselst du ins Konfigurationsverzeichnis und öffnest die Konfigurationsdatei dann mit vim.

$ cd ~/html/huge/application/config
$ vim config.developement.php

Unter DB_NAME und DB_USER trägst du deinen Uberspace-Namen und unter DB_PASS dein Datenbankpasswort (mittels [Strg]+[Shift]+V) ein.

Damit das Framework sauber E-Mails versenden kann, um zum Beispiel ein Passwort-vergessen-Link zu verschicken, legst du dir noch ein E-Mailkonto im Uberspace an und gibst die Zugangsdaten in der Konfigurationsdatei an.

Dort musst du folgende Variablen anpassen: EMAIL_SMTP_HOST, EMAIL_SMTP_USERNAME, EMAIL_SMTP_PASSWORD

Außerdem schaltest du EMAIL_USE_SMTP auf true und EMAIL_SMTP_PORT stellst du auf 587. Nachtrag: Ändere außerdem noch  EMAIL_SMTP_ENCRYPTION auf tls.

Datenbank

Das Framework hat zwar jetzt Zugriff auf deine Datenbank, allerdings liegt noch kein Datenbankschema vor, liegen noch keine Tabellen drin. Die nötigen SQL-Befehle liefert das Framework unter application/_installation mit. Dort findest du drei Dateien: 01-create-database.sql, 02-create-table-users.sql, 03-create-table-notes.sql.

An den Namen der Dateien sieht man schon recht gut für was sie da sind. Die erste Datei ist ganz klein und zur Einrichtung einer Datenbank gedacht. Die brauchst du nicht, denn du hast ja schon eine Datenbank (die du oben in die Konfiguration eingetragen hast).

Die anderen zwei Tabellen sind zur Speicherung der Userdaten sowie für die Daten einer kleiner Beispielanwendung für Notizen gedacht. Diese beiden Tabellen brauchst du, allerdings musst du die Dateien noch ein wenig anpassen, denn sie verwenden den falschen Datenbanknamen huge. Eine Datenbank mit solchen Namen besitzt du allerdings nicht und kannst sie auch nicht anlegen (wenn dein Uberspace-Name nicht zufällig gerade huge lautet).

Daher ersetzt du in den zwei Dateien den Datenbanknamen mit deinem Uberspace-Namen. Dazu nutzt du das Kommandozeilen-Werkzeug sed. In dem Befehl wird die Umgebungsvariable $USER genutzt, welche durch das Terminal direkt durch deinen Uberspace-Namen ersetzt wird.

$ sed -i 's/huge/$USER/g' 02-create-table-users.sql
$ sed -i 's/huge/$USER/g' 03-create-table-notes.sql

Jetzt musst du die Befehle der beiden sql-Dateien nur noch in die Datenbank kriegen. Das erledigt der Befehl mysql für dich, dem du den Inhalt der Dateien übergibst. Auch hier nutzt du wieder die Umgebungsvariable.

$ mysql $USER < 02-create-table-users.sql
$ mysql $USER < 03-create-table-notes.sql

Finished!

Das war es! Du kannst deine Installation von HUGE nun aufrufen und dich unter login mit dem Admin-Nutzerkonto demo und dem Passwort 12345678 einloggen. Es existiert auch noch ein normales Nutzerkonto namens demo2 und dem gleichen Passwort. Am besten legst du dir direkt ein neues Admin-Konto an und löschst die beiden alten Konten.