Sicherheit von Variablen...

[sumiyou]

Hallo allerseits,

ich hoffe, ich bin hier richtig. Kurz zur Vorstellung: ich programmiere neuerdings PHP sehr gerne, weil ich da einige Dinge realisieren kann, die ich übers Web für mich privat gut gebrauchen kann. Ich bin PHP-Newbie, jedoch sind mir grundsätzlich Programmiermethoden bekannt.

Ein kleines Helferlein von mir ist, dass ich mir Usernamen/Passworte/Mailadressen generieren lasse, die von diversen (und untereinander verschiedenen) Bedingungen abhängig sind. Mein Username hier ist so ein Fall. Ich gehe in einer anderen Anfrage noch darauf ein.

Wichtig ist die Abhängigkeit von einem einzugebenden String, nennen wir ihn $_SESSION['geheim'], der geheim bleiben muß.

- Die Abhörsicherheit gewährleiste ich mit SSL.
- Clientsicherheit (Keylogger etc.) setze ich hier als gegeben voraus.
- $_SESSION['geheim'] wird via HTML-Formular belegt

Dies bereitet mir Unbehagen:

- Die Session-Variable steht in der gesamten Session zur Verfügung (wegen Faulheit, damit das PW nicht öfter eingegeben werden muss)

Ist das Unbehagen berechtigt? Letztlich steht dieser Geheimstring im klartext im RAM des Servers, Gefahren von Aussen kann ich direkt nicht erkennen...
Ich habe eine Anfagsüberlegung, ob ich den Variableninhalt irgendwie mit einem temporären Schlüssel verschlüsseln sollte...

Unter der Voraussetzung, dass ich die Faulheit beibehalten will (ansonsten könnte ich den Variableninhalt ja immer sofort nach gebrauch killen):

->Welche Möglichkeiten habe ich?
->Ist der Aufwand nötig?

P.S.: Versteht mich nicht falsch, intern wird mit diversen Hashfunktionen (teilweise wiederholt angewandt) gerechnet und verglichen. Jedoch steht nun mal am Anfang die Klartexteingabe, die gemanaged werden muss.

Danke
Michael

[wolf29]

Schauste hier:

Peter Kropff - Tutorials - Allgemeines - Sicher programmieren - Einführung

Einfach und gut erklärt.

Wolf29

[sumiyou]

Ja danke... das sind im Prinzip die Themen, die ich gerade gestern im Buch "Besser PHP programmieren" gelesen habe.

Mein Thema ist ja im Grunde: "Sicherheit von Variableninhalten" - dazu fand ich aber keine Bemerkung. Vielleicht bin ich ja auch übervorsichtig.

Ist es bzgl. Security "gute Praxis", unset() so schnell es geht hinterherzuschieben, wenn Inhalte nicht mehr gebraucht werden?

[chorn]

Die Sessions sind i.d.R. in einer Datei auf dem Server abgelegt, jeder der darauf Zugriff hat, hat dein Passwort. Wenn der Server falsch konfiguriert ist haben natürlich auch Andere Zugriff auf diese Datei. Aber wenn es dir tatsächlich um die Sicherheit auf dem Server geht, musst du deinen eigenen aufsetzen, mit PHP hat das dann nichts mehr zu tun.

[sumiyou]

Die Sessions sind i.d.R. in einer Datei auf dem Server abgelegt, jeder der darauf Zugriff hat, hat dein Passwort. Wenn der Server falsch konfiguriert ist [...]

Danke, Rest ist klar

OK, das mit Dateiablage ist unangenehm. Es wäre schon wesentlich schöner, würde sich ein Geheimnis maximal im RAM des Servers befinden.

Dann komme ich nun also auf die Idee, das Passwort nur in einer normalen Variable zu verarbeiten, dann mit einem zufälligen Sitzungsschlüssel zu verschlüsseln und beides zu trennen: Den Sitzungsschlüssel halte ich in einer Session, das verschlüsselte Passwort in einem Cookie auf dem Client.... Kann man machen, oder?

Prinzipiell ist natürlich klar, man muss dem Server vertrauen können, aber meine Devise lautet halt: Tun, was möglich ist.

Danke
Michael

[Flor1an]

Was möchtest du in dem "geheim" speichern? Das Passwort? Würde ich nicht machen, das Passwort gehört nicht in die Session. Wenn der User sich einloggen soll dann kannst du in der Session (nach erfolgreichem Login) abspeichern das der User eingeloggt ist. Dafür brauchst du das Passwort überhaupt nicht mehr.

Falls du andere Daten in der Session ablegen willst und unbedingt vermeiden willst dass die Daten auf dem Filesystem liegen dann kannst du dir deinen eigenen Sessionhandler schreiben der die Sessiondaten im Arbeitsspeicher ablegt. Dafür kannst du dann memcache oder xcache verwenden. Ob das ganze dann wirklich sicherer ist mag ich aber bezweifeln.

Am besten du erklärst uns was genau du so "geheim" speichern möchtest, vlt. können wir dir nen ganz anderen Ansatz geben.

[fireweasel]

Ist es bzgl. Security "gute Praxis", unset() so schnell es geht hinterherzuschieben, wenn Inhalte nicht mehr gebraucht werden?

Das ist Unfug. Unset() löscht den Speicher nicht, sondern schubst im günstigsten Fall die Speicher-"Bereinigung" an. Die gibt (wieder im günstigsten Fall) den Speicher dem System zurück. Deswegen kann an der entsprechenden Hauptspeicheradresse immer noch das gleiche Datum stehen wie vor dem Aufruf von unset() ...

...

Dann komme ich nun also auf die Idee, das Passwort nur in einer normalen Variable zu verarbeiten, dann mit einem zufälligen Sitzungsschlüssel zu verschlüsseln und beides zu trennen: Den Sitzungsschlüssel halte ich in einer Session, das verschlüsselte Passwort in einem Cookie auf dem Client.... Kann man machen, oder?

Kann man, wenn man mit dem Klammersack gepudert ist ...

Full Disclosure: Impossible to Maintain Secure Session With Twitter.com Web Interface

Das Passwort hat auf dem Client nichts zu suchen. Alle Daten, die von dort kommen, sind grundsätzlich als "User-generated Input" zu betrachten -- also potenzielle Gefahrenquellen. Da lagert man doch nicht so etwas Wichtiges wie ein Passwort dorthin aus. Prinzipiell sollte in einem (Browser-)Cookie nicht mehr als eine Session-ID abgelegt sein. Alles was darüber hinausgeht ist problematisch und auch unnötig. Wozu hat man sonst auf dem Server eine Session?

[sumiyou]

Am besten du erklärst uns was genau du so "geheim" speichern möchtest, vlt. können wir dir nen ganz anderen Ansatz geben.

Ich generiere mir Passworte (auch Usernamen) abhängig von einer Eingabe. Zur Visualisierung eine Beispieleingabe:

Eingabe:
SERVICE_NAME: php.de
USERNAME: sumiyou
YEAR: 2010
LENGTH: 15
USERPW: geheimpasswortx498754hfssdjklsdfjkl

Ausgabe:
PW: UtfpMxZ0GdO21Y1

Mit diesen Eingabedaten wird ein Passwort generiert, welches von allen o.g. Eingabedaten abhängig ist. Der "personalisierende" Bestandteil ist das USERPW, das ist das Passwort, worüber wir redeten.
Es dürfte klar sein, dass bei so einem zentralisierter Ansatz diesesPasswort ganz besonders schützenswürdig ist (ähnlich wie bei Passwortsafes, die mit einem Masterpasswort arbeiten). Zwischendrin wende ich die üblichen Mechanismen an wie Verwendung verschiedener krypt. Hashfunktionen, Hashing über <n|n=einige > Runden usw...

Ich werde aber erstmal das Passwort aus der Session rausnehmen, dann muss es halt für jede Berechnung eingegeben werden. Faulheit war ja schon immer der Feind von Sicherheit

Das Passwort hat auf dem Client nichts zu suchen.

Danke für den Twitter-Hinweis, diese Aussage stimmt auch für "mit Sitzungsschlüssel verschlüsseltes Passwort". Von dem Cookie-Gedanken bin ich auch weg mittlerweile.

Im Moment sehe ich zwei Möglichkeiten:
a) Nicht faul sein! Userpasswort nicht in Session schreiben und immer eintippen, wenn es gebraucht wird.
b) Damit das Userpasswort nicht im Klartext auf der Platte des Servers landet, es in zwei Sessionvariablen aufteilen: 1:Sitzungsschlüssel 2:Verschlüsseltes Userpasswort. Wenn das Passwort gebraucht wird, muss 2 mit 1 entschlüsselt werden. Es ist klar, dass das kein großer Sicherheitsgewinn ist. Aber allemal besser, als Passwort im Klartext in der Sessionvariable.

[mermshaus]

Zwischendrin wende ich die üblichen Mechanismen an wie Verwendung verschiedener krypt. Hashfunktionen, Hashing über <n|n=einige > Runden usw...

Keine Ahnung, ob ich richtig interpretiere, was du da machst, aber das Anwenden von verschiedenen Hash-Funktionen nacheinander verschlechtert üblicherweise die Sicherheit, da zumindest die Chance auf Hash-Kollisionen ansteigt. Ein hash() der "gesalzenen" Eingabe mit sha512 (oder so) ist so ziemlich die beste Idee, wenn es um Passwort-Hashes geht.

[sumiyou]

Ich konkateniere mit 3 verschiedene Hashfunktionen ein mal, wende sh512 n* an und konkateniere dann das Ergebnis wieder aus 3 Hashfunktionen. Ja, Mehrfachanwendung von sha512 ist wahrscheinlich der Entropie nicht förderlich, aber ist dennoch der Weg hier (linearer Zeitverlust beim Angriff).

salt fällt hier weg, weil ja hier eine eindeutige, unversalzene Ausgabe gebraucht wird.

EDIT: OK ich sehe gerade, ich warf so einiges an Hashing-Algorithmen ins Spiel Für große "$rounds" freut sich der Server $_SESSION['pass'] ist das Klartext-Eingabepasswort, welches wir oben besprachen. $mixing_pw ist die Variable, von der die Ausgabe unter anderem abhängig gemacht wird.

$mixing_pw=hash("whirlpool", $_SESSION['pass']).hash("gost", $_SESSION['pass']).hash("ripemd320", $_SESSION['pass']);
for ($i=0; $i<$rounds; $i++)
    $mixing_pw=hash("ripemd256", $mixing_pw).hash("sha256", $mixing_pw).hash("whirlpool", $mixing_pw);
$mixing_pw=hash("sha512", $mixing_pw); 

Insgesamt muss ich nochmal sagen, dass ich das nur für mich als Privatspaß mache. Die Konzepte versuche ich dennoch optimal zu wählen. Der Vorteil hier ist auch, dass ich das ganze auch mittels Windows cmd.exe plus ein paar GNU-Tools (relativ aufwändig) auf Clients berechnen lassen kann. Allerdings mit vorgeneriertem $mixing_pw, das ich GPG-verschlüsselt liegen habe und durch eine Pipe bekomme...

Spaß pur

[mermshaus]

Wieso nicht einfach:

$mixing_pw=hash("sha512", $_SESSION['pass']);
usleep(100000); 

Edit: Beide Varianten (deine und meine) erzeugen zu derselben Eingabe einen 128 Zeichen langen Hashwert. Bei einem Brute-Force-Angriff wird versucht, durch das Durchprobieren von Eingaben diesen Hashwert zu treffen. Je mehr Runden du dein Script laufen lässt, desto einfacher machst du das, denn desto mehr Eingaben führen durch Hash-Kollisionen zum schließlich ermittelten Hashwert.

[sumiyou]

sleep bringt nichts, wenn man Angriffe abwehren will, die Außerhalb durchgeführt werden. Wenn also jemand meinen Algorithmus kennt (was ich voraussetze) und das bei sich durchführt.
Ich gehe momentan davon aus dass, die Folgen der Mehrfachanwendung -siehe for-Schleife- für meine Anwendung vernachlässigbar ist. Wie es sich mathematisch verhält, können wir vermutlich nur schwer einschätzen, darüber bin ich noch nicht ganz sicher.

Hier noch etwas zur Auflockerung:

[nikosch]

Eingabe:
SERVICE_NAME: php.de
USERNAME: sumiyou
YEAR: 2010
LENGTH: 15
USERPW: geheimpasswortx498754hfssdjklsdfjkl

Ausgabe:
PW: UtfpMxZ0GdO21Y1

Versteh gar nicht, was das für einen SInn haben soll.

[sumiyou]

Versteh gar nicht, was das für einen SInn haben soll.

So kann ich Dienstepassworte berechnen, wann immer ich sie brauche. Habe es mal für Euch zum Anschauen hochgeladen, ist da aber keine SSL-Seite. Ist etwas seltsam gemacht, weil ich das ja nur nutze - und meine HTML-Kenntnisse sind nicht so toll. Ich frage mich noch, wie ich es hinbekomme, dass [Enter] den "Generate"-Button antriggert.

    /**
     *  Username, Password and E-Mail adress generator
     *
     * Results depend as follows:
     * Username: Service name, Mixing PW
     * Password: Service name, User name, Mixing PW, Year, Length
     * E-Mail:   Service name, User name, Mixing PW
     *
     * [...] **/ 

[nikosch]

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

Auf der anderen Seite existiert ohne das User-PW überhaupt keine „Zufalls“komponente mehr. Insofern man die anderen Daten in Erfahrung bringen kann (sehr einfach z.B. USERNAME) basiert das Dienstpasswort nur noch auf Unwissen über den verwendeten Algorithmus (security by obscurity).