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.
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 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.
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, 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.
Ok, danke, die Aussage genügt mir
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.
@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.
"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.
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.
"
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."
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.