Gedanken zu sicherem Login mit PHP und MySQL

[Money Making Machinist]

Hi,

bin selbst noch ziemlich neu in PHP und wollt deshalb die Meinungen von anderen schon erfahreneren PHPlern.

Was meint ihr, worauf sollte man achten für einen einigermassen sicheren Login?

Lasst euch hier euren Gedanken freien Lauf was man tun kann/könnte und auf jeden Fall sollte.

Danke schon mal im Vorraus.

[baba007]

md5, errechnet den MD5-Code eines Strings ... das ist alles was du brauchst.

md5($usr_pass);

$usr_pass muß auch so in der DB abgespeichert werden, sonst kannst du nicht vergleichen

[Aiun]

'Sicher' ist schwierig, es gibt immer einen Weg es zu umgehen, aber lass dich nicht von evtl. extrem-schwarzseherischen Posts die vermutlich folgen werden beeinflussen *g*

1.-------

An sich ist eine Session ganz nett, somit liegst du nicht auf Cookies fest.

Doch eine Session-ID kann nachgebaut werden, und dann hat man den Salat.

Um die sicherheit zu erhöhen logge ich die IP mit, die zu einer Session-ID gehört. Schon wg. Datenschutz natürlich nur die aktuelle / nötige IP, jeweils aktualisiert beim Login.

Sollte sich also die IP ändern *schwups* draußen. Ich habe mich noch nicht genau damit befasst, aber ich bin sicher es gibt noch mehr Parameter mit denen du feststellen kannst, das eine Anfrage immer vom gleichen Rechner kommt.

2.-------

Pass' auf das du keine Register_Global Variablen, sondern immer schön $_GET, $_POST, $_REQUEST, $_SESSION unsw. verwendest und die am besten noch durch ein html_entities jagen, damit keine HTML / Datenbankmanipulation möglich wird.

[Aiun]

ich erweitere mal Baba007, speichere in der Datenbank "nie" das Passwort, sondern immer den md5-Hash. Sollte jemand einblicke in die Datenbank bekommen, hilft ihm das dann auch nicht viel weiter.

dann vergleichst du md5($_POST['eingabe']) == $datenbank->passwort

[baba007]

2.-------

Pass' auf das du keine Register_Global Variablen, sondern immer schön $_GET, $_POST, $_REQUEST, $_SESSION unsw. verwendest und die am besten noch durch ein html_entities jagen, damit keine HTML / Datenbankmanipulation möglich wird.

$_GET bitte nicht beim PW

[Jaraz]

Um die sicherheit zu erhöhen logge ich die IP mit, die zu einer Session-ID gehört. Schon wg. Datenschutz natürlich nur die aktuelle / nötige IP, jeweils aktualisiert beim Login.

Womit du alle die zwischendurch z.b. Offline gehen aussperrst.

Sicherer Login und Datenübertragung geht im Internet nur über SSL.

Wie du dann auf dem Server das Passwort speicherst ist eine andere Sache.

Da ist das beschriebene MD5 ok.

Gruß Jaraz

[Money Making Machinist]

2.-------

Pass' auf das du keine Register_Global Variablen, sondern immer schön $_GET, $_POST, $_REQUEST, $_SESSION unsw. verwendest und die am besten noch durch ein html_entities jagen, damit keine HTML / Datenbankmanipulation möglich wird.

Gibt es Funktionen die einen String nach html/sql-Sach durchsuchen oder muss ich eine solche Funktion selberschreiben?

ich erweitere mal Baba007, speichere in der Datenbank "nie" das Passwort, sondern immer den md5-Hash. Sollte jemand einblicke in die Datenbank bekommen, hilft ihm das dann auch nicht viel weiter.

dann vergleichst du md5($_POST['eingabe']) == $datenbank->passwort

Versteh ich dich richtig, ich soll das Passwort als md5 (was ist überhaupt genau ein Hash, sind das nicht diese Zufallszahlen) codiertes Passwort speichern, also nicht das Passwort selbst? Ändert sich nicht die md5 ständig?

$_GET bitte nicht beim PW

Das war glaub so das erste, was ich gedacht hab, als ich gelesen hatte was $_GET ist .

Sicherer Login und Datenübertragung geht im Internet nur über SSL.

Wie du dann auf dem Server das Passwort speicherst ist eine andere Sache.

Da ist das beschriebene MD5 ok.

Welche Möglichkeiten der Passwort speicherung gäbes es denn noch? Und ist SSL schwer zu realisieren?

[geloescht_JesterDay]

Womit du alle die zwischendurch z.b. Offline gehen aussperrst.

Ist ja auch Sinn der Sache. Wenn man wieder online kommt, meldet man sich neu an und gut is. Auch wenn die Session-ID nicht gerade leicht nachzumachen ist (32 Zeichen alphanumerisch), kann sie u.U. dennoch "geklaut" werden oder wenn man sich nicht auf Cookies verlassen will und sie in der URL mitgibt z.B. an einem Bookmark hängen. Von daher ist die beschränkung auf die IP-Adresse ansich ne gute Idee. Ich war aber immer zu faul bzw. die Daten nicht sooo relevant

Welche Möglichkeiten der Passwort speicherung gäbes es denn noch? Und ist SSL schwer zu realisieren?

Klartext, als Hash (md5 ist nur einer vom vielen, wird aber z.B. von MySQL und PHP direkt unterstützt), normale Verschlüsselung. Wobei Klartext ja jedem als nicht praktikabel auffallen sollte. Verschlüsselung scheint auf den ersten Blick ja noch gut zu sein, aber es ermöglicht immernoch das auslesen des Passworts, wenn auch nicht mehr so leicht. eine Verschlüsselung kann immer rückgängig gemacht werden und das wollen wir ja nicht

Ein Hash funktioniert nur in 1 Richtung. Du kannst aus dem Passwort einen (eindeutigen) Hash erzeugen, aus dem Hash aber nie wieder dein Passwort (ausser BruteForce, also alle Kombinationen Hashen bis eine übereinstimmt).

SSL ist sehr einfach, es muss dir z.B. von deinem Webspace-Provider nur angeboten werden. Auf einen bestimmten Ordner kannst du dann nur per HTTPS-zugreifen z.B.

Wenn du den Server selber betreibst, brauchst du nur Apache2, da ist SSL mit integriert. Bei Apache 1.x musst du dafür eine spezielle Version laufen lassen, die aber dann nur SSL kann.

Wenn du das hast legst du nur einen Eintrag (VirtualHost)in der httpd.conf an und zwar bsp. <VirtualHost *:443> . 443 ist der Standardport für SSL.

SSL verschlüsselt die Verbindung zw. Client und Server. Alles, was du dann überträgst kann erstmal von keinem entschlüsselt werden.

[Jaraz]

Ist ja auch Sinn der Sache. Wenn man wieder online kommt, meldet man sich neu an und gut is.

Dann hast du noch keine Anwendung die mit x tausend Usern läuft geschrieben.

Wenn ich jeden der etwas länger ließt und zwischendurch einen Timeout der Internetverbindung bekommt aus der Anwendung schmeißen würde, ständen die Telefone hier nicht mehr still.

Außerdem, die sichtbare IP-Nummer eines Benutzers kann während der Session wechseln. Viele Proxy-Server arbeiten in einem Cache-Verbund mit Lastverteilung. Die nach außen sichtbare IP-Nummer eines Anwenders wird je nach Lastsituation im Cache-Verbund diejenige IP-Nummer des am wenigsten ausgelasteten Proxy-Servers sein.

Session IDS raten ist praktisch unmöglich.

Wer Sie ausspioniert (Logfiles, Trojaner) und so versucht sie zu übernehmen, den hält auch die IP nicht auf.

Gruß Jaraz

[geloescht_JesterDay]

Dann hast du noch keine Anwendung die mit x tausend Usern läuft geschrieben.

Wenn ich jeden der etwas länger ließt und zwischendurch einen Timeout der Internetverbindung bekommt aus der Anwendung schmeißen würde, ständen die Telefone hier nicht mehr still.

Nein, hab ich noch nicht Aber ich stell es mir nicht so häufig vor, dass es einen INet Timeout gibt. Was wohl eher vorkommt ist ein Session-Timeout, aber den hast du auch so.

Aber ich hab sowas wie gesagt noch nicht selbst benutzt, finde es aber für wirklich sicherheitsrelevante Dinge dennoch gut. Da haben wir aber dann wieder das alte Problem: Bequemlichkeit vs. Sicherheit.

Und ich denke auch nicht, dass jemand eine Session-ID erraten kann. Dennoch halte ich es nicht von vorneherein für so verkehrt, das nochmal zu sichern.

[Money Making Machinist]

Klartext, als Hash (md5 ist nur einer vom vielen, wird aber z.B. von MySQL und PHP direkt unterstützt), normale Verschlüsselung. Wobei Klartext ja jedem als nicht praktikabel auffallen sollte. Verschlüsselung scheint auf den ersten Blick ja noch gut zu sein, aber es ermöglicht immernoch das auslesen des Passworts, wenn auch nicht mehr so leicht. eine Verschlüsselung kann immer rückgängig gemacht werden und das wollen wir ja nicht

Ein Hash funktioniert nur in 1 Richtung. Du kannst aus dem Passwort einen (eindeutigen) Hash erzeugen, aus dem Hash aber nie wieder dein Passwort (ausser BruteForce, also alle Kombinationen Hashen bis eine übereinstimmt).

Ich glaub ich habs verstanden. Das User Passw wird bei der Anmeldung zum Hash. Und wenn der User sich einloggt wird seine Passw auch wieder zum Hash und wenn beides stimmt, passt ja alles. Aber der Hash kann nicht mehr zum Passw werden, also eigentlich könnte man den auch veröffentlichen (was ich aber auf keine Fall vorhab). Das ist echt gut gemacht. Mach ich auf jeden Fall so, scheint vernünftig zu sein.

[Money Making Machinist]

Wie sieht des den eigentlich aus mit den SSL-Zertifikaten. Braucht/Bekommt man eins wenn man nur Login für Userdaten hat, also keinen Onlineshop.

[geloescht_JesterDay]

Wie sieht des den eigentlich aus mit den SSL-Zertifikaten.

Die kannst du dir selber erstellen. Allerdings sind die dann nicht signiert und der Nutzer erhält eine Warnung. auch wenn du eines signieren lassen willst (gibt mehrere dienste, die das anbieten...), musst du erst eins selber erstellen.

Falls du den Apache2 benutzt brauchst du eh z.B. OpenSSL und damit erzeugst du auch einen Key:

openssl genrsa -out server.key -des3 1024

Damit wird der Schlüssel "server.key" erzeugt. Den kannst du jetzt zu einem Zertifizierungsinstitut schicken oder unterschreibst das Zertifikat selber:

openssl req new -x509 -days 1460 -key server.key -out server.crt

Damit wird ein für 4 Jahre (1460 Tage) gültiges Zertifikat erzeugt (server.crt). Diese beiden Dateien kopierst du dann in den conf Ordner deines apache2, schützt sie entsprechend (kein Schreibzugrif für keinen und lesen auch nur wer unbedingt muss) und was noch fehlt ist die Angabe in der httpd.conf:

<VirtualHost *:443>

...

SSLEngine On

SSLCertificateFile conf/server.crt

SSLCertificateKeyFile conf/server.key

...

</VirtualHost>

Dann musst du nur bei jeden Start den apache das PW des Key-files eingeben. Das PW entfernst du so:

openssl rsa -in /path/to/apache/conf/server.key -out /path/to/apache/conf/server_neu.key

Damit ist der Schlüssel aber ungeschützt (weil kein PW mehr)! Ausserdem musst du das in der httpd.conf anpassen.

[Aiun]

@Jaraz, ich habe mitlerweile einige Anwendungen für "zahlreiche" Benutzern geschrieben. Intranetseiten für ca. 1500 Mitarbeiter u.A. ... so viel zu deiner Frage / Aussage.

Ein automatischer Logout bei schließen des browsers wird häufig "verlangt" um sicher zu stellen das niemand auf daten eines anderen zugreifen kann.

Eine Session-ID zu "klauen" ist schwierig, aber je mehr benutzer desto 'möglicher' und auch schon mehrfach vorgekommen. Die IP-Adresse eines Benutzers ändert sich normalerweise nicht 'einfach so' und ansonsten muss man halt gugen was es an anderen Variablen gibt, die man mitloggen kann.

[Jaraz]

@Jaraz, ich habe mitlerweile einige Anwendungen für "zahlreiche" Benutzern geschrieben. Intranetseiten für ca. 1500 Mitarbeiter u.A. ... so viel zu deiner Frage / Aussage.

Schön für dich. Ist die Frage ob die auch von extern regelmäßig zugreifen.

Weil, warum sollte die in einem Intranet zwischendurch andere IPs bekommen.

Ein automatischer Logout bei schließen des browsers wird häufig "verlangt" um sicher zu stellen das niemand auf daten eines anderen zugreifen kann.

Habe ich was anderes behauptet?

Eine Session-ID zu "klauen" ist schwierig, aber je mehr benutzer desto 'möglicher' und auch schon mehrfach vorgekommen. Die IP-Adresse eines Benutzers ändert sich normalerweise nicht 'einfach so' und ansonsten muss man halt gugen was es an anderen Variablen gibt, die man mitloggen kann.

Wie gesagt es ist höchstens eine Teilllösung, die aber technische Probleme mit sich bringt. Wer an die Session ID kommt, kommt auch an alle anderen Daten der Verbindung. (Über die Schulter schauen und Session ID merken, mal außen vor.) Wenn also die zu bearbeitenden Daten so brisant sind, kommt man um eine SSL Verbindung nicht herum.

Gruß Jaraz

[Aiun]

dann mal so rum: glaubst du hier in dem Forum wird 'irgendwo' eine SSL-Verbindung verwendet ? ... währen demnach nicht alle E-Mail adressen, MD5 Hashs unsw. die sicherheit wert ?