Implementierung One-Time-Password
-
cooky451 schrieb:
Die Erklaerung ist auf jeden Fall schon mal wesentlich verstaendlicher als dein Eingangspost.
Das typische Problem. Zu abstrakt: versteht keiner. Zu genau: alle sind verwirrt. Hybride: jeder denkt es verstanden zu haben, dabei versteht jeder etwas anderes.
cooky451 schrieb:
Das heisst also, du hast eine Verbindung Browser <-> Webserver <-> C-Server?
So in etwa. Genau genommen könnte man den C-Server als erweiterndes Modul für den Webserver verstehen. Da soll die gesamte Datenverarbeitung (also auch die Authentifizierung) drüber laufen. Vermittelt wird das ganze der Einfachheit halber via Webserver (PHP).
-
Ich verstehe nicht was daran sicherer ist als eine Passwort eingabe.
Sobald ich die Kommunikation abfange, habe ich den PIN. Welchen Vorteil siehst du also? Geht es dir nur um Keylogger? Dann mach 2 factor.
-
Verstehe ich dich richtig dass das was du als One-Time-Password bezeichnest ein einfaches Challenge-Response Verfahren werden soll, wobei der User selbst die (viel zu einfache) Berechnung machen soll?
Gegenvorschlag: verwende zwei Geräte. z.B. ein Handy oder Tablet als zweites Gerät. Mit ner eigenen App oder auch einfach ne SMS schicken. Oder so Kasterln die ne Uhr drinnen haben und aus der aktuellen Zeit + internen Schlüssel nen PIN berechnen.
Den User interessiert es nämlich sowieso nicht wenn er zum Einloggen irgendwas machen muss was komplizierter ist als sein fixes Passwort von seinem Schmierzettel runterzulesen und einzutippen. Bzw. würde es mich nicht wundern wenn die meisten User ihre Passwörter sowieso im Browser abgespeichert hätten.
-
Shade Of Mine schrieb:
Sobald ich die Kommunikation abfange, habe ich den PIN.
Das verstehe ich wiederum nicht. Die PIN wird gar nicht gesendet, stattdessen wird eine Zeichenfolge gesendet, die anhand der PIN durch den User "herausgefunden" und eingegeben wurde. Mein Problem setzt eben da an, dass man aber anhand der Zeichenfolge die PIN ermitteln kann, wenn man das Bild hat, aus der die Zeichenfolge erstellt wurde.
hustbaer schrieb:
Verstehe ich dich richtig dass das was du als One-Time-Password bezeichnest ein einfaches Challenge-Response Verfahren werden soll, wobei der User selbst die (viel zu einfache) Berechnung machen soll?
Das könnte man so sehen. Die Antwort kann aber eben nur mit Hilfe der PIN erstellt werden. Da reicht also kein implizites Wissen à la Beherrschung der Grundrechenaufgaben, sondern man benötigit explizit die PIN um die richtige Antwort herauszufinden. Vereinfacht könnte man sagen, dass das wie die Spam-Abfrage hier im Forum ist, nur dass bei der Rechnung eine Zahl nicht angezeigt wird, die auch nur der User kennen kann und wodurch das System letztendlich nicht nur ermitteln kann, ob das (vermutlich) ein Mensch ist, sondern anhand der "Zusatzzahl" bzw. PIN auch feststellen kann, welche bestimmte Person das ist.
Aber bitte nicht falsch verstehen: So wie gerade beschrieben, soll das nicht funktionieren, das sollte nur zur Verdeutlichung dienen.
hustbaer schrieb:
Gegenvorschlag: verwende zwei Geräte. z.B. ein Handy oder Tablet als zweites Gerät. Mit ner eigenen App oder auch einfach ne SMS schicken.
Sowas ähnliches wollte ich beim Vergessen der PIN machen, so dass die neue PIN per SMS an eine hinterlegte Handynummer versendet wird. Die Begeisterung hielt sich aber bei den Leuten in Grenzen, denen ich die Idee mal vorgestellt habe (alles keine Programmiere, ich frage gerne potentielle Endnutzer, wie sie sich das vorstellen würden, allerdings war die häufigste erste Frage "Ich brauche dann Handy UND PC?"). Ich sehe da also zwei Geräte schon als recht kritisch an, da viele wohl zu faul sein würden. Allerdings ist die Idee, wie du sie eingebracht hast für wirklich sicherheitskritische Bereiche sehr nett. Vllt. setze ich die Administratorenanmeldung so um.
hustbaer schrieb:
Den User interessiert es nämlich sowieso nicht wenn er zum Einloggen irgendwas machen muss was komplizierter ist als sein fixes Passwort von seinem Schmierzettel runterzulesen und einzutippen. Bzw. würde es mich nicht wundern wenn die meisten User ihre Passwörter sowieso im Browser abgespeichert hätten.
Das schöne an dieser Idee ist ja eigentlich (Achtung, alles persönliche Meinung), dass es eben nur unwesentlich aufwendiger ist. Eine Art Passwort muss sich der User immer noch merken, nur dass er das eben umwandeln muss, um sich zu authentifizieren. Speichern kann er dadurch auch nichts mehr im Browser (ein sehr schöner Nebeneffekt, danke fürs drauf aufmerksam machen), da er das was er eingibt das nächste Mal nicht mehr gebrauchen kann (deshalb ja One-Time-Password).
Falls ich nachher Zeit habe, erstelle ich mit PHP ein Beispiellogin, so wie ich mir das vorstelle. Dann kann man das glaube ich besser verstehen, was ich meine.
-
Fake oder Echt schrieb:
hustbaer schrieb:
Verstehe ich dich richtig dass das was du als One-Time-Password bezeichnest ein einfaches Challenge-Response Verfahren werden soll, wobei der User selbst die (viel zu einfache) Berechnung machen soll?
Das könnte man so sehen. Die Antwort kann aber eben nur mit Hilfe der PIN erstellt werden. Da reicht also kein implizites Wissen à la Beherrschung der Grundrechenaufgaben, sondern man benötigit explizit die PIN um die richtige Antwort herauszufinden.
Weisst du wie eine Challenge-Response funktioniert?
Dabei gibt es nämlich genau so ein sog. "Shared Secret", also einen Wert den der Server kennt und der Client, aber sonst keiner. Ohne das wäre das Verfahren ziemlich nutzlos.
D.h. dein Verfahren ist ein Challenge-Response Authentifizierungsverfahren. Nur dass die Berechnung -- also wie die Channenge mit dem Shared Secret kombiniert wird um die Response auszurechnen -- viel zu einfach ist. Wodurch es dann möglich wird auf das Shared Secret "zurückzurechnen" wenn man einen solchen Vorgang komplett mitgeschnitten hat -- also wenn man Challenge + dazupassende Response kennt.Bei guten Challenge-Response Verfahren ist das nicht möglich. Allerdings sind die Berechnungen für gute Challenge-Response Verfahren viel viel zu aufwendig als dass man sie einem User zumuten könnte. Du bräuchtest also ein Hilfsprogramm, wo der User wieder seinen PIN eingeben muss, womit das ganze wieder unsicher wird (ein Keylogger/Screenlogger kann ja genau so gut mitloggen was dem Hilfsprogramm eingegeben wird).
Fake oder Echt schrieb:
hustbaer schrieb:
Den User interessiert es nämlich sowieso nicht wenn er zum Einloggen irgendwas machen muss was komplizierter ist als sein fixes Passwort von seinem Schmierzettel runterzulesen und einzutippen. Bzw. würde es mich nicht wundern wenn die meisten User ihre Passwörter sowieso im Browser abgespeichert hätten.
Das schöne an dieser Idee ist ja eigentlich (Achtung, alles persönliche Meinung), dass es eben nur unwesentlich aufwendiger ist.
Nö, die Handy-Lösung ist die die unwesentlich aufwendiger ist (für den User).
Wenn deine User das schon abschreckt, dann zeig denen mal nen Prototypen von dem wie du dir das vorstellst, und dann guck zu wie sich ihre Gesichter in Angst und Schrecken verzerren.ps: OK, zeigen reicht natürlich nicht. Du musst sie den Prototypen natürlich selbst ausprobieren lassen. Ohne es ihnen vorher zu erklären, einfach nur mit dem Helpfile/der Anleitung die "normale" Anwender dann später bekommen würden.
-
Fake oder Echt schrieb:
Shade Of Mine schrieb:
Sobald ich die Kommunikation abfange, habe ich den PIN.
Das verstehe ich wiederum nicht. Die PIN wird gar nicht gesendet, stattdessen wird eine Zeichenfolge gesendet, die anhand der PIN durch den User "herausgefunden" und eingegeben wurde. Mein Problem setzt eben da an, dass man aber anhand der Zeichenfolge die PIN ermitteln kann, wenn man das Bild hat, aus der die Zeichenfolge erstellt wurde.
Ich denke genau das meint Shade ja.
Kommunikation abfangen = Bild + zurückgeschickte Antwort abfangen = Challenge + Response abfangen.
Wenn du davon ausgehst dass der Client kompromitiert ist, dann kannst du das aber nicht verhindern, da du mit nem kompromitierten Client weder "Man in the Middle" Attacken noch Keylogger+Screenlogger ausschliessen kannst.
-
hustbaer schrieb:
Fake oder Echt schrieb:
Shade Of Mine schrieb:
Sobald ich die Kommunikation abfange, habe ich den PIN.
Das verstehe ich wiederum nicht. Die PIN wird gar nicht gesendet, stattdessen wird eine Zeichenfolge gesendet, die anhand der PIN durch den User "herausgefunden" und eingegeben wurde. Mein Problem setzt eben da an, dass man aber anhand der Zeichenfolge die PIN ermitteln kann, wenn man das Bild hat, aus der die Zeichenfolge erstellt wurde.
Ich denke genau das meint Shade ja.
Kommunikation abfangen = Bild + zurückgeschickte Antwort abfangen = Challenge + Response abfangen.
Wenn du davon ausgehst dass der Client kompromitiert ist, dann kannst du das aber nicht verhindern, da du mit nem kompromitierten Client weder "Man in the Middle" Attacken noch Keylogger+Screenlogger ausschliessen kannst.
Will ich ja auch nicht ausschließen, ich versuche das aber zu erschweren. Deshalb überlege und frage ich ja, ob es eine Möglichkeit gibt, die Eingaben (also das OTP) vor dem Versenden nochmals zu verschlüsseln. Am schönsten wäre theoretisch direkt während der Eingabe. Dann wären nämlich schon alle meine Anforderungen erfüllt. Die Entwicklung einer Authentifizierungsmethode, die wirklich zu 99,9% sicher ist (ausgehend davon, dass der Server als "unangreifbar" gesehen wird und davon ausgehend, dass der User seine PIN auch brav geheim hält) erachte ich für mich persönlich im Alleingang als absurd. Was ich aber durchaus schaffen kann, ist eine Risikominimierung im Vergleich zu herkömmlichen Passwörtern. Daher kam mir der Gedanke mit den OTPs. Der große Vorteil, den ich daran sehe, ist, dass eine abgefangene Authentifizierung nur einmal ausgenutzt werden kann, vorausgesetzt man kann anhand des OTPs nicht auf die PIN Rückschlüße ziehen (da liegt das geedankliche Problem und ja offensichtlich auch nicht nur bei mir=.
Und ja, mir ist das Challenge-Response-Verfahren (eigentlich) bekannt.
Was sicherlich ginge, ist, beide Verfahren zu kombinieren. Also dass der User eine Login-Anfrage stellt, per SMS Zusatzzahlen erhält und diese in welcher Weise auch immer zu seiner PIN hinzufügen muss, um dann wiederum das OTP daraus zu generieren. Aber auch hier wäre es schön, wenn das OTP vor dem Versenden noch verschlüsselt würde. Es reduziert und bleibt reduziert auf das Grundproblem (zumindest aus meiner Sicht).
-
Fake oder Echt schrieb:
Was sicherlich ginge, ist, beide Verfahren zu kombinieren. Also dass der User eine Login-Anfrage stellt, per SMS Zusatzzahlen erhält und diese in welcher Weise auch immer zu seiner PIN hinzufügen muss, um dann wiederum das OTP daraus zu generieren. Aber auch hier wäre es schön, wenn das OTP vor dem Versenden noch verschlüsselt würde. Es reduziert und bleibt reduziert auf das Grundproblem (zumindest aus meiner Sicht).
Wieso nicht einfach ein Einmalpasswort per SMS versenden?
-
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. 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.
-
@Fake oder Echt
Wie kann der User denn einen (aktiven, verwendbaren) Account haben, wenn er sich noch nie authentifiziert hat?
Also ich denke man kann dieses Problem auf jeden Fall in den Griff bekommen. Z.B. es so einrichten, dass man einen Account so lange nicht zu irgendwas "schützenswertem" verwenden kann, und auch keine "schützenswerten" Daten hinterlegen kann, so lange der Account nicht ausreichend abgesichert ist.Davon abgesehen...
Ich würde an deiner Stelle erstmal anpeilen das Service gegen alle bekannten Schwächen/Exploits (inklusive Phishing etc.) mit Mitteln abzusichern die "tried and true" sind (soweit eben möglich)...
Das würde für mich auch bedeuten das ganze als Prototyp online zu stellen, und dann inklusive einer Beschreibung wie das System funktioniert in z.B. eine auf Security spezialisierte Newsgroup zu stellen. Mit der Bitte man möge dir die Schwachstellen des Systems aufzeigen und wie du sie fixen kannst.
Und mir dann erst Gedanken darüber machen wie man es noch sicherer machen kann.Und dann könntest du z.B. Two-Factor Authentication über SMS oder TOTP optional anbieten. Also wer ein Handy hat und die Nummer eingeben will, der kann es nutzen, die anderen bekommen halt "nur" die "normale" Sicherheit.
-
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.
