Sicherheit von Variablen...

[sumiyou]

Ein Dienstepasswort, das auf Grundlage des User-PW gebildet wird, erscheint mir doch recht unsinnig.
Zum Einen Wird das User-PW im Normalfall als Hash gespeichert, ist also direkt gar nicht verfügbar oder nur gegen Sicherheitsverlust. Zum Zweiten ist das User-PW variabel (der User kann es ändern und damit das Dienstpasswort entwerten).

Ich bin jetzt ehrlich gesagt nicht sicher, ob Du das Verfahren verstanden hast oder ob ich Dich nicht verstanden habe. Eventuell wird es durch die genannte URL klarer. Was da "Mixing Password" heißt, ist das "Masterpasswort", von dem die Ausgabe abhängt und was das zentrale Geheimnis ist. Wenn das leakt, hat ein dritter die Berechnungsgrundlage für andere Dienstepassworte, ähnlich als wenn Datenbank und Masterpasswort bei einem Passwort-Safe leaken.

[nikosch]

ob Du das Verfahren verstanden hast

Nö hab ich nicht. Du hast es auch nicht wirklich erklärt. Aus Deinem Online-Beispiel werd ich auch nicht schlau. Irgendwelche genrierten User durchswitchen und ein paar Eingaben und Random-Knöpfe. Hmmm

[sumiyou]

Sorry Es ist etwas unintuitiv, wegen des Usernamen-Generators.

Es geht halt einfach darum, dass Du bei gegebener Eingabe immer die gleiche Ausgabe bekommst. Nur kurz zwei Anwendungsfälle, dann wird es klar:

a) "Ich will ein Passwort der Länge 15 für das Jahr 2010 fürs heise-forum haben als User 'heinz' bekommen"
Service name: heise.de
User name: heinz (eintippen)
"Generate" drücken. (Jahr und Länge sind ja schon eingetragen)

Nun kommt da "M5I7q3dTRTtL4gm" als Passwort heraus (Unten, schwarzer Text auf schwarzem Hintergrund wg. eavespropping), und das kann jeder berechnen. Daher gibt es das "Mixing Password", im Grunde also "das Masterpasswort", womit Du ein eindeutiges, aber individuelles Passwort als Ausgabe bekommst.

b) "Ich will einen Account mit Passwort der Länge 15 für das Jahr 2010 fürs heise-forum haben - einen Usernamen auch bitte, denn mir fällt keiner ein"

Service name: heise.de
Mixing PW: <eingeben>
"usr0" drücken.

Das Mailinator-Ding da ganz unten ist nur so ein Nebenprodukt und ist nicht von Jahr und Länge abhängig.

<Link>

P.S.: Weiß jemand, wie ich den Focus auf "Generate" bekomme, so dass einfach Enter gedrückt werden kann?

[nikosch]

Mit focus() in Javascript.

Trotzdem: Welchem Zweck soll das dienen? Da ist doch jeder Passwortgenerator mit einer reinen Zufallskomponente viel sicherer! Wenn die Gefahr besteht, aus den vorhandenen Eingaben das Passwort rückrechnen zu können (Stichwort social engineering), ist der Generator doch ein echter Unsicherheitsfaktor.

Was eher typisch (für Userpasswörter) ist: Denke Dir einen Masterpasswortstring aus (möglichst komplex) und lerne den auswendig. Ergänze diesen für jeden Service um eine Zeichenkette, die nach einem Prinzip aus dem Servicenamen o.ä. abgeleitet wird.

Z.B.
Masterpasswort: IdRfaRS,aiJ2010 (noch recht trivial, „In der Regel folgt auf Regen Sonnenschein,außer im Jahr 2010“)
Service: Web.de Mailing -> Wb.IdRfaRS,aiJ2010Mlg
Service: Heise Forum -> Hs.IdRfaRS,aiJ2010Frm

[sumiyou]

Trotzdem: Welchem Zweck soll das dienen? Da ist doch jeder Passwortgenerator mit einer reinen Zufallskomponente viel sicherer! Wenn die Gefahr besteht, aus den vorhandenen Eingaben das Passwort rückzurechnen, ist der Generator doch ein echter Unsicherheitsfaktor.

Yep. Ich würde sagen "auszurechnen".
Der Vorteil ist Flexibilität. Klar, die zentrale Angreifbarkeit muß man handhaben - - erster Punkt ist, das nur in sicherer Umgebung zu nutzen. Ist ja auch erstmal nur eine Anfangsidee. Man kann ja da noch mehr machen, zum Beispiel das Geheimnis "Master Password" (habe es jetzt umbenannt) entschärfen und aufteilen mittels externen Token... Muß ich mal überlegen
Edit: Du hast jetzt schon gepostet und ich keine Zeit mehr, ich sehe mir die Ideen ein anderes mal an.

[nikosch]

Ich glaube, ich raffs jetzt, was Du da bstelst. Dir gehts nicht nur um die Generierung, sondern der User soll jedes mal dieses Tool nutzen, wenn er sich wo einloggen will. Statt Passwortsafe also dieses Tool. Den einzigen Vorteil sehe ich daran, wenn man Programmierer ist, kann man das Ding auf dem eigenen Server oder lokal hosten und kann sich sicher sein, dass niemand mitschnorchelt, wohingegen Passwortsafes i.A. Fremdsoftware ist.

In diesem Fall solltest Du das Masterpasswort zum Pflichtfeld machen und Trivialpasswörter nicht zulassen.

[Sirke]

Z.B.
Masterpasswort: IdRfaRS,aiJ2010 (noch recht trivial, „In der Regel folgt auf Regen Sonnenschein,außer im Jahr 2010“)
Service: Web.de Mailing -> Wb.IdRfaRS,aiJ2010Mlg
Service: Heise Forum -> Hs.IdRfaRS,aiJ2010Frm

Das ganze ist ja noch unsicherer und beruht noch mehr auf Security Through Obscurity, weil sobald ein Passwort geknackt und das Verfahren bekannt, sind alle PWs unsicher... aber du hast den Sinn bzw seine Idee jetzt ja verstanden!

@sumiyou: Ich würde vorallem das Spiel mit den vielen Hash-Funktionen sein lassen, weil die SHA2 Familie oder Whirlpool völlig ausreichend ist!

Deine Befürchtung, dass das Passwort zum Ableiten in irgendeiner Weise in der Session gespeichert wird/werden muss und dadurch auf diesen Wert zugegriffen werden kann, kannst du an sich nicht verhindern, weil entweder zu speicherst das PW als Hash in der Session, dann kann man dein PW nicht herausfinden, aber auch jeder kann die neuen PWs mit dem Wissen ableiten oder du verschlüsselst das PW in irgendeiner Form in der Session und jeder kann mit der Kenntnis des Schlüssels dieses regenerieren!

Das Problem dahinter ist, egal welchen Wert du wie speicherst, kann jeder mit der entsprechenden Kenntnis diesen Wert zurückgewinnen oder damit auf die selbe Weise wie du arbeiten...

Ein paar Ideen dieses Problem mit asymmetischer Kryptographie und damit mit Trapdoors von Einwegfunktionen zu umgehen hätte ich, aber an sich zögert man es bloß hinaus...
Andere Ideen der Implementierung würden auch nur das Problem verschieben, anstatt es wirklich zu lösen...

Ich würde lieder die Werte UND gerade den unbekannten Wert bei jeder Berechnung eingeben, anstatt ein wichtiges Geheimnis im Speicher zu halten!

Ein Login/Benutzerverwaltungssystem soll es nicht geben, also auch keine angelegten Benutzer, oder?

[nikosch]

Das ganze ist ja noch unsicherer und beruht noch mehr auf Security Through Obscurity, weil sobald ein Passwort geknackt und das Verfahren bekannt, sind alle PWs unsicher

Das ist ja auch für Userpasswörter. Jedes Passwort selbst basiert auf Unbekanntheit. Solange das Masterpasswort unbekannt ist, unterscheidet sich das nicht von normaler Passwortverwendung. Im Gegenteil ergibt sich meist ein stärkeres Endpasswort, als würde man sich x Individualpasswörter merken müssen. Für alle Anbieter, denen man nicht vertraut, empfielt sich im Übrigen ein zweites Masterpasswort.

Finde leider den entspr. Ct-Artikel gerade nicht.
[edit]
Da isser: http://www.heise.de/ct/inhalt/2009/02/86 Vielleicht hat ja mancheiner die Ausgabe rumliegen.

Security Through Obscurity ist eigentlich eher problematisch, wenn es einen Algorithmus gibt, der das Passwort erzeugt. Oder das Passwort prüft.

[mermshaus]

Ah, ich habe es auch endlich kapiert. So eine Art "OpenID-Provider", dessen Ergebnis allerdings nicht der Login selbst ist, sondern die Rückgabe/Generierung des jeweiligen Login-Passworts für den Zielservice.

@sumiyou: Ich würde vorallem das Spiel mit den vielen Hash-Funktionen sein lassen, weil die SHA2 Familie oder Whirlpool völlig ausreichend ist!

Die Idee hinter den vielen Hash-Funktionen ist gewissermaßen, dass es länger dauert, ein Masterpasswort über einen bekannten Hash zu knacken, wenn der Algorithmus lokal ausgeführt werden kann. Ich kann nicht sagen, ob das Sinn ergibt. Spontan tendiere ich eher dazu, dass dem nicht so ist, weil Verfahren X für sich allein genommen als sicher gilt und erhöhte Laufzeit -- oder meinetwegen auch quadrierte Laufzeit -- daran prinzipiell nichts ändert. Entschuldige, falls du genau das meintest, Sirke.

@sumiyou:

Ein Problem, das ich bei dem Gesamtansatz sehe: Ein Ziel-Hash als Ausgangspunkt für lokale Brute-Force-Berechnungen wird jedem Servicebetreiber zur Verfügung gestellt, bei dem sich ein Benutzer deines Masterpasswort-Services anmeldet. Das heißt, jeder Betreiber kann lokal versuchen, das Masterpasswort eines Nutzers zu ermitteln (Bekanntheit des Algorithmus hattest du ja vorausgesetzt). Ist ein Masterpasswort geknackt, ist jeder damit verbundene Account kompromittiert.

Die Gefahr besteht nicht, wenn die individuellen Passwörter nicht aus dem Masterpasswort generiert werden (also beim "klassischen" Passwortsafe).

Edit: Denn der Passwortsafe-Service kann üblicherweise per Brute Force nur über HTTP angegriffen werden, was sich serverseitig schnell "abriegeln" lässt.

[sumiyou]

Ja, Ihr habt es verstanden Ich habe doch Sicherheit größer geschrieben und hatte schon auf der Demonstrationsseite, die ich Euch nannte, das Masterpasswort aus der Session rausgenommen, desweiteren sogar noch direkt nach Gebrauch die $_post-Variable auf NULL gesetzt und unset walten lassen... Gleiches gilt für das gehashte Masterpasswort. Momentan sieht das so aus, dass wenn da ins Passwortfeld ein Passwort eingegeben und eine Berechnung durchgeführt wurde, das Textfeld grün ist, sonst rot.
Klar, man sollte eine Mindesteingabe als Masterpasswort erzwingen, jedoch nutze ich den Spaß ja nur selbst (auf anderer URL durch SSL)... Ich würde natürlich sogar jedem nur abraten, solche Dienste von Dritten zu nutzen.

Was die Angreifbarkeit angeht, kann der Dienst zunächst mit einem Passwortsafe verglichen werden. Beide müssen auf den Clients in einer sicheren Umgebung ausgeführt werden (Abgreifen des Masterpassworts). Bei diesem Dienst kommt noch die Serverseite (Abgreifen aus dem RAM des Servers) und die Übermittlung dazu.
Zentraler Unterschied: Der Dienst hält quasi alle Passworte für alle Dienste für alle Zeiten vor. Wenn das Masterpasswort bekannt wird, ist Holland in Not.

Bei der Konkatenation der krypt. Hashfunktionen war der Vater des Gedankens, dass es dann keine Rolle spielt, wenn eine davon gebrochen würde.

Ein Problem, das ich bei dem Gesamtansatz sehe: Ein Ziel-Hash als Ausgangspunkt für lokale Brute-Force-Berechnungen wird jedem Servicebetreiber zur Verfügung gestellt, bei dem sich ein Benutzer deines Masterpasswort-Services anmeldet. Das heißt, jeder Betreiber kann lokal versuchen, das Masterpasswort eines Nutzers zu ermitteln (Bekanntheit des Algorithmus hattest du ja vorausgesetzt). Ist ein Masterpasswort geknackt, ist jeder damit verbundene Account kompromittiert.

Sehr guter Einwand. Daran hatte ich auch gedacht und dem begegne ich mit üblichen Methoden a) ausreichend langem Masterpasswort und b) "key strengthening" (so heißt das Verfahren glaube ich - also die vormals zitierte for-Schleife). Konkret mache ich das so, dass wenn ich mein Masterpasswort eingebe (d.h. ich vergleiche mit einen Teilhash "if (substr(md5($masterpw),0,=='0123abcd')") wird das Key strengthening länger, es werden also mehr Runden gedreht.

[nikosch]

Das ganze Gehashe kannst Du Dir doch dann aber sparen. Mit einem entspr. Masterpasswort und dem Dienstteil sollte sich doch ein ausreichend sicherer String ergeben. Notfalls packst Du noch &*^$#HJ3__0897&^# dazwischen. Wenn Du sicherstellst, dass niemand Deinen Generator aufrufen kann (das ist die Sicherheitslücke) - who cares? Niemand wird den Hash zurückrechnen können. Erst recht nich sich die Mühe machen, da versuchen zu ergründen, ob dahinter vielleicht ein Algorithmus mit einem Masterpasswort steckt, über den man, wenn man das Prinzip errät, andere Dienste mitknacken kann. Sowas mag für einen weitverbreiteten Generator noch halbwegs realistisch sein, aber doch nicht für einen privaten, von dessen Existenz noch nichtmal jemand weiß.

[sumiyou]

Du schreibst von praktischer Relevanz, damit wirst Du Recht haben. Ich will dennoch ordentliche -die besten- Verfahren anwenden - will ich immer. "Wenn schon machen, dann richtig". In Übung bleiben und so...

[nikosch]

Sorry, aber niemand baut an einen Kohlenkeller einen Pupillenscanner und ein Lasergitter an. Die Argumentation ist aber genauso - diese Techniken sind sicherer, als ein einfaches Vorhängeschloss.

[sumiyou]

Sorry, aber niemand baut an einen Kohlenkeller einen Pupillenscanner und ein Lasergitter an. Die Argumentation ist aber genauso - diese Techniken sind sicherer, als ein einfaches Vorhängeschloss.

Die Pupillenscanner und Lasergitter der IT sind frei verfügbar und jeder kann sie sich leisten - anders als die echte Hardware. Alles weitere ergibt sich daraus und braucht nicht diskutiert zu werden. Daher: Für meinen Kohlenkeller sind Pupillenscanner und Lasergitter noch zu wenig.

[cortex]

Für meinen Kohlenkeller sind Pupillenscanner und Lasergitter noch zu wenig.

vielleicht wär' das ja was für dich: Zufallszahlen aus verschränkten Atomen

cx