abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du: 

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

Link zum Beitrag wurde kopiert.

Gelegentlicher Autor
  • Community Junior
  • Community Junior
  • Community Junior
  • Anerkannter Autor
  • Community Beobachter
Beiträge: 10
Registriert: 06.10.2016

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.

57 Antworten 57

Enthusiast
Beiträge: 790
Registriert: 08.12.2014

Hallo @mxscho,

 

1. Ein 5-stelliges Passwort hilft nicht gegen Bruteforce? Bin ich 100% bei Dir. Ich verwende bei Verschlüsselung mindestens 25 stellen alphanumerisch+Sonderzeichen. Bei WLAN noch deutlich mehr (und es nerv gewaltig das bei irgendwelchen Consumer-Geräten ohne Tastatur einzutippen, aber kürzer kann ichs WLAN gleich offen lassen).

 

2. Dein zweiter Punkt leitet aber sehr schön ein, wieso das für das Login-Thema auch gleich total irrelevant ist weil, kein Bruteforce möglich ist.

Ja, Passwortklau, stimmt, das ist ein riesen Problem. Allerdings wer soweit in die Systeme eingedrungen ist an die Passworttabellen zu kommen, braucht sicher nicht Dein Passwort um an Deine weiteren Daten zu kommen. Somit gibt es eine ganz simple Lösung, die auch allgemein bekannt sein sollte: Pro System ein eigenes Passwort. 5 Stellen sollten genug Variationsmöglichkeiten bieten für eine große Anzahl von Logins eigene PINs zu wählen.

 

3. TAN-Generator auch für den Login nutzen? Also mein persönlicher Sicherheitsbedarf ist jetzt nicht so hoch, dass ich das unbedingt benötigen würde. Wäre das aber optional zuschaltbar, für die Kunden die etwas mehr möchten, wieso nicht? Ich denke hier wäre tatsächlich ein signifikanter Sicherheitsgewinn zu erreichen. Vor allem weil, anders wie die Flackercode-Geräte, der Consorsbank TAN-Generator recht gut für so was geeignet wäre, denke ich. Guter Gedanke! Da würde ich auf jeden Fall parallel eine Idee in den Ideen-Bereich einstellen.

 

Gruß

Myrddin


Enthusiast
Beiträge: 220
Registriert: 30.11.2014

Gibt es hierzu von Consors etwas neues?

0 Likes

Gelegentlicher Autor
  • Community Junior
  • Community Junior
  • Community Junior
  • Anerkannter Autor
  • Community Beobachter
Beiträge: 10
Registriert: 06.10.2016

Hi @Myrddin,

 

danke für deine unvoreingenommene Stellungnahme.

Ein Teilgedanke hinter dem Erstellen eines weiteres Threads bezüglich der Thematik war auch mit dieser 3. Punkt. Ich wollte ganz einfach nicht, dass das irgendwie in den Antworten eines anderen Threads untergeht.

 

Zu 2.:

Ich verstehe vollkommen, was du meinst - und hab mir darüber auch schon während meines ersten Posts Gedanken gemacht, aber aufgrund der Länge und Komplexität dann doch verzichtet, darauf einzugehen.
Deswegen an dieser Stelle:

Im Bereich IT-Sicherheit gibt es leider keinen vollständigen Schutz. Den wird und den kann es nie geben. Daher geht es meist darum, die Angriffsvektoren und das Risiko zu minimieren. Man muss also immer zwischen Risikominimierung und Entwicklungsaufwand abwägen.

Im Falle der Beschränkung der Passwortlänge sehe ich allerdings eine mir nicht nachvollziehbare Entscheidung, da ich mir nicht vorstellen kann, dass der Aufwand, längere Passwörter zu speichern den Aufwand, ein System zu entwerfen, das dies explizit verbietet, übersteigt.

In einem sicheren System sollte ein Passwort in einer Datenbank niemals im Klartext gespeichert sein, sondern vorher kryptographisch gehasht worden sein. Dazu verwendet man zudem Pepper und Salt, was gewisse Angriffe nahezu ausschließt. Wichtig ist dabei, dass der Pepper an einer anderen Stelle im System gespeichert ist, als die eigentlichen Passwort-Hashes. Damit erreicht man, dass beide Teile für sich alleine nicht brauchbar für einen Angreifer sind. Was das Beispiel zeigen soll:

Ein sicheres System ist selbst gegen die Entwickler dessen bestmöglichst geschützt.
Das Argument, dass wenn jemand bis zu der Passwortdatenbank vorgedrungen ist, er noch viel mehr machen könnte, ist also eher schwach. In einem sicheren System sollte dies nämlich ausgeschlossen sein.

Da die Consorsbank uns aus sehr verständlichen Gründen wohl kaum ihr gesamtes Sicherheitskonzept erläutern wird, müssen wir in dieser Hinsicht auf die Kompetenz der IT-Abteilung vertrauen, was auch soweit vollkommen in Ordnung ist.
Es gibt allerdings Bereiche, die in der IT-Sicherheit und in der Kryptographie gerne doch der Allgemeinheit anvertraut werden. Das fängt bei der Benutzung von bekannten, öffentlichen kryptographischen Algorithmen an und hört - und das ist jetzt meine Ansicht - bei der Bereitstellung eines adäquaten Passwortwahlmechanismus auf.

Selbst wenn alle Consorsbank-Mitarbeiter vertrauenswürdig sind, muss dies nicht für die Serverbereiber gelten. Möglicherweise sind bestimmte Teile der IT-Infrastruktur ausgelagert. Möglicherweise werden die Server von einem anderen Unternehmen gehostet, die nur als Dienstleister arbeiten. Das ist durchaus gewöhnlich, ich habe selbst bereits in einem derartigen Unternehmen gearbeitet.

Bitte nicht falsch verstehen - ich möchte hier niemandem auf den Schlips treten! Es muss nicht einmal die Schuld eines Mitarbeiters sein. Systemfehler, Bugs, Exploits, ein Hacker, eine andere Schwachstelle. Ein Programm, das eine neue Sicherheitslücke besitzt. Es geht nur um Risikominimierung. Ich hasse diesen Satz selbst, aber: Es geht um's Prinzip. Und ich sehe wirklich kein Argument für die bewusste Einführung (und ich sehe es nicht als Feature es zu entfernen, ich denke die Limitierung des Passworts ist gewollt!) einer begrenzten Passwortlänge, die im Endeffekt keinen Beitrag zur Verbesserung der Sicherheit darstellt.

Mich würde an dieser Stelle einfach auch nur das offizielle Statement dazu interessieren, warum es Sinn macht, die Passwortlänge zu begrenzen. Und nochmal: Ich denke, dass diese Designentscheidung so getroffen wurde und es nicht andersherum ist - nämlich dass es aufwändiger gewesen wäre ein längeres Passwort zuzulassen.

An dieser Stelle auch nochmal der Hinweis auf diesen Artikel, der das in noch ausführlicherer Weise beschreibt: https://www.troyhunt.com/the-cobra-effect-that-is-disabling/

Zumindest mir sind keine in Deutschland oder sonstwo auf der Welt bekannten anerkannten Regulatorien oder Standards in Erinnerung, die eine Beschränkung der Passwortlänge als gutes Sicherheitsmerkmal einstufen. Falls doch, lass ich mich gerne überraschen.

 

TL;DR: Mir würde also tatsächlich eine offizielle Antwort ala "wir haben das damals so gemacht, es ist aber vielleicht wirklich nicht so gut - es ist für uns aber aktuell zu aufwändig, das zu ändern" mehr zufriedenstellen als die Aussage "das ist sicher, Ende".
Denn dass wir hier eine große Sicherheitslücke haben, habe ich nie behauptet. Es geht mir nur um die Transparenz, die man in diesem Punkt umsetzen sollte.


Anders für den 2FA-Vorschlag: Das ist wirklich etwas, das mir wirklich am Herzen liegen würde.
In Zeiten, in denen ohne 2FA nicht mal die Accounts von Mark Zuckerberg vor feindlicher Übernahme sicher sind, sollte man vielleicht auf diesen Zug aufspringen.

Passwort-Dumps/Leaks sind heutzutage keine Seltenheit mehr. Mit 2FA wäre das nicht passiert.

Und ich bin mir durchaus bewusst, dass gerade stark regulierte Bereiche wie der Bankensektor bei sowas immer noch hinterherhinken. Also wieso nicht als positives Beispiel vorangehen mit vollständiger (!) 2FA? (Quelle: https://twofactorauth.org/)

 

Tut mir Leid für die Länge meiner Posts, aber vielleicht interessiert es ja tatsächlich irgendwen. 🙂


Moderator
Beiträge: 20
Registriert: 29.06.2016

Hallo @mxscho, hallo @Myrddin, hallo @WilhelmTell,

liebe Community,

 

wir freuen uns, dass auch Ihnen, so wie uns, die Sicherheit sehr wichtig ist. Wir haben daher nochmals Rücksprache mit den für dieses Thema zuständigen Kollegen gehalten. Diese werden Ihnen in den nächsten Tagen an dieser Stelle eine Rückmeldung geben. Bis dahin bitten wir Sie noch um etwas Geduld.

 

Beste Grüße

 

CB_Ramona

Community Moderatorin


Community Manager
Beiträge: 1768
Registriert: 13.01.2014

Hallo @mxscho, hallo @Myrddin, hallo  @WilhelmTell,

liebe Community Mitglieder,

 

vielen Dank für Ihre Beiträge und Ihr Interesse an den Sicherheitsmaßnahmen der Consorsbank.

Dass das Thema Sicherheit der PIN ein absolut wichtiges Thema für Sie ist, und daher immer mal wieder in der Community angesprochen wird, können wir sehr gut nachvollziehen.

 

Um Ihre Frage mit dem nötigen fachlichen Wissen zu beantworten, sind wir auf die Kolleginnen und Kollegen aus dem IT-Bereich zugegangen. Mit folgenden Ausführungen möchten wir Ihnen insbesondere die technischen Hintergründe  unseres PIN-Verfahrens erläutern.

 

Wir stimmen Ihnen zu: 1 Milliarde Kombinationen sind mit heutiger Rechenkapazität schnell durchprobierbar.

Jedoch unter der Voraussetzung, dass der Angreifer ohne Zeitverzug jede Kombination testen kann.

Dies ist jedoch nur möglich, wenn der Angreifer die zugrunde liegende Datenbank zur Verfügung hat. Ein kombinatorischer Angriff auf Login/Passwort-Felder scheitert somit allein deshalb, weil es eine Response-Time gibt.

 

Selbst wenn der Login nur 0,3 Sekunden braucht, wären 10 Jahre nötig alle Kombinationen zu probieren. Wohlgemerkt: Pro Kontonummer. Dem entgegen steht zudem der dreimalige Fehlversuch. Ein Angriff auf ein Konto über die Webseite ist also nicht zu vergleichen mit einem Angriff auf die Passworttabellen selbst und somit für einen Angreifer schlicht unwirtschaftlich.

 

Was tut die Consorsbank zum Schutz der internen Systeme? Damit möchten wir auf den zweiten Aspekt Ihrer Frage eingehen, den Schutz der Datenbanken. Bitte haben Sie Verständnis, dass wir aus Sicherheitsgründen nicht allzu detailliert auf all unsere Sicherheitsmaßnahmen eingehen können.

 

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

 

Einen Angriff über Rainbowtables o.ä. sehen wir somit für "die nächste Zeit" als sehr unwahrscheinlich an. Dieses Verfahren schützt die PINs im Übrigen auch gegenüber dem theoretisch internen Angreifer.

Dem Eindringen in unsere internen Systeme begegnen wir mit mehrschichtigen und breiten Schutzmaßnahmen nach aktuellem Stand der Technik sowie angemessenen organisatorischen Maßnahmen.

 

Wir möchten Ihnen abschließend versichern: über die gängigen Sicherheitsmaßnahmen hinaus trifft die Consorsbank weitreichende und tiefgehende Maßnahmen zum Schutz ihrer Kunden.

 

Ich hoffe, wir können Ihnen damit etwas mehr Einblick in die Hintergründe zur Sicherheit der 5-stelligen PIN bringen.

 

Beste Grüße aus Nürnberg,

Sonja

Community Moderator

 


Gelegentlicher Autor
  • Community Junior
  • Community Junior
  • Community Junior
  • Anerkannter Autor
  • Community Beobachter
Beiträge: 10
Registriert: 06.10.2016

Hallo,

 

vielen Dank für das Statement.

ich werde den ersten Teil des Posts deshalb ignorieren, weil es a) stimmt und b) nicht relevant ist, wie ich bereits erörtert habe.

 

Ein Salt verhindert den von mir beschriebenen Angriffsvektor nicht. Ein Pepper in gewisser Weise schon. Das mit den Rainbowtables stimmt auch, aber ich empfinde es nicht nur als schlimm, wenn alle Passwörter bekannt werden - sondern auch schon, wenn das eines einzelnen Users bekannt wird. Leider wurde nicht darauf eingegangen, worum es mir eigentlich ging: Nämlich diese Sicherheit nicht vertrauensbasierend zu versprechen, sondern sie dem Benutzer durch die Möglichkeit der eigenen Bestimmung zu gewährleisten. Denn Vertrauen ist gut, Kontrolle ist besser.

Meine Frage war nicht, ob es sicher ist (denn natürlich ist es das in jedem Fall bis zu einem gewissen Level), sondern warum man eine Designentscheidung vertritt, eine noch bessere Sicherheit aktiv zu verhindern.

 

Abschließend möchte ich noch einen Thread einer renommierten IT-Sicherheits-Frage/Antwort-Plattform zitieren:

What technical reasons are there to have low maximum password lengths?

 

Take five chimpanzees. Put them in a big cage. Suspend some bananas from the roof of the cage. Provide the chimpanzees with a stepladder. BUT also add a proximity detector to the bananas, so that when a chimp goes near the banana, water hoses are triggered and the whole cage is thoroughly soaked.

Soon, the chimps learn that the bananas and the stepladder are best ignored.

Now, remove one chimp, and replace it with a fresh one. That chimp knows nothing of the hoses. He sees the banana, notices the stepladder, and because he is a smart primate, he envisions himself stepping on the stepladder to reach the bananas. He then deftly grabs the stepladder... and the four other chimps spring on him and beat him squarely. He soon learns to ignore the stepladder.

Then, remove another chimp and replace it with a fresh one. The scenario occurs again; when he grabs the stepladder, he gets mauled by the four other chimps -- yes, including the previous "fresh" chimp. He has integrated the notion of "thou shallt not touch the stepladder".

Iterate. After some operations, you have five chimps who are ready to punch any chimp who would dare touch the stepladder -- and none of them knows why.


Originally, some developer, somewhere, was working on an old Unix system from the previous century, which used the old DES-based "crypt", actually a password hashing function derived from the DES block cipher. In that hashing function, only the first eight characters of the password are used (and only the low 7 bits of each character, as well). Subsequent characters are ignored. That's the banana.

The Internet is full of chimpanzees.


These restrictions are often put in place for various reasons:

  • Interaction with legacy systems that do not support long passwords.
  • Convention (i.e. "we've always done it that way")
  • Simple naivety or ignorance.

Quelle: https://security.stackexchange.com/questions/33470/what-technical-reasons-are-there-to-have-low-maxi...

 

In diesem Sinne.

Danke, dass auch auf meine anderen Vorschläge eingegangen wurde im Hinblick auf die 2-Faktor-Authentifizierung. Anscheinend ist es wohl wichtiger, die Leiter zu beschützen.

Keine weiteren Fragen.


Enthusiast
Beiträge: 220
Registriert: 30.11.2014

Guten Tag CB_Sonja,

gibt es zu diesem Thema etwas Neues?

 
0 Likes

Gelegentlicher Autor
  • Community Junior
  • Community Beobachter
  • Kommentator
  • Beitragsunterstützer
Beiträge: 5
Registriert: 15.11.2016

 

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

 

Hm diese Beschreibung passt aber absolut nicht zu dem Thema. "Geben sie bei der Hotline die xte und yte Stelle der Pin an". Damit könnten sie nämlich gar nicht anfangen, wenn die Pins gehashed wären, da sie mit diesen 2 Stellen den Hash nicht errechnen können. Irgendwas stimmt da nicht. Bitte um Aufklärung!

 

ich meine das hier:

https://wissen.consorsbank.de/t5/Sonstige-Themen/Sprachcomputer-will-2-Stellen-der-PIN-wissen/m-p/24...

 


Gelegentlicher Autor
  • Community Junior
  • Community Beobachter
  • Kommentator
  • Beitragsunterstützer
Beiträge: 5
Registriert: 15.11.2016

Und nochwas. Wenn ich zugriff auf die Datenbank habe, dann helfen ihnen all ihre Salts nichts, Ein brauchbarer Rechner brauch max. 1Sekunde pro passwort. D.h. in 2 Wochen habe ich alle Passworte aller Kunden.

0 Likes
Antworten