Implementierung One-Time-Password
-
Ich versuche meine Frage nochmal zu präzisieren. Wie kann die Verarbeitung des OTPs clientseitig möglichst sicher gestaltet werden, ohne unnötig viel Angriffsfläche durch Caching und KeyLogging offenbaren zu müssen? clientseitige Verschlüsselung/Hashen?
Oder anders: serverseitig habe ich keine Bedenken. Dein Verweis auf PKV ist zwar nett, allerdings nicht wirklich hilfreich, da das bereits durch mich beantwortet wurde.
Hier nochmal die entsprechende Passage
Fake oder Echt schrieb:
Server besitzt Datenbank mit PINs aller User (verschlüsselt gespeichert).
Zur Entschlüsselung wird ein Hash verwendet, der aus uniquen Daten des entsprechenden Users und des Servers jedes Mal zur Entschlüsselung neu erstellt wird. Gedacht habe ich da an SHA (durch die zusätzlichen Faktoren wäre das ja ordentlich gesalzen). Ist das sinnvoll? Aus meiner Sicht ist das zwar wenigstens sicherer bzw. aufwendiger zu umgehen, als ein globales Passwort irgendwo zu hinterlegen, aber die Sinnhaftigkeit lasse ich gerne anzweifeln.Was ich allerdings nicht nochmal extra klar gemacht habe (dachte, das mit dem Caching wäre Hinweis genug, aber das ist mein Fehler), ist, dass das ganze clientseitig in einem Webinterface (PHP-basiert) läuft und daher serverseitig (C Server, der mit Webserver kommuniziert) ver- und entschlüsselt werden muss.
Gerne lasse ich mich aber beraten, inwiefern die PKV bei meinem Problem abhilfe schaffen kann.
-
Ich glaube, du vermischt hier einige Dinge. Wenn der Rechner des Users infiziert ist, hat der User verloren. Dagegen kann man nichts machen. Ja, dein Verfahren (oder ein On-Screen Keyboard) wuerden einem simplen Keylogger die Suppe versalzen. Kann man als Gag machen, nachdem man ordentlich eine verschluesselte Verbindung aufgebaut hat etc. - aber dein Erstbeitrag wirkt so, als wuerdest du das Ganze ueber eine unverschluesselte Verbindung als primaere Authentifizierungsmethode anwenden wollen, was irgendwie keinen Sinn macht.
-
cooky451 schrieb:
Ich glaube, du vermischt hier einige Dinge.
Nein.
cooky451 schrieb:
Wenn der Rechner des Users infiziert ist, hat der User verloren.
Ja und eben da soll das OTP eingreifen. Daher erkläre ich dir den Sinn dahinter nochmal genauer: Ein KeyLogger an sich stellt kein Problem dar, da die PIN vom User nicht direkt eingegeben wird. Das bedeutet, die eine Authentifizierung kann zwar dann abgefangen und ausgenutzt werden, generell ist der Account aber "sicher". Bei einem herkömmlichen Passwort wäre das problematisch, da das Passwort geloggt wäre und für beliebig viele weitere Authentifizierungen verwendet werden könnte. Nicht aber so bei einem One-Time-Password - das wird schließlich immer wieder neu erstellt. Unsicher wird das OTP nur, wenn anhand eben dieses OTPs die PIN ermittelt werden kann. Dann wäre der Account vollständig kompromittiert und die PIN müsste geändert werden. Sinn und Zweck ist es aber, dass die PIN nicht zwangsläufig geändert werden muss. Sicherlich wäre das in einem solchen Fall (wie bei einem normalen Passwort auch) zwingend anzuraten, es ist aber nicht wirklich notwendig. Es sei denn, und ja ich wiederhole mich, man kann vom OTP auf den PIN Rückschlüsse ziehen (abgesehen von der Länge, die lässt sich egal bei welchem Verschlüsselungsverfahren ermitteln).
Da ich mir selbst darüber im Klaren bin, dass bei einem kompromittierten PC das ganze Spiel jedes Mal aufs Neue los gehen würde (hinsichtlich abfangen und Authentifizierung übernehmen), interessiere ich mich für Ideen, wie das noch sicherer (clientseitig) gestaltet werden kann. Ein On-Screen-Keyboard stellt dabei keine Lösung dar, da KeyLogger mit dieser Methode genug verarscht werden. Es bleibt aber immer noch das Problem, dass mit Hilfe des Caches und eines KeyLoggers die PIN ermittelt werden könnte.
Weiterhin stellt sich die Frage, ob jemand einen Einfall hat, wie man einen Man-in-the-Middle-Angriff erschweren könnte. Ich wiederhole dazu nochmal: Sollte jemand den Datenverkehr abfangen und das Captcha, sowie das OTP aus den Datenpaketen ermitteln, ist er in der Lage daraus die PIN zu ermitteln. Sichere Verbindungen hin oder her, ich habe es schon oft genug erlebt, dass es ein Zertifikatsproblem oder sonstige Umstände verhinderten, eine sichere Verbindung aufzubauen (und wenn es nur ein User war, der in seinen Einstellungen als "besondere" Vorsichtsmaßnahme alle Zertifikate ablehnen ließ, bis auf die, die er explizit eingetragen hat). Daher suche ich nach einer Möglichkeit, zusätzlich (durch clientseitige Verschlüsselung?) das OTP zu sichern, um die Ermittlung der PIN zu erschweren/zu verhindern. Denn den Verbindungsaufbau zu verhindern, weil irgendwas mit der sicheren Verbindung nicht stimmt, ist aus Gründen der content accessibility und aus der unter Anderem daraus resultierenden customer satisfaction nicht denkbar. Denn leider muss eher die reliability/trustability und security dran glauben, bevor die dependability auch nur angekratzt werden darf (das waren glaube ich genug englische Schlagworte).
Um den Server mache ich mir im Übrigen am wenigsten Sorgen. Schwierig ist es nur, die Authentifizierung möglichst sicher zu gestalten. Auch der weitere Datenverkehr ist relativ unproblematisch, da wichtige Dateien und Daten nur per OTP verfügbar gemacht werden und daher die einmalige Authentifzierung nichts bringt (es sei denn, man hat die PIN). Dass man sich nicht gegen alles wappnen kann, ist mir im Übrigen auch klar. Viele Dinge lassen sich aber serverseitig regeln. Die Authentifizierung ist aus meiner Sicht in der von mir gedachten Form bisher das Sicherheitskritischste.
-
Die Erklaerung ist auf jeden Fall schon mal wesentlich verstaendlicher als dein Eingangspost. Das heisst also, du hast eine Verbindung Browser <-> Webserver <-> C-Server?
-
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.
