[Holgerwa]

Hallo!
Ich habe bisher nur sehr wenig mit PHP gemacht, daher würde ich gerne sicher sein, ob diese Überlegung richtig ist:
Ich habe ein PHP-Skript, das Login-Daten eines Benutzers prüft. Es werden also Name und Paßwort entgegengenommen und diese mit einer Liste verglichen. Und genau um diese Liste geht es. Der Inhalt sollte unter keinen Umständen einsehbar sein. Daher habe ich diese Daten in eine Datei geschrieben und diese außerhalb des WWW-Bereichs auf dem Linux-Server gespeichert. Soweit ich weiß, kann man von außen nicht auf Dateien zugreifen, die nicht im Public-HTML-Verzeichnis eines Apache-Servers liegen.
Daher sollten die Daten in dieser Datei absolut sicher sein?!?
Oder gibt es Möglichkeiten, so etwas zu umgehen und ich sollte das lieber anders machen? Es dürfte doch nicht möglich sein, die Daten, die ein PHP-Skript intern einliest, von außen einzusehen?

Vielen Dank und viele Grüße,
Holger

[Bleistift]

Speicher lieber nur einen Hash des Passworts ab (One-Way-Verschlüsselung). Siehe dazu z.B. http://php.net/md5

[Holgerwa]

Hallo,
das mach ich für das Paßwort, aber mir geht es auch darum, daß gar keine Daten aus dieser Datei zugänglich sind, denn die "Login-Namen" sind Email-Adressen.
Deshalb die Idee, alle wichtigen Daten an einem Platz aufzubewahren, an dem sie nicht zugänglich sind.
Geht das?

Viele Grüße,
Holger

[Bleistift]

Am erwähnten Ort sind sie vor Zugriff via Web-Server grundsätzlich sicher. Du könntest noch eine .htaccess-Datei mit dem Inhalt "Deny from all" anlegen, falls mal was falsch konfiguriert ist. So könntest du die Datei übrigens in einem eigentlich zugänglichen Unterordner von public-html platzieren

[Basti]

Hallo Holger.

Ja, das sollte so passen, falls dein Provider nicht gepfuscht hat. Mögliche Lücken sehe ich spontan hier:

- Durch falsch gesetzte Rechte können andere Kunden auf dem Server auf die Datei zugreifen;
- Die Datei liegt noch innerhalb eines weiteren doc_root;
- Ein öffentlicher (öffentlich lesbarer) FTP-Zugang;
- Ein PHP-Skript, das die Daten bei Übergabe ungünstiger Parameter ausgibt;

Basti

[Holgerwa]

Hallo,
das hört sich gut an, dann versuch ich mal mein Glück!

Vielen Dank für Eure Hilfe!
Holger

[Flor1an]

Theoretisch kannst du die Email auch mit md5() verschlüsseln, dann hast du immer nur ein paar aus zwei Hashes! Dann kannste beide vergleichen aber die Daten nicht erkennen.

[Jojo]

Allerdings - so habe ich es gelernt - ist md5() für die Verschlüsselung von Passwörtern weder gedacht noch geeignet.
Da md5() einen ultimativ repräsentativen Hash errechnet, ist er - zum Beispiel - dafür gedacht, Fehler bei einem Dateitransfer über ein Netzwerk zu entdecken.

Die ultimative Repräsentativität (also, dass er bei allen md5()-Aufrufen gleich ist) macht ihn allerdings leider für Rainbow Tables angreifbar.

Die Funktion crypt() hingegen ist genau für den Einsatz bei Passwortverschlüsselung konzipiert und bringt einen weiteren Faktor zum Hash-Errechnen mit: den Salt.
Damit unterscheidet sich je nach gewähltem Salt das Ergebnis, was zur Folge hat, dass für jedes mögliche Salt eine eigene Rainbow-Table angelegt werden müsste.

Ich persönlich bevorzuge diesen Algorythmus zum Erstellen eines PW Hashes:

PHP-Code:

$cryptpw = crypt($pw); 


Wobei PHP einen automatisch generierten Salt nimmt.
Der Witz liegt dabei darin, dass der Salt immer an den Anfang des verschlüsselten Strings gehängt wird und man zum Vergleichen einfach den verschlüsselten String selbst als Salt benutzen kann, denn je nach Verschlüsselung werden nur die ersten x Zeichen als Salt benutzt.

Mein Vergleich sieht daher so aus:

PHP-Code:

if ($cryptpw == crypt($pw, $cryptpw)) {
  echo "Du bist drin!";
} 


Man möge mich berichtigen, wenn ich Stuss gelabert habe...

Jojo

[Basti]

sha1() und md5() kannst du auch salzen, was spricht dagegen? Und, wenn bei jedem Aufruf der Verschlüsselung (durch dein System) nicht der gleiche Hash bei rauskäme, wäre das ganze Verfahren ziemlich unsinnig.

Basti

[mepeisen]

Hash != Verschlüsselung. bei einem Hash wird nur ein Weg unterstützt, nämlich der vom Ursprungstext zum Hash. Zurück geht es nicht und zwar aus einem sehr einfachen Grund: Alle gängigen Hash-Algorithmen können nie garantieren, dass der Hash eindeutig ist. So kann "a" und "b" zum gleichen Hash führen mit der Auswirkung, dass "b" als Passwort akzeptiert würde, selbst wenn der ursprüngliche User "a" eingetippt hat. Und da könnt ihr noch soviel salzen, wie ihr wollt. Vergesst es. Hashes sind unsicher, gesalzen oder nicht.

[Flor1an]

Was allerdings auch wieder irgendwo egal ist. Wenn es jemand darauf abgesehen hat einen Hash zu knacken und per Brute Force alle Passwörter ausprobiert ist es egal ob er jetzt das richtige oder eine "alternative" findet. Und bei md5() tretten Kollisionen bei den normalen Passwort konstellationen nicht auf.

Wenn das Passwort jetzt noch mit nem Salt zusammen gehasht wird gibt es dafür auch keine Rainbow Tables. Fürs Web sollte das eigentlich ausreichen!

Vor allem in der Hinsicht dass falls jemand an deine ganzen Passwörter die per crypt verschlüsselt sind heran kommt, dann wird er wohl genauso an den Salt mit dem die Passwörter verschlüsselt sind heran kommen! Und dann ist das ganze noch gefährlicher.

[Basti]

Ich schnalls nicht so recht: crypt() benutzt auch ausschließlich Einweg-Verschlüsselungs-Verfahren. Es geht doch hier garnicht um den Vergleich von Verschlüsselung vs. Prüfsummen.

Ein Hash, der mit deinem salt erstellt wurde bringt dir nichts, wenn du das Salz nicht kennst (z.B. wenn jemand lesenden Zugriff auf die Datenbank hat, nicht aber auf das Dateisystem in dem der salt gespeichert ist). Kennst du allerdings das Salz auch, kannst du daheim in aller Ruhe versuchen, einen Treffer zu landen und musst damit nicht das Zielsystem penetrieren.

Basti

[Jojo]

Zitat von Basti

Kennst du allerdings das Salz auch, kannst du daheim in aller Ruhe versuchen, einen Treffer zu landen und musst damit nicht das Zielsystem penetrieren.

Aber es ist wesentlich billiger, eine Rainbow Table zu nutzen, als per Bruteforce einen Treffer zu landen.

Natürlich kann man md5 salzen, macht aber kaum einer.
Crypt() hingegen zwingt dem Benutzer dieses Verfahren auf.
Daher ist es vom Prinzip her sicherer.

@mepeisen
Ich habe von crypt() nicht als Mehrwegeverschlüsselung gesprochen.
Latürnich ist es auch eine Ein-Weg-Verschlüsselung.
Wobei natürlich die Frage auftritt, ob eine Verschlüsselung per Definitionem wieder zangsweise entschlüsselt werden können muss.

[mepeisen]

Das Problem ist, dass Verschlüsselung ein allgemeiner Begriff ist, also prinzipiell eine "Verfälschung" eines Inhalts. Du kannst auch den Inhalt Zeichen für Zeichen als Hex-String ausgeben. Sowas kann man auch Verschlüsselung nennen, obgleich die sehr plump ist.
Das gefährliche daran ist die Annahme, dass eine Verschlüsselung immer eindeutig sein muss bzw. ist das die weitverbreitete Meinung.

Im Prinzip will man doch, dass man eine eindeutige Passwort-Prüfung hat und dass man - für den Fall eines Einbruchs ins System - die Daten sicher hat. Beides zusammen geht nicht mit einem einfachen Hash. Gut, den Salt müsste man wissen, um schnell ne Rainbow Table an die Hand zu kriegen. Aber muss man den wirklich kennen? Wie wird eine Rainbow-Table errechnet? Nicht durch Trial and Error sondern durch Reverse Engineering des Hash-Algorithmus. Und da lassen sich jederzeit Salts mit einbeziehen. Wenn die normale Rainbow-Table nicht funktioniert, kann man den möglichen Salt errechnen und je mehr Passwörter man probiert, desto eindeutiger wird er bis nur noch einer übrig bleibt. Fakt ist, dass es ziemlich leicht ist, den Salt herauszufinden, selbst wenn man die Datei mit den verschlüsselten Passwörtern nicht zur Hand hat. Das ist dann eine Mischung aus Rainbow-Tables und Bruteforce.

Aber mal zurück zur Ausgangssituation. Man will die Passwörter verschlüsseln (im ursprünglichen Sinn des Wortes), damit für den Fall eines Angriffs das ganze nicht weiter schlimm ist, will aber dadurch auf der Webseite nicht Tür und Tor öffnen. Die Lösung ist simpel: Für jeden User einen eigenen zufälligen Salt nehmen, der sich aus einer in der DB gespeicherten Random-Zahl ergibt. Selbst wenn man dann zufällig für User X ein Passwort findet, das passt und damit auf eine Raindbow-Table und einen Salt kommen könnte, passt das plötzlich bei User Y nimmer. So ein Schutz reicht in meinen Augen.

[Jojo]

Zitat von mepeisen

Für jeden User einen eigenen zufälligen Salt nehmen, der sich aus einer in der DB gespeicherten Random-Zahl ergibt. Selbst wenn man dann zufällig für User X ein Passwort findet, das passt und damit auf eine Raindbow-Table und einen Salt kommen könnte, passt das plötzlich bei User Y nimmer. So ein Schutz reicht in meinen Augen.

Aber das kann man doch auch - wie in meinem Codeblock - PHP überlassen.
Wenn kein Salt angegeben wird, generiert es doch einen zufälligen
Oder ist das unsicherer als eine manuelle Salterzeugung?

[Basti]

Zitat von mepeisen

Das Problem ist, dass Verschlüsselung ein allgemeiner Begriff ist, also prinzipiell eine "Verfälschung" eines Inhalts. Du kannst auch den Inhalt Zeichen für Zeichen als Hex-String ausgeben. Sowas kann man auch Verschlüsselung nennen, obgleich die sehr plump ist.
Das gefährliche daran ist die Annahme, dass eine Verschlüsselung immer eindeutig sein muss bzw. ist das die weitverbreitete Meinung.

Redet hier doch niemand von.

Im Prinzip will man doch, dass man eine eindeutige Passwort-Prüfung hat und dass man - für den Fall eines Einbruchs ins System - die Daten sicher hat. Beides zusammen geht nicht mit einem einfachen Hash.

Wie denn dann?

Fakt ist, dass es ziemlich leicht ist, den Salt herauszufinden, selbst wenn man die Datei mit den verschlüsselten Passwörtern nicht zur Hand hat.

Whow, du kannst zaubern! Aber erklär dich. Wie bekommt man den Salt raus, wenn man den Hash nicht kennt? Was hat man denn dann für Informationen? Bleibt ja nur der Algorithmus und das Passwort! Ersterer ist eh bekannt, aber wie bekommt man jetzt ausschließlich anhand eines Passwortes heraus, mit welchem Salz es auf irgendeinem System wohl verschlüsselt ist (oder sein wird)?

Aber mal zurück zur Ausgangssituation. Man will die Passwörter verschlüsseln (im ursprünglichen Sinn des Wortes), damit für den Fall eines Angriffs das ganze nicht weiter schlimm ist, will aber dadurch auf der Webseite nicht Tür und Tor öffnen. Die Lösung ist simpel: Für jeden User einen eigenen zufälligen Salt nehmen, der sich aus einer in der DB gespeicherten Random-Zahl ergibt. Selbst wenn man dann zufällig für User X ein Passwort findet, das passt und damit auf eine Raindbow-Table und einen Salt kommen könnte, passt das plötzlich bei User Y nimmer. So ein Schutz reicht in meinen Augen.

Kann ich nachvollziehen, aber die Lücke, die hier noch gestopft wird ist doch minimal in Relation zu den üblichen Angriffsvektoren auf Web-Anwendungen. Der Fall, in dem diese Methode ein Mehr an Schutz bringt ist der, dass der Angreifer a) das Passwort eines Benutzers kennt, b) den Hash in der Datenbank (und damit ggf. c) den Salt), aber weder hashes, noch Salts der anderen Benutzer auslesen, noch deren Passwörter abfangen kann. Ist doch ziemlich unwahrscheinlich, oder?

Nicht, dass ich es deswegen schlecht reden will, aber diese Massnahme für den Fall, dass ein Angreifer bereits zumindest teilweise ins System eingestiegen ist fällt dann eben in die Kategorie Schadensbegrenzung.

Zitat von Jojo

Aber das kann man doch auch - wie in meinem Codeblock - PHP überlassen.
Wenn kein Salt angegeben wird, generiert es doch einen zufälligen

Jo, sicherer ist es schon, nur kannst du damit halt auch nichts mehr anfangen! crypt() ohne Salt gibt bei jedem Aufruf was anderes aus und selbst wenn es sich die Daten irgendwo merken würde,was wäre bei einem Upgrade oder einer Migration? Dann wäre es einfacher sich die Daten selbst zu merken und das ist das, was Martin hier vorschlägt.

Basti

[Jojo]

Zitat von Basti

Jo, sicherer ist es schon, nur kannst du damit halt auch nichts mehr anfangen! crypt() ohne Salt gibt bei jedem Aufruf was anderes aus und selbst wenn es sich die Daten irgendwo merken würde,was wäre bei einem Upgrade oder einer Migration? Dann wäre es einfacher sich die Daten selbst zu merken und das ist das, was Martin hier vorschlägt.

Siehe:

PHP-Code:

if ($cryptpw == crypt($pw, $cryptpw)) {
  echo "Du bist drin!";
} 


Funktioniert bei mir prima.
//edit:
Latürnich bringt es nix, wenn man auf dem anderen System nicht auf die Verschlüsselung achtet.
Da gebe ich dir recht.

[Basti]

Zitat von Jojo

Siehe:

PHP-Code:

if ($cryptpw == crypt($pw, $cryptpw)) {
  echo "Du bist drin!";
} 


Funktioniert bei mir prima.
//edit:
Latürnich bringt es nix, wenn man auf dem anderen System nicht auf die Verschlüsselung achtet.
Da gebe ich dir recht.

Achso. Und das soll den Algorithmus verbessern? Kann ich mir kaum vorstellen.

Basti

[Jojo]

Zitat von Basti

Achso. Und das soll den Algorithmus verbessern? Kann ich mir kaum vorstellen.

Verstehe grade nicht dein Problem
Ich wollte lediglich wissen, ob es einen Vorteil birgt, wenn man die Salts separat speichert. Denn das Salt wird sowieso vorne an den Verschlüsselten String gehängt.
Wenn man auf einem anderen System arbeitet und eine andere Verschlüsselung benutzt, dann bekommt man auch ein Problem, wenn man die Salts separat ablegt.
Maximal könnte man überprüfen, ob die falsche Verschlüsselung aktiviert ist.

Einen Algorithmus wollte ich damit gar nicht verbessern. Wenn überhaupt verkürzen.

[mepeisen]

Zitat von Basti

Wie denn dann?

Mit einer eindeutigen Verschlüsselungsmethode. Was weiss ich. SSL. Gibt aber auch einfachere. Klar hat man implizit dann ne Verschlüsselung, die zwei Wege unterstützt, die man also bei richtigen Informationen wieder zurückrechnen kann zum ursprünglichen Wert.

Zitat von Basti

Whow, du kannst zaubern! Aber erklär dich. Wie bekommt man den Salt raus, wenn man den Hash nicht kennt?

Ne nitt zaubern, das ist binäre Logik Es ist wie ich sagte relativ einfach. Die Betonung ist aber auf dem Wörtchen "relativ". Du brauchst nur zwei Konstanten im System, wofür du ggf. das System selbst nutzen kannst. Bei einer Webseite ist das relativ einfach, weil du dort ja meist selbst einen Account erstellen kannst. Alternativ macht man ein Trial-and-Error Spielchen, um einen Account mit Passwort zusammenzubringen. Sobald du diesen Account mit Passwort hast, hast du bereits eine Zuordnung. Hashes lassen sich zurückrechenn und dort beziehst du den Salt als Variable X ein. Nun wieder mit verschiedenen Salts ein Trial-and-Error-Spielchen und wenn wieder ein (nun neues) Passwort passt, hast du viele andere mögliche Salts eliminiert. Das machst du nun solange bis ein Salt übrig bleibt. Kommt jetzt auf den Algorithmus an, der dem Salt zugrunde liegt. Mag auch sein, dass es vielen Hackern oder Freizeithackern zu aufwändig ist, aber es gibt genug Tools, die sowas können.

Zitat von Basti

Nicht, dass ich es deswegen schlecht reden will, aber diese Massnahme für den Fall, dass ein Angreifer bereits zumindest teilweise ins System eingestiegen ist fällt dann eben in die Kategorie Schadensbegrenzung.

Wenn man etwas Ausdauer mitbringt und Bot-Netzwerke tun dies teilweise, kann man das ganze bereits ohne vorher ins System eingedrungen zu sein. Und Tools, die unter Einbeziehen von Salts auf gängige Hash-Algorithmen ne Rainbow-Tabelle zurückrechnen, gibt es ebenfalls. Die Frage ist natürlich, inwieweit ein Angreifer sich generell für eine private Homepage interessiert mit vielleicht 20 Usern. Von daer gebe ich dir mal recht. Aber man sollte trotzdem nicht zu blauäugig durchs Leben gehen. Mein neues Projekt hat exakt 6 User registriert. Es erzeugt derzeit etwa 20 Visits am Tag. Und Bots haben die bereits merhfach abgegrast, immer mal was anderes, immer mit dem Ziel, irgendwie ins System zu kommen, um Spam zu verbreiten. Das stimmt einen u.U. bedenklich.