Vorschläge einblenden
Mit der automatischen Vorschlagsfunktion können Sie Ihre Suchergebnisse eingrenzen, da während der Eingabe mögliche Treffer angezeigt werden.
Suchergebnisse werden angezeigt für
- Wissen
- :
- Informationen zu mxscho
Informationen zu mxscho
seit
06.10.2016
28.07.2021
mxscho
Gelegentlicher Autor
10
Beiträge
47
Likes
0
Lösungen
Die Implementierung einer 2-Faktor-Authentifizierung wird ein Element unserer Weiterentwicklungen sein. Einen konkreten Umsetzungszeitpunkt kann zum derzeitigen Stand nicht kommuniziert werden. Quelle: @CB_Michael, 28.11.2016 @CB_Kai Das ist jetzt 1,5 Jahre her. Ist die Consorsbank transparent genug, um den Grund anzugeben, warum es aktuell noch kein 2FA für Login gibt?
... Mehr anzeigen
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.
... Mehr anzeigen
Übrigens: Dass damals zur aktiven Zeit dieses Threads mein Vorschlag, 2FA beim Login zu ermöglichen (Opt-in wäre vorerst völlig ausreichend), anscheinend doch wieder vollständig über Bord geworfen wurde, empfand ich als wesentlich unbefriedigender als diese sinnbefreiten Versuche, eine begrenzte Passwortlänge zu rechtfertigen. Vielleicht hab ich aber auch einfach gelernt meine Zeit nicht damit zu verschwenden, gegen eine Wand zu sprechen. Die Leute, die ich mit diesen Sicherheitsbedenken wohl am ehesten ansprechen würde, sind sowieo vermutlich aktuell mit anderen Dingen am ripplen. 😉
... Mehr anzeigen
@as_no5 Nagut. Ich sehe natürlich ein, dass in den anderen Threads teilweise tatsächlich Unwahrheiten verbreitet werden/wurden. Bevor du mir vorwirfst, dass ich Äpfel mit Birnen vergleiche, solltest du auch den ersten Teil des Threads nochmal lesen, in dem ich meinte, dass genau der von dir erwähnte 3-Versuche-Online-Brute-Force-Angriffsvektor irrelevant und nicht wichtig für die Diskussion ist. Wie du so schön beschreibst sitzt das Problem vor dem Rechner, womit wir bei diversen "ITlern" aus der System-am-Laufen-halten-Abteilung wären. Außerdem habe ich bereits erläutert, warum es keinen Nachteil, sondern nur Vorteile bringen würde, meine Vorschläge umzusetzen (und dass ich auch keinem User etwas aufzwingen wollen würde, wenn sie das Alte beibehalten wollten) - will mich jetzt aber nicht wiederholen. Übrigens: Meine Passwörter sind im Schnitt keine 16, sondern eher 32-64 Zeichen lang. Und ja, ich tippe die tatsächlich nicht ein. Nicht einmal in dem Moment, wo ich sie zufällig generiere. Für sowas gibt es KeePass, 1Password, LastPass o.ä. Falls das jemand für paranoid hält: Gerne, akzeptiere ich. Siehe 2 Sätze weiter vorne. 🙂
... Mehr anzeigen
@CB_Michael Danke für's Weiterleiten. Die Antwort war tatsächlich noch etwas positiver als die Resonanz zuvor. Vielleicht steigt die Signifikanz ja noch an. @as_no5 Ich bin zwar nicht ganz sicher, in wie weit uns diese relativ irrelvante Korrektur der Zeitkomplexitätsabschätzung und das darauffolgende Totschlagargument (?) weiterhelfen, aber aufgrund der Tatsache dass du die Antwort noch 1:1 in drei weitere Threads gespammt hast nehme ich einfach mal an, dass du alle vorherigen Aussagen natürlich auch vollständig gelesen und in deinen Gedankenprozess mit einbezogen hast, nicht wahr? 😉
... Mehr anzeigen
@immermalanders Ich weiß nicht, ob ich dich zu 100% verstanden hab, da ich leider die App noch nicht benutzt habe. Basierend auf der Aussage "warum sie in der App keine mTAN mehr nutzen können": Ist damit gemeint, dass der Funktionsumfang der App in etwa dem der Weboberfläche entspricht und man dort ebenfalls beispielsweise eine Überweisung durchführen kann und es in diesem Fall ausreicht, diese dann mit einer TAN, die per mTAN mit demselben Gerät per SMS empfangen wurde, zu bestätigen? Falls das tatsächlich so ist (ich weiß es leider nicht), ist das ja sowieso eigentlich keine (gute) 2FA. Prinzipiell ist es eigentlich nie wirkliche 2FA, wenn man für beide Faktoren dasselbe Gerät bzw. dasselbe Betriebsystem benutzt (in dem Fall das Smartphone). Dass das nicht ausreichend sicher ist, um als annehmbare 2FA durchzugehen, wurde bereits mehrmals klargestellt: - https://www.heise.de/newsticker/meldung/32C3-pushTAN-App-der-Sparkasse-nach-wie-vor-angreifbar-3056667.html Manche gehen sogar so weit, SMS nicht als eigenen Faktor zu akzeptieren, da es ein Leichtes zu sein scheint, per Social Engineering SIM-Karten von anderen Personen zu bekommen und deren SMS mitzulesen: - https://techcrunch.com/2016/07/25/nist-declares-the-age-of-sms-based-2-factor-authentication-over/ - http://fortune.com/2016/06/27/two-factor-authentication-sms-text/ Aber das ist ein anderes Thema. Falls ich dich richtig verstanden habe, sehe ich aber prinzipiell kein Problem in der Tatsache, dass die Sicherheit für Mobilkunden nicht steigt. Warum müsste man es für Mobilkunden deaktivieren? Meine Idee war es ja, die 2FA optional auch für den Login freizuschalten. Das würde ja (nach meinem Verständnis, bitte korrigiert mich) ja prinzipiell nur die Sicherheit der Browser-Nutzer verbessern, aber nicht gleichzeitig die der Mobil-Nutzer verschlechtern, die bliebe ja einfach gleich. Und für den Rest würde sich nichts ändern. (Genau wie bei der Sache mit dem Passwort. Die Maximallänge anzuheben ändert grundsätzlich erst einmal nichts für andere Nutzer. Ich möchte ja mit meinem Feedback kein Unmensch sein. Mir ist die Abwägung zwischen Sicherheit und Nutzerfreundlichkeit sogar sehr bewusst, sonst würde ich noch ganz andere Dinge vorschlagen. Deswegen ist mir diese Ignoranz gegenüber diesem Feedback ja so unverständlich - es sei denn, jemand erläutert mir die bürokratische Komplexität, warum es nicht möglich ist, ein System zu bauen und Angestellte zu beschäftigen, die dieses System in annehmbarer Zeit an die selbstverständlichen Sicherheitsstandards des Jahres 2016 anpassen können. Wenn es tatsächlich auch nur eine Frage des Geldes ist - na dann Hut ab zu dieser Entscheidung.)
... Mehr anzeigen
Wie bereits schon erwähnt, will ich niemandem persönlich auf den Schlips treten. Man muss allerdings eingestehen, dass das dem Kunden einer Bank wie dieser, die weiterhin die Strategie fahren will, auf Sicherheitsbedenken nur mit Inkompetenz oder Ignoranz zu reagieren, nicht weiterzuhelfen scheint. Da es anscheinend doch immer wieder Leute gibt, die es tatsächlich interessiert (und ich weiß wirklich nicht warum ich noch mehr Argumente für meinen Standpunkt bringen muss): Das NIST (Bundesbehörde der USA u.a. für Sicherheitsstandards) arbeitet gerade (mal wieder) an einem Entwurf für die aktualisierten/neuen Authentifikations-Richtlinien, die von der kompletten Regierung (und besonders im öffentlichen Bereich) eingehalten werden müssen. Hier einige kurze Auszüge dazu: NIST’s new guidelines say you need a minimum of 8 characters. NIST says you should allow a maximum length of at least 64, so no more “Sorry, your password can’t be longer than 16 characters.” Applications must allow all printable ASCII characters, including spaces, and should accept all UNICODE characters, too, including emoji! Und besonders: "This is great advice, and considering that passwords must be hashed and salted when stored (which converts them to a fixed-length representation) there shouldn’t be unnecessary restrictions on length." Quellen: Ganzer Artikel (Englisch) NIST Digital Authentication Guideline (Public Preview) Wenn man bedenkt, dass bei dieser Bank hier keine einzige dieser Anforderungen auch nur ansatzweise erfüllt ist, muss man sich nicht wundern, warum Deutschland in vielen Bereichen anderen Ländern so weit hinterher ist, wenn es um (Achtung, Buzzword) Digitalisierung geht. Diese Bank ist keine Ausnahme. (Mal ganz zu schweigen von der Tatsache, dass mein 2FA-Vorschlag den ich hier gemacht habe komplett unter den Tisch gekehrt wurde). Euer Verfahren ist nicht sicher. Tut was dagegen.
... Mehr anzeigen
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-maximum-password-lengths 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.
... Mehr anzeigen
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. 🙂
... Mehr anzeigen
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.html „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.
... Mehr anzeigen
Letzte Likes von:
