Implementierung One-Time-Password
-
Achja, es gibt natürlich immer noch die Möglichkeit Hardware-Dongle.
Wobei nicht jeder Dongle möglich ist, es müsste einer sein der z.B. selbst Daten mit einem nicht auslesbarem Schlüssel verschlüsseln kann.
Der Schlüssel ist dann entweder fix im Dongle eingebrannt, oder kann über public key cryptography abgesichert werden.
Dann kann ein kleines Login-Hilfsprogramm (oder Browser-Plugin) die Challenge vom Server in den Dongle reinstopfen und der Dongle gibt die Response zurück. Das Shared-Secret kann der Angreifer dabei nicht auslesen, selbst wenn er vollen Zugriff auf den lokalen PC hat, da es vom Dongle geschützt wird.Und nochmal: vergiss alles was man einem User erklären müsste und/oder wozu ein Mindestmass an Intelligenz nötig ist. Sowas kann man vielleicht in einer Firma durchsetzen wenn der Chef sagt "muss"... Massiven Unmut erzeugt man damit aber auf jeden Fall, und sobald das "muss" wegfällt... => game over.
-
Ich nehme auch hustbaers Anregungen und Vorschläge auf, sie gehen allerdings teilweise weit über den Umfang hinaus, den ich verkraften kann, daher kann es durchaus sein, dass ich darauf nicht weiter eingegangen bin.
Das Kernproblem ist leider die Usability. Externe Geräte zur Authentifizierung wären prinzipiell sicherer. Allerdings ist der Aufwand besonders was die Nachbetreuung angeht wohl doch etwas zu hoch. Die Implementierung stelle ich mir dabei nicht mal unbedingt aufwendiger vor, als das von mir erdachte "neue Rad". Bloß hinsichtlich RollOut und Nachbetreuung übersteigen diese Möglichkeiten dann doch meine Kapazitäten. Allerdings empfinde ich die Authentifizierung unter Zuhilfenahme einer externen Quelle in gewissen Bereichen schon als nötig.
So ähnlich, wie ich mir das OTP anfänglich vorstellte, wurde es auch bereits von einer mir bekannten Firma umgesetzt. Allerdings reagiert die Software-Abteilung immer allergisch, wenn ich Fragen hinsichtlich meiner hier zu genüge geäußerten Bedenken kundtue, daher dachte ich mir, warum nicht einfach mal hier nachfragen.
hustbaer schrieb:
Und nochmal: vergiss alles was man einem User erklären müsste und/oder wozu ein Mindestmass an Intelligenz nötig ist. Sowas kann man vielleicht in einer Firma durchsetzen wenn der Chef sagt "muss"... Massiven Unmut erzeugt man damit aber auf jeden Fall, und sobald das "muss" wegfällt... => game over.
Deshalb reite ich ja so dermaßen drauf rum, das OTP clientseitig ohne Aufwand für den User sicherer zu gestalten. Man kann nichts von einem User erwarten, außer das, was sie bereits kennen. Da wäre also die Eingabe eines Codes mit Hilfe einer PIN schon fast das Maximum. Naja ...
SeppJ schrieb:
Also ein klassisches indiziertes TAN-Verfahren? Aber auf solch eine Karte passen nur wenige Passwörter und Mehrfachbenutzung geht nicht.
...
Oder muss er dafür ein Programm auf dem lokalen Computer nutzen? Dann hättest du doch genau das Problem erzeugt, das du lösen wolltest!Geht man bei so einer Karte davon aus, dass das abzulesende Passswort immer gleich lang ist und immer in der gleichen Richtung abgelesen werden muss, ergeben sich 30 mal 8 Startpositionen, also 240 Passwörter. Mit geringem Aufwand könnten auch noch mehr aus dieser Karte generiert werden. Mal abgesehen davon, dass man die nicht eins zu eins so übernehmen muss, sondern ja auch noch Abwandlungen treffen kann. Im Endeffekt wäre es auch nichts anderes, als das alte TAN-Verfahren. Man bekommt eine Zeile und eine Reihe und liest die Zeichen daraus ab. Ich schaue nachher mal, wie diese Idee ankommt, ansonsten habe ich ja noch einige Anregungen hinsichtlich Hardware, über die ich mir genug Gedanken machen kann. Das Verfahren via SMS steht ja mindestens auch noch zur Debatte.
Und nein, sollte nicht über eine Software geschehen, auch wenn die Karten über eine Software erstellt werden, wäre es wohl unklug, diese Software generell mit auszuliefern.
-
Fake oder Echt schrieb:
Geht man bei so einer Karte davon aus, dass das abzulesende Passswort immer gleich lang ist und immer in der gleichen Richtung abgelesen werden muss, ergeben sich 30 mal 8 Startpositionen, also 240 Passwörter. Mit geringem Aufwand könnten auch noch mehr aus dieser Karte generiert werden. Mal abgesehen davon, dass man die nicht eins zu eins so übernehmen muss, sondern ja auch noch Abwandlungen treffen kann.
30 mal 8? Du meinst wohl eher 8*8, wenn die Chance auf einfaches Raten des Passworts unter 1:1000 liegen soll. Ein einzelnes Zeichen als Passwort ist selbst bei OTP sehr, sehr unsicher. 4 sollten es schon mindestens sein.
Wenn du mit den Abwandlungen meinst, die gleichen Zeichen mehrmals zu benutzen, dann ist doch der ganze Witz des OTP dahin! Der Angreifer kennt schließlich Wert und Position eines Zeichens nachdem es einmal benutzt wurde.
-
Fake oder Echt schrieb:
hustbaer schrieb:
Und nochmal: vergiss alles was man einem User erklären müsste und/oder wozu ein Mindestmass an Intelligenz nötig ist. Sowas kann man vielleicht in einer Firma durchsetzen wenn der Chef sagt "muss"... Massiven Unmut erzeugt man damit aber auf jeden Fall, und sobald das "muss" wegfällt... => game over.
Deshalb reite ich ja so dermaßen drauf rum, das OTP clientseitig ohne Aufwand für den User sicherer zu gestalten. Man kann nichts von einem User erwarten, außer das, was sie bereits kennen. Da wäre also die Eingabe eines Codes mit Hilfe einer PIN schon fast das Maximum.
Und was ich schon die ganze Zeit versuche dir klarzumachen: das wäre nicht das Maximum, es wäre weit ÜBER dem Maximum. Also falls du dich damit immer noch auf das von dir skizzierte "User bekommt ein Bild und muss da mittels seines PINs Zahlen raussuchen" System beziehst. Das macht dir kein normaler User mit. Ausser eben er wird gezwungen. Nur dann wird er dich dafür mit Flüchen belegen dass auch einem nicht abergläubischen Menschen bange dabei wird.
Ein externes Gerät (z.B. Dongle) ist dagegen für den User kein echter Aufwand. Den muss er bloss rumschleppen, das geht schon - so gross sind die Dinger ja nicht. Natürlich hast du damit mehr Aufwand, das ist klar. SMS wäre vermutlich ein guter Mittelweg. Ne SMS über ein per RS-232/USB angeschlossenes 2G/3G/4G Modem rausschicken ist keine Hexerei (Internet SMS Gateways würde ich bei dieser Anwendung eher nicht empfehlen ;)). Und wenn auch nur bestimmte Bereiche/Funktionen "extra" abgesichert werden müssen, dann sollte auch das Problem mit dem "muss Handy haben" bzw. "muss Nummer hergeben wollen" nicht so schlimm sein.
Oder eben ne eigene App.
Damit könntest du z.B. einfach auf der Webseite nen QR-Code mit der Challenge anzeigen. Der User scannt den mit der App, gibt dann sein Passwort ein, die App errechnet mit einem fix im Handy abgespeicherten Salt+eingegebenem Passwort die Response und schickt das Ergebnis an den Server. Ist vermutlich nicht so sicher wie SMS TAN, aber immerhin wird sich ein Angreifer der nur eines der beiden Geräte kompromitiert hat schwer tun die Daten zu korrelieren. Die App muss nämlich wirklich nur die Response schicken, um welchen User es dabei geht ist vollkommen schnuppe -- das weiss dann schon der Server.
-
Nur dann wird er dich dafür mit Flüchen belegen dass auch einem nicht abergläubischen Menschen bange dabei wird.
-
hustbaer schrieb:
Und was ich schon die ganze Zeit versuche dir klarzumachen: das wäre nicht das Maximum, es wäre weit ÜBER dem Maximum.
Gut, das habe ich verstanden.
Eine eigene App und SMS via Modem sind gute Alternativen, danke für die ausführlichen Erläuterungen dazu.
SeppJ schrieb:
30 mal 8? Du meinst wohl eher 8*8, wenn die Chance auf einfaches Raten des Passworts unter 1:1000 liegen soll. Ein einzelnes Zeichen als Passwort ist selbst bei OTP sehr, sehr unsicher. 4 sollten es schon mindestens sein.
Ich meinte eigentlich Startpositionen. Bspw. Herz 8 als Startposition ist dann nicht "E", sondern "Eq2Tji". Dazu kann man dem User auch weitere "zufällige" Anweisungen übermitteln, wie z.B. "6 Zeichen lang, lesen Sie von links nach rachts" oder man legt von vornherein eine Leserichtung und Zeichenlänge fest. Aber da sind wir ja schon an dem Punkt angelangt, dass das zuviel Aufwand für einen User sein wird.
-
Fake oder Echt schrieb:
SeppJ schrieb:
30 mal 8? Du meinst wohl eher 8*8, wenn die Chance auf einfaches Raten des Passworts unter 1:1000 liegen soll. Ein einzelnes Zeichen als Passwort ist selbst bei OTP sehr, sehr unsicher. 4 sollten es schon mindestens sein.
Ich meinte eigentlich Startpositionen. Bspw. Herz 8 als Startposition ist dann nicht "E", sondern "Eq2Tji". Dazu kann man dem User auch weitere "zufällige" Anweisungen übermitteln, wie z.B. "6 Zeichen lang, lesen Sie von links nach rachts" oder man legt von vornherein eine Leserichtung und Zeichenlänge fest. Aber da sind wir ja schon an dem Punkt angelangt, dass das zuviel Aufwand für einen User sein wird.
Aber es sind nur 32*8 Zeichen auf der Karte! Darauf kannst du höchstens 64 Passwörter a 4 Zeichen generieren, egal wie kompliziert du es deinem Nutzer machst. Und es gibt keinen Grund es komplizierter zu machen, als jedes Mal einfach 4 Zeichen weiter zu gehen.edit: Ich sehe gerade, die Karte ist ja nicht einmal komplett zufällig, sondern hat nur 128 Bit Entropie! Das kannst du ja total vergessen, daraus kannst du höchstens 1 bis 2 Passwörter generieren, bevor die Karte als kompromittiert gelten muss.
-
SeppJ schrieb:
Fake oder Echt schrieb:
SeppJ schrieb:
30 mal 8? Du meinst wohl eher 8*8, wenn die Chance auf einfaches Raten des Passworts unter 1:1000 liegen soll. Ein einzelnes Zeichen als Passwort ist selbst bei OTP sehr, sehr unsicher. 4 sollten es schon mindestens sein.
Ich meinte eigentlich Startpositionen. Bspw. Herz 8 als Startposition ist dann nicht "E", sondern "Eq2Tji". Dazu kann man dem User auch weitere "zufällige" Anweisungen übermitteln, wie z.B. "6 Zeichen lang, lesen Sie von links nach rachts" oder man legt von vornherein eine Leserichtung und Zeichenlänge fest. Aber da sind wir ja schon an dem Punkt angelangt, dass das zuviel Aufwand für einen User sein wird.
Aber es sind nur 32*8 Zeichen auf der Karte! Darauf kannst du höchstens 64 Passwörter a 4 Zeichen generieren, egal wie kompliziert du es deinem Nutzer machst. Und es gibt keinen Grund es komplizierter zu machen, als jedes Mal einfach 4 Zeichen weiter zu gehen.edit: Ich sehe gerade, die Karte ist ja nicht einmal komplett zufällig, sondern hat nur 128 Bit Entropie! Das kannst du ja total vergessen, daraus kannst du höchstens 1 bis 2 Passwörter generieren, bevor die Karte als kompromittiert gelten muss.
Da steige ich jetzt gerade nicht hinter. Um diese Methode zu kompromittieren, muss der Angreifer entweder die Zeichenreihenfolge kennen (also die obere Symbolleiste) um nach genügend abgefangenen Eingaben sich die Karte nachbauen zu können oder er kennt den Algorithmus der zur Erstellung der Karte nötig ist und kann dann mit viel Aufwand annäherungsweise auf den private key zurückrechnen (der Key, mit dem die Karte erstellt wurde). Aber allein beim Rückbau durch genügend abgefangene Eingaben weiß er immer noch nicht, in welche Richtung gelesen wurde (worauf natürlich nach einigen Eingaben auch Rückschlüsse möglich sind).
Wie kommst du auf die 128bit Entropie?
Wenn ich die Entropie H eines vier Zeichen langen Passwortes bei einer Mächtigkeit von 62 berechne, erzielt ein jedes solches Passwort ca 24 Bit Informationsgehalt.
Dazu rechne ich:
-
Fake oder Echt schrieb:
oder er kennt den Algorithmus der zur Erstellung der Karte nötig ist
Natürlich kennt er den! Du musst immer davon ausgehen, dass ein Algorithmus nicht geheim gehalten werden kann oder sollte.
Aber allein beim Rückbau durch genügend abgefangene Eingaben weiß er immer noch nicht, in welche Richtung gelesen wurde (worauf natürlich nach einigen Eingaben auch Rückschlüsse möglich sind).
Ahh, ich hatte nicht gesehen, dass die obere Leiste variabel ist. Das macht es unwesentlich schwerer, aber das Angriffsprinzip ist das gleiche: Der Angreifer kennt nun eine Zuordnung der Symbole zu den Zeichen.
Wie kommst du auf die 128bit Entropie?
Diese Annahme war falsch, es sind sogar nur 64 Bit. Das heißt, das System ist praktisch schon geknackt, nachdem ein einziges Passwort von der Karte benutzt wurde. Da ist ja sogar ein Rainbowtable aller Karten nicht unrealistisch.
64 Bit, weil die Karte eindeutig durch eine 16-stellige Hexadezimalzahl beschrieben werden kann.
-
Ich will nur mal kurz erwähnen dass es bei Sicherheitsfragen nur eine wirklich richtige Antwort gibt: bestehende bewehrte Verfahren verwenden.
Sich selber etwas auszudenken ist immer(!) schlechter als bestehende Systeme zu verwenden.
