Sicherheit der 5-stellige PIN, 2-Faktor-Authentifzierung (TAN) für Login

[mxscho]

Hallo,

ich weiß, dass das Thema gerade erst aktiv behandelt wurde (https://wissen.consorsbank.de/t5/Feedback/Sicherheit-der-5-stelligen-PIN/td-p/32883), möchte aber nochmals ausführlich auf das offizielle Statement eingehen. Möglicherweise gibt es auch weitere Informationen oder regulatorische Problematiken, über die noch nicht offziell informatiert wurde.

Es wurde zwar bereits "abschließend geklärt", diese Aussage ist allerdings nach meiner informationstechnischen Ansicht nicht haltbar.

In der FAQ befindet sich ein Artikel bezüglich der Sicherheit der 5-stelligen PIN.
Hier: https://wissen.consorsbank.de/t5/PIN-TAN/Ist-meine-5-stellige-PIN-sicher/ta-p/15827

Aus IT-sicherheitstechnischer Sicht ist die Argumentation leider (auch aus meiner Sicht) nicht ausreichend, um die Sicherheit eines Accounts vor Missbrauch zu beweisen.

Hier kurz meine Kommentare zu den in dem Artikel genannten Argumenten.

• „Die 5-stellige alphanumerische PIN schütz Ihren Kontozugang sehr effektiv. Die Kombination aus fünf Buchstaben (jeweils in Groß- oder Kleinschreibung) und Zahlen bedeutet, dass es nahezu eine Milliarde verschiedener Möglichkeiten gibt, die PIN zusammenzusetzen.“

Dieses Argument spielt auf einen Brute-Force-Angriff an, bei dem Passwörter durch Ausprobieren erraten werden können. Die These ist, dass 1 Milliarde Möglichkeiten für Passwörter ausreichen sollten, um sie nicht in hinnehmbarer Zeit zu erraten.
Nach kurzem Googeln findet man allerdings schnell zahlreiche Artikel, die belegen, dass es (je nach verwendetem Passwort-Aufbewahrungs-Algorithmus) durchaus möglich ist,  ein Passwort mit 1 Milliarde möglichen Kombinationen innerhalb von Sekunden zu knacken.
Beispiel: https://www.heise.de/security/meldung/Rekorde-im-Passwort-Knacken-durch-Riesen-GPU-Cluster-1762654.h...

• „Die Wahrscheinlichkeit, dass ein Angreifer die richtige PIN errät, ist außerordentlich gering. Zudem hat ein Angreifer nicht unendlich viele Möglichkeiten, um die richtige PIN zu finden. Nach drei Fehlversuchen wird der Konto-/ Depotzugang gesperrt, somit ist eine sogenannte ‘Brute-Force-Attack‚ bei der computerunterstützt einfach alle theoretisch denkbaren xxx Mio. Kombinationen ausprobiert werden, nicht möglich. “Die Wahrscheinlichkeit mit drei Versuchen unsere fünfstellige PIN zu erraten, liegt bei rund 1 zu 300 Mio.“

Die Einschränkung der Versuche, über das Online-Portal Passwörter zu erraten, ist selbstverständlich und gängige Praxis bei sämtlichen Passwort-basierenden Authentifzierungs-Diensten/Services. Es ist allerdings nicht der einzige Angriffsvektor für Passwort-gesicherte Dienste. Irgendwo müssen die Passwörter nämlich auch in einer Datenbank gespeichert sein (bestenfalls in verschlüsselter Form), auf die möglicherweise auch noch andere Leute als der Benutzer Zugriff haben (z.B. Entwickler, Administratoren, Mitarbeiter, Server-Provider-Mitarbeiter/Entwickler/Administratoren) oder eben Hacker, die es geschafft haben, in irgendeinem Glied dieser Kette Datendiebstahl zu begehen.

Gelangt jemand in den Besitz dieser Datenbank, ist es mit einem vielstelligen Passwort, das unter Verwendung von sicheren kryptographischen Algorithmen geschützt wurde, auch für diese Menschen oder Hacker nicht möglich, das Passwort aus dem Datendiebstahl zu rekonstruieren.

Wer garantiert, dass sich in dieser Kette nicht eine einzige nicht vertrauenswürdige Person befindet? Wer garantiert, dass keine Person oder Maschine in dieser Kette jemals einen Sicherheits-relevanten Fehler begeht?

Es mag überzogen klingen - aber in Zeiten, in denen wöchentlich größere Datenverluste auch von großen oder sogar in der IT angesiedelten Unternehmen bekannt werden, ist dies nur eine Frage der Zeit, bis derartiges jede Unternehmung treffen kann.

Wäre die Möglichkeit eines mehrstelligen Passworts gegeben, hätte der Benutzer selbst die Möglichkeit, derartige Gefahrenszenarien zu eliminieren.

• „Mit der PIN alleine können keine Transaktionen ausgeführt werden. Für jede Überweisung etc. ist zusätzlich eine TAN notwendig. Und die Verwendung der mobilen TAN oder des TAN Generators erhöht die Sicherheit auf ein Maximum.“

Natürlich ist es selbstverständlich, dass in der heutigen Zeit das Angebot von 2-Faktor-Authentifzierung Pflicht sein sollte, wenn es um vertrauliche Daten geht. Die TAN ist eine Form der 2-Faktor-Authentifzierung. Leider deckt diese nicht vollständig den Bereich aller vertraulichen Daten ab. Kontostand, Kontoauszüge und andere vertrauliche Informationen sind nicht durch die TAN geschützt und können direkt nach Login eingesehen werden.

Denn was beispielsweise auch ein sicheres Passwort nicht verhindern kann, ist den Diebstahl des Passworts durch Malware (wie beispielsweise einen Keylogger). Ohne TAN/2-Faktor-Authentifzierung beim Login ist es für Malware/Viren ein Leichtes, sämtliche vertrauliche Informationen nur mithilfe des gestohlenen Passworts einzusehen.

Meine Vorschläge zur Verbesserung der Sicherheit sind daher:

- Aufheben der Passwort-Maximallänge (und die damit verbundene Softwareänderung) und Beibehaltung wirklicher Passwortverbesserungs-Kriterien (wie beispielsweise die bereits vorhandene Pflicht, Groß- und Kleinbuchstaben sowie Zahlen zu verwenden).

- Erweiterung der gültigen Passwort-Zeichen um Sonderzeichen, falls nicht vorhanden.

- Einführung der Möglichkeit, Webseiten-Logins mithilfe von TANs bestätigen zu müssen.

Viele für Anwender im Vergleich als unkritischere Services im Vergleich zu Online-Banking bezeichnete Dienste bieten bereits diese Form der Sicherheit. Für Online-Banking sollte es daher in jedem Fall ebenfalls so sein.

Meine Änderungsvorschläge beinhalten zudem einen optionalen Charakter, d.h. für User, denen ihre Sicherheit nicht so sehr am Herzen liegt, würde sich meiner Einschätzung nach zudem nahezu nichts ändern.

Für affine Interessierte hier vielleicht auch noch ein meiner Meinung nach anderer sehr interessanter Artikel bezüglich der Sache mit der Einschränkung der zulässigen Passwörter:
https://www.troyhunt.com/the-cobra-effect-that-is-disabling/

Ich erwarte kein vollständiges Verständnis für meinen erneuten Diskussionsanstoß, aber anscheinend hilft in diesem Fall (nämlich das Verbessern der Sicherheit) nur die Wiederholung von bereits häufig genannten Argumenten.

Viele Grüße
Maximilian S.

[AccessDenied]

@immermalanders, würdest du mir bitte einen Link zu solch einem Verfahren zukommen lassen?
Ja, die 2FA ist also eigentlich schon umgesetzt, allerdings nur auf Nachfrage am Telefon. Eine andere Möglichkeit wäre die Verwendung eines speziellen Telefonpasswort, was wohl der derzeitige Standard bei anderen Anbietern ist.

[immermalanders]

@AccessDenied, das ist doch recht einfach zu machen. Beim Übermitteln den neuen Passworts liegt dieses im Klartext vor. Jetzt bildet man die Kombinationen aus den abzufragenden Stellen und speichert den entsprechenden Hash in der Datenbank ab. Jetzt kann man die Eingabe der zwei Stellen jeweils mit dem entsprechendem Hash vergleichen. So würde ich das umsetzen.

[AccessDenied]

@immermalanders

Ok, danke, die Aussage genügt mir

[mxscho]

Weil das jetzt schon mehrfach angesprochen wurde:
Es ist vollkommen irrelevant, in welcher Form das Password/die PIN gespeichert wird.
Ein Hash (egal in welcher Form, selbst ein aufwändig zu berechnender) schützt 1 aus 5^10 möglichen Zeichenketten nicht vor Offline-Brute-Force.

Wenn ich raten müsste, würde ich sagen, dass die PINs vermutlich im Klartext abgespeichert sind. Möglicherweise sogar verschlüsselt (aber nicht gehasht), um irgendwelche Regularien zu erfüllen.

Die Bank ist vermutlich der Ansicht, dass ein Offline-Angriff oder ein Leak der Datenbank sowieso den Super-GAU darstellt und es damit Risikomanagement-technisch von Belangen ist, sich diesbezüglich abzusichern.

Der Schutz des Verfahrens beruht aktuell auf der Tatsache des Lockouts bei zu vielen Fehlversuchen.

Ein Problem könnte sein: Angenommen, jemand im Besitz eines Botnets mit bspw. > 10.000 verschiedenen IP-Adressen probiert nun bei 10.000 verschiedenen Accounts dasselbe Passwort (am besten noch eines der oft genutzten Kombinationen).
Wie hoch ist die Chance, sich an nur 1 der Accounts anzumelden?
Der IT-Sicherheits-Maximalist würde sagen: Inakzeptabel hoch.

Die Bank sagt (vermutlich): Wir haben genug Kapital, um den Schaden in so einem Fall auszugleichen.
Es kann natürlich auch einfach sein, dass derartige Angriffe auf andere Weise bspw. automatisiert erkannt und damit abgewehrt werden.

Das, was mich daran stört, ist eigentlich nur, dass ich in jedem Satz das Wort "vermutlich" benutzen muss, weil dieses Risikomodell nicht in zufriedenstellender Weise kommuniziert werden kann, weil die Bank nicht möchte, dass ihr Risikomodell bekannt ist.

Dies könnte man umgehen, indem man auf Vorschläge eingeht wie bspw. optionales 2FA beim Login zu ermöglichen, denn dann wäre man nicht mehr in der Bringschuld, sondern es wäre für jeden offensichtlich, dass das System bspw. gegen den zuvor angeführten Angriff abgesichert wurde.

Ich für meinen Teil hab aber mittlerweile einfach hingenommen, dass in 2018 jeder einzelne meiner Social-Media-Zugänge mehr abgesichert erscheint als sämtliche Accounts von Unternehmen aus stark regulierten Sektoren.

[immermalanders]

@mxscho, da wir nicht wissen, wie die Passwörter gesichert sind, ist das alles reine Spekulation. Wird das Kennwort verschlüsselt oder "nur" als Hash gespeichert, könnte das im Finanzsektor gegen diverse Vorgaben verstoßen. Da in diesem Sektor regelmäßiger Audits stattfinden (sollten), wird an dieser Stelle sicherlich immer weiter nachgerüstet. Eine genaue Auskunft wird man dazu nicht bekommen.

[expat]

"Ein Problem könnte sein: Angenommen, jemand im Besitz eines Botnets mit bspw. > 10.000 verschiedenen IP-Adressen probiert nun bei 10.000 verschiedenen Accounts dasselbe Passwort (am besten noch eines der oft genutzten Kombinationen)." (mxscho)

Mal zwei Gedanken dazu:

- Der Angreifer hat beim Login nur drei Versuche. Danach ist das Login gesperrt. Passiert sowas kurz hintereinander bei einer ganzen Anzahl Accounts, ruft das (hoffentlich) die IT Security der Bank auf den Plan. In jedem Fall aber war der Angriff dann ein Misserfolg.

- Angenommen, der Login / Angriff funktioniert tatsächlich bei dem einen oder anderen Konto aufgrund der hohen Anzahl (IMHO unwahrscheinlich): Was macht der Angreifer dann? AFAIK benötigt man für alle relevanten Transaktionen den TAN Generator.

[AccessDenied]

Der Angreifer weiß dann wem er ggf. mal einen Besuch abstatten sollte, da er für die Einsicht in die Vermögensbestände keine TAN benötigt.
Wie wird dieser Schaden quantifiziert? Wer würde in diesem Fall darauf vertrauen, dass die Consorsbank einen darüber informiert, so sie es denn überhaupt selbst mitbekommen?
Das ist schon ein gewaltiges Pokerspiel was die Consorsbank hier treibt. Leider bietet aber meines Wissens so gut wie keine Bank eine 2FA an. Allerdings werde ich da zumindest nicht nach meiner PIN gefragt und der Login ist nicht identisch mit meiner Kontonummer.

[Sikk]

Wenn sich ein Angreifer Zugriff auf ein Kundenkonto verschafft hat, kann er natürlich noch keine Transaktionen durchführen, richtig. Er hat aber dafür Zugriff auf die (verifizierten) persönlichen Daten des Kunden. Ist DAS nicht schon Grund genug, die 2FA einzuführen?
Name, Adresse, Geburtsdatum, Mobilfunknummer, das alleine sind Daten, die in einschlägigen Kreisen eine Menge Geld wert sind. Dazu kommen noch die Daten übers Konto und das Depot: Wieviel Geld kommt rein, wo geht es hin? Wie legt er sein Geld an, eher vorsichtig und auf Sicherheit bedacht oder doch eher hohes Risiko? Das macht den Datensatz gleich noch wertvoller.

Mit diesen Daten kann man auch wunderbar bei Consors (oder anderswo) anrufen und sich für den Kunden ausgeben. Ich will das gar nicht weiter ausmalen.

Ein Blick auf das Referenzkonto, bei einer anderen Bank? Mal schauen, ob die PIN dort auch funktioniert? Ist natürlich Schuld des Kunden, aber wer "12345" als Passwort nimmt, macht auch sowas. Und Consors verhindert die 12345 _nicht_ als PIN, ich habe das ausprobiert, als ich mich das erste Mal dafür interessierte (und natürlich sofort wieder geändert).

Vielleicht würde es die Consorsbank auf die eigene Kappe nehmen, wenn doch irgendwie Geld verloren ginge, aber ganz bestimmt nicht ohne den Rechtsweg und der ist für den Kunden wesentlich anstrengender als für die Bank. Wenn man bei einem fehlerhaften Login eine Nachricht darüber bekäme, und sei es nur eine E-Mail, besser natürlich eine TAN, dann wäre man als Kunde ja wenigstens gewarnt.

Ich habe in den letzten paar Tagen zweimal meine PIN falsch eingegeben und keine Mail darüber bekommen, dafür bekam ich für jede Antwort, die seit gestern hier einging eine gesonderte Mail. Es geht doch offenbar und es kostet auch nichts. Und wenn ich zwei Euro von einem auf das andere Konto verschiebe, bekomme ich eine TAN, um das abzuschließen, warum denn nicht auch beim Login? (Ja, Community und Bank sind unterschiedliche Systeme und blablabla, aber um hier in der Community zu posten muss ich drüben in der Bank eingeloggt sein...)

Jetzt fange ich schon an zu schimpfen und höre besser auf 🙂 Sorry dafür.
Aber wenn Consors einmal gehackt wird, wird auch diese Diskussion hier wieder ans Licht gezerrt und man wird nicht sagen können, man hätte von nichts gewusst...

[Sigrid_W]

@Sikk

Ja, Community und Bank sind unterschiedliche Systeme und blablabla, aber um hier in der Community zu posten muss ich drüben in der Bank eingeloggt sein...

Das liegt aber daran, dass Du Dich mit Deinem Banklogin bei der Community angemeldet hast.

Ich habe zwei vom Banklogin unabhängige Community-Accounts (einer davon zu Testzwecken angelegt).

Ich wäre aber auch dafür, dass beim Banklogin zumindest nicht die Kontonummer zur Anmeldung genutzt würde. Und zusätzlich eine TAN wäre auch nicht schlecht.

[cym80]

@mxscho:

"

Wenn ich raten müsste, würde ich sagen, dass die PINs vermutlich im Klartext abgespeichert sind. Möglicherweise sogar verschlüsselt (aber nicht gehasht), um irgendwelche Regularien zu erfüllen."

Dann hör doch auf zu raten und lies, was dir bereits in 2016 mitgeteilt wurde:

"Soviel sei verraten: die Passwörter werden in den Datenbanken gehashed gespeichert, mit Pepper und pro Kunde individuellem Salt."

https://wissen.consorsbank.de/t5/Feedback/Sicherheit-der-5-stellige-PIN-2-Faktor-Authentifzierung-TA...

Klar, wenn jemand tatsächlich offline Zugriff auf die DB erhalten würde, hilft das auch nur begrenzt. Aber wir dürfen doch sicherlich hoffen, dass in einem solchen Fall die DB schnellstens vom Netz genommen würde.