Implementierung One-Time-Password
-
Fake oder Echt schrieb:
Das fände ich ganz sinnvoll, wenn der User sich bereits einmal authentifiziert hätte. Aber als Erst-Authentifizierung würe das eher nicht reichen, da die Authentifizierung soweit wie möglich sicherstellen soll, dass der User sich anmeldet und nicht jemand mit dem entsprechenden Handy.
Ich sehe nicht, wo du hier ein Problem siehst. Bei der Erstidentifizierung fragst du nach der Handynummer.
Das nächste Problem bei der SMS-Thematik ist, dass ich nicht garantieren kann, dass auch jeder eine Handynummer hinterlegt. Das ist zwar generell vorgesehen, aber ich habe bisher noch nie das Glück gehabt, keinen Querulanten oder besonders Datenbesorgten unter den Usern zu haben. Das wäre also höchstens als Zweitweg ohne Weiteres vertretbar.
Dann mach das, je nach Art der Dienstleistung, die du anbietest:
a) Pflicht. Wer nicht will, muss eben draußen bleiben.
oder
b) Optional. Wer nicht will hat es eben weniger sicher.
Oder nimm eines der Vorläuferverfahren, von bevor das SMS-Verfahren der Quasi-Standard wurde:
-Physisch ausgedruckte Codetabelle an die Nutzer ausgeben. Die Challenge ist eine Codenummer, die Response ist der Eintrag an dieser Stelle der Tabelle. Jede Nummer wird höchstens einmal benutzt.
-Physischen Codegenerator an die Nutzer ausgeben. Die Challenge ist ein Seed für den Generator; zur Authentifizierung des Nutzers dient eine Pin, die ebenfalls als Seed in den Generator eingegeben wird (oder ein Wert, der auf einer an den Nutzer ausgegebenen Schlüsselkarte gespeichert ist); die Response ist ein aus beidem errechneter kryptografischer Hash.Letzteres ist vermutlich das, was du von Anfang an wolltest. Aber eben auf eine Art und Weise, die dem Nutzer zumutbar ist, da niemand kryptografische Hashfunktionen im Kopf ausrechnen kann. Die Eingabe der Nutzerpin erfolgt nur in das nicht netzwerkfähige Berechnungsgerät.
Nachteil all dieser Verfahren ist, dass der Nutzer ständig einen physikalischen Token mit sich rumtragen muss. Daher ist das SMS-Verfahren auch so beliebt: Sein Mobiltelefon trägt sowieso fast jeder ständig mit sich rum. Und man ist auch nicht an ein bestimmtes physikalisches Objekt gebunden, sondern kann dieses ersetzen, so lange man nur seine Rufnummer behält.
Die Verfahren sind, in der Art und Weise die ich hier beschrieben habe, noch nicht sicher gegen einen Man-in-the-Middle. Ein Angreifer, der im gleichen Moment mitlauscht, kann sich damit einmalig als der Nutzer ausgeben. Bei der Mobil-TAN und dem TAN-Generator kann man dies verhindern, indem man die TAN nicht für die Authentifizierung nutzt, sondern zur Bestätigung einer bestimmten Aktion und diese Aktion ist entweder Teil der Eingabemenge für den Generator oder Zusatzinformation bei der SMS. Bei der Papier-TAN ist dies nicht möglich, daher ist das Verfahren auch nicht mehr üblich.
-
SeppJ schrieb:
Ein Angreifer, der im gleichen Moment mitlauscht, kann sich damit einmalig als der Nutzer ausgeben.
Das hatte ich ja weiter oben auch bereits festgestelt und das wäre bei einem Standarduser auch so in Ordnung, wenn das passiert, vermeiden würde ich das natürlich trotzdem gerne, daher ja der Thread.
Wie es scheint, ist mein Wunsch nach Verschlüsselung bei der Eingabe mit "Standardmitteln" nicht wirklich umsetzbar. Aber schon mal gut, dass viele weitere Möglichkeiten und Kombinationen zusammen gekommen sind.
Dann werde ich schauen, welche der vielen Möglichkeiten davon jetzt tatsächlich in Frage kommt. Mir ist dabei gerade auch noch der Einfall gekommen, dass man dem User auch so eine Karte (http://www.passwordcard.org/en) in die Hand drücken kann.
Die Idee, die mir dazu gerade gekommen ist, ist, dass der User mithilfe seiner PIN (als erstes Seed) und bspw. einer Zeichenkombination, die vom Server ausgegeben wird (zweites Seed) das Password von dieser Karte abliest. Einen Generator hatte ich dafür sogar schonmal programmiert (ursrpünglich um einer Firma die Möglichkeit zu geben, ohne großen Aufwand viele von diesen Karten für ihre Mitarbeiter zu personalisieren und drucken zu können), so dass dahingehend etwas Arbeit erspart bliebe. Vorteil wäre daran auch, dass der User sich seine Karte am PC neu generieren lassen könnte, wenn er den ersten bereitgestellten Ausdruck verliert, wobei das auch wiederum ein Risiko hinsichtlich ScreenLogger beherbergt, aber das ist Feintuning.Immer her mit weiteren Anregungen/Anmerkungen/Nackenschlägen und ansonsten vielen Dank bis hierhin
-
Fake oder Echt schrieb:
Die Idee, die mir dazu gerade gekommen ist, ist, dass der User mithilfe seiner PIN (als erstes Seed) und bspw. einer Zeichenkombination, die vom Server ausgegeben wird (zweites Seed) das Password von dieser Karte abliest.
Also ein klassisches indiziertes TAN-Verfahren? Aber auf solch eine Karte passen nur wenige Passwörter und Mehrfachbenutzung geht nicht.
Einen Generator hatte ich dafür sogar schonmal programmiert (ursrpünglich um einer Firma die Möglichkeit zu geben, ohne großen Aufwand viele von diesen Karten für ihre Mitarbeiter zu personalisieren und drucken zu können), so dass dahingehend etwas Arbeit erspart bliebe.
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!
Immer her mit weiteren Anregungen/Anmerkungen/Nackenschlägen und ansonsten vielen Dank bis hierhin
Ich habe den Eindruck, du versuchst, das Rad neu zu erfinden, ohne ein einziges Mal nach draußen gegangen zu sein und dir all die verschiedenen Räder anzugucken, die an verschiedenen Fahrzeugen sind. Stattdessen hämmerst du dir irgendwas Eckiges aus Granit, gänzlich unwissend über Felgen, Reifen und Speichen.
Außerdem dreht sich die Diskussion etwas im Kreis. Dein Vorschlag aus diesem Beitrag wurde - je nach Auslegung - entweder von mir oder von hustbaer bereits gemacht und jeweils mit Stärken und Schwächen erläutert. Gerade hustbaers Beiträge scheinst du zur Hälfte zu ignorieren. Dabei erklärt er vieles was du wissen solltest und nimmt bereits die Gedankengänge vorweg, auf die du anscheinend erst jetzt selber gekommen bist.
-
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.
