Implementierung One-Time-Password

Fake oder Echt

Hallo,

ich sinniere gerade über eine Umsetzung von OTPs als Authentifizierungsmöglichkeit. Die prinzipielle Umsetzung gestaltet sich gedanklich wie folgt:
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.
Jedenfalls wird mit Hilfe dieser PIN das Einmal-Passwort generiert.
Das OTP besteht dabei aus so vielen Zeichen, wie die PIN lang ist.
Das ganze wird dann in Form eines Bildpfades an den Client weitergeleitet und der User muss mit Hilfe seiner PIN das OTP aus dem Captcha ermitteln und eingeben.
Es gibt dabei insgesamt 10 Zeichen, die jeweils einer Zahl zugeordnet sind (von 0 bis 9).
Die Zeichen sind mit Hilfe der Zahlen sortiert und der User soll an Hand seiner PIN die richtigen Zeichen in der richtigen Reihenfolge eintragen.

Beispiel-Captcha:
0 1 2 3 4 5 6 7 8 9
a B c D e F g H i J

PIN: 491745
OTP: eJaHeF

Über die Zuordnung des Captchas (bzw. des Bildes) zum User mache ich mir keine Gedanken, das ist recht schnell abgebacken aus meiner Sicht. Was ich allerdings als derzeitiges Problem sehe, ist die Übermittlung des OTPs. Wird es unverschlüsselt bzw. ungehasht übermittelt, kann man durch Abfangen des OTPs und mit dem Pfad zum Bild ganz einfach die PIN ermitteln. Dafür würde es bereits reichen, dass der User unachtsam ist, ein anderer an das Gerät geht, die Zurück-Taste des Browsers betätigt und sich das Captcha anschaut. Dazu noch ein KeyLogger und man hat alles, was man braucht. Auch könnte das Bild aus dem Browser-Cache direkt gezogen werden. Über einen Man-in-the-Middle-Angriff mache ich mir ebenso Gedanken. Mal abgesehen davon, dass man das OTP abfangen könnte und sich damit erfolgreich authentifizieren könnte (wenn man den Datenverkehr vom Client direkt unterbindet, das OTP abfängt und sich damit selbst authentifiziert), wäre es ebenso einfach, den Bildpfad abzufangen, das Bild zu speichern, auf die User-Eingabe zu warten und daraus dann die PIN herzuleiten. Besonders letzteres wäre mehr als unschön, da ich eigentlich die Sicherheit gegenüber herkömmlichen Passwörtern erhöhen möchte und nicht einfach nur dem User das Leben schwerer machen will.

Fällt jemanden dazu ein geeigneter Ansatz ein? Meine Überlegungen, wie z.B. das Bild direkt nach dem Authentifzierungsversuch zu löschen, würden das Problem des Speicherns leider auch nicht lösen. Stattdessen könnte man das Bild nach dem ersten Aufruf sofort löschen, so dass dieses nur einmal zur Verfügung steht. Da stellt sich mir aber trotzdem die Frage, ob und wie das machbar ist und außerdem bliebe das Problem mit dem Cache wohl noch bestehen.

Ich freue mich über jede Anregung

cooky451

Es waere gut wenn du damit anfangen wuerdest welches Problem du ueberhaupt loesen willst. Wie man Passwoerter auf einem Server speichert? Und dann solltest du noch ausfuehren, welche Probleme du bei aktuellen Verfahren siehst und welche Probleme dein Verfahren davon loesen kann.

Fake oder Echt

cooky451 schrieb:

Es waere gut wenn du damit anfangen wuerdest welches Problem du ueberhaupt loesen willst.

Fake oder Echt schrieb:

ich sinniere gerade über eine Umsetzung von OTPs als Authentifizierungsmöglichkeit

und noch dazu:

Fake oder Echt schrieb:

[um] die Sicherheit gegenüber herkömmlichen Passwörtern [zu] erhöhen

cooky451 schrieb:

Wie man Passwoerter auf einem Server speichert?

Fake oder Echt schrieb:

Server besitzt Datenbank mit PINs aller User

cooky451 schrieb:

welche Probleme du bei aktuellen Verfahren siehst

Fake oder Echt schrieb:

Was ich allerdings als derzeitiges Problem sehe, ist die Übermittlung des OTPs.

dazu weiter:

Fake oder Echt schrieb:

Wird es unverschlüsselt bzw. ungehasht übermittelt, kann man durch Abfangen des OTPs und mit dem Pfad zum Bild ganz einfach die PIN ermitteln. Dafür würde es bereits reichen, dass der User unachtsam ist, ein anderer an das Gerät geht, die Zurück-Taste des Browsers betätigt und sich das Captcha anschaut. Dazu noch ein KeyLogger und man hat alles, was man braucht. Auch könnte das Bild aus dem Browser-Cache direkt gezogen werden. Über einen Man-in-the-Middle-Angriff mache ich mir ebenso Gedanken. Mal abgesehen davon, dass man das OTP abfangen könnte und sich damit erfolgreich authentifizieren könnte (wenn man den Datenverkehr vom Client direkt unterbindet, das OTP abfängt und sich damit selbst authentifiziert), wäre es ebenso einfach, den Bildpfad abzufangen, das Bild zu speichern, auf die User-Eingabe zu warten und daraus dann die PIN herzuleiten.

cooky451 schrieb:

und welche Probleme dein Verfahren davon loesen kann.

Das ist zwar eigentlich die meine Hauptfrage, aber:

Fake oder Echt schrieb:

Meine Überlegungen, wie z.B. das Bild direkt nach dem Authentifzierungsversuch zu löschen, würden das Problem des Speicherns leider auch nicht lösen. Stattdessen könnte man das Bild nach dem ersten Aufruf sofort löschen, so dass dieses nur einmal zur Verfügung steht. Da stellt sich mir aber trotzdem die Frage, ob und wie das machbar ist und außerdem bliebe das Problem mit dem Cache wohl noch bestehen.

Es war wohl doch zuviel Text...

cooky451

Mit aktuellen Verfahren meine ich etablierte Dinge wie Public-Key-Crypto, die man normalerweise benutzt wenn man Nutzer authentifizieren will, nicht dein Verfahren. Alle Folgefragen richten sich demnach auch daran, welche Probleme du damit siehst.

Fake oder Echt

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.

cooky451

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.

Fake oder Echt

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.

cooky451

Die Erklaerung ist auf jeden Fall schon mal wesentlich verstaendlicher als dein Eingangspost. Das heisst also, du hast eine Verbindung Browser <-> Webserver <-> C-Server?

Fake oder Echt

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).

Shade Of Mine

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.

hustbaer

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.

Fake oder Echt

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.

hustbaer

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.

hustbaer

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.

Fake oder Echt

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).

SeppJ

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?

Fake oder Echt

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.

hustbaer

@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.

SeppJ

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.

Fake oder Echt

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