PHP Login = Sicherheit/SSL
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
array
beispiel
benutzen
benutzer
code
datenbank
datum
domain
frage
http
merkmal
nutzen
server
session
speichern
statement
url
verbindung
verwenden
zertifikat
-
1. Was kann man, um den Login so sicher zu machen wie möglich.? Man kann ja Session benutzen, Passwort verschlüsseln, SSL verwenden und die Post-Abfrage filtern. Gibt es andere Möglichkeiten?
2. Ist folgende mysql-Verbindung sicher oder kann man das auch hacken?
$link = mysql_connect($host, $user, $pass) or die ("Keine Verbindung zu der Datenbank möglich."); mysql_select_db($db, $link);
Gibt es auch eine andere, sichere Verbindung?
3. Wenn ich hier in LC eine SSL Zertifikat kaufe, gilt die dann für alle Domain die ich gekauft habe oder nur für eine ausgewählte?
4. Kann man Passwörter, die gehasht sind, entschlüsseln? Wenn nicht, gibt es eine andere Verschlüsselung-Art, die man entschlüsseln kann. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Was das SSL Zertifikat angeht: Das geht nur für eine Domain. Wenn du das für eine andere Domain benutzen würdest käme der gleiche Fehler wie einem selbstsigniertem Zertifikat: Nicht vertrauenswürdig. Die Zertifizierungsstelle möchte ja auch noch was dran verdienen und einen Zuwachs an Sicherheit bringt es auch.
Bei der Verschlüsselung (https) ist es so, dass https nicht gleich sicher ist. Im folgenden Video wird z.B. gezeigt, wie leicht es ist TLS 1.0 zu knacken. Trotzdem ist der Präfix in der Adresszeile https.
Was deine MySQL Verbindung angeht: Solange du die Benutzerdaten nicht per GET übergibst und sie in einer PHP Datei zwischen den <?php ?> Tags speicherst, sollte sie eigentlich sicher sein. Hierfür aber natürlich kein Gewähr! -
Sicherheit ist immer etwas relatives. Ich kann nicht auf alles Antworten, möchte aber anfangen:
SSL wird genutzt um eine HTTPS Verbindung zu öffnen. Dank HTTPS ist die Verbindung zwischen Server und Client dann theoretisch Abhörsicher. Das heißt, dass Leute, die zwischen dem Server und Clienten sitzen, zwar den Traffic mitschneide können, aber nicht auslesen können. Damit wäre die Verbindung also "gesichert".
Sessions sind nur eine relative Sicherheit. Man kann natürlich IP, User-Agent und andere Merkmale nutzen, um wirklich sicherzugehen, dass es der ursprüngliche Verbindungscomputer ist. Nutzt man diese Merkmale zur Session-Absicherung, ist es für einen Angreifer schwerer eine Session zu übernehmen, auch bei erfolgreich gestohlendem Session-Key, aber nicht unmöglich. Allerdings macht alles, was es schwerer macht eine Hürde die den Angreifer aufhält, stört, und vielleicht sogar scheitern lassen könnte.
Ein Passwort wird nicht direkt verschlüsselt, eben da man es entschlüsseln könnte. Passwörter werden in der Regel gehashed. Ein Hash berechnet einen Wert aus dem entsprechendem Passwort, welcher für die gegebene Zeichenkette eigentlich einmalig ist (Kollisionen sollte es nicht geben, aber hier möcht ich nicht zu weit ins Detail gehen). Der Wert, den man so berechnet, kann man speichern. Liest ihn jemand fremdes aus, hat er nicht das Passwort, sondern nur einen berechneten Wert. Das entschlüsseln, oder rückrechnen, ist nicht möglich. Es gibt allerdings Angriffsmethoden: Sogenannte Rainbowtabellen zum Beispiel. Eine Rainbowtabelle ist eine Sammlung aller möglichen Kombinationen von Zeichen, bereits vorberechnet als Hashwert. Hier kann man den gefundenen Hashwert dann nachschlagen, Salts entfernen und hat das Passwort. Daher nutzt man variable Salts, und versucht so lang wie mögliche Salts zu nutzen (lange Zeichenketten sind oft noch nicht in Rainbowtables enthalten. Problem an denen ist aber auch, dass sie so unglaublich groß sind, beispielsweise https://www.freerainbowtables.com/de/tables2/)
Als letztes möchte ich noch die MySQL-Verbindung ansprechen. Die Schwäche von MySQL ist nicht die Verbindung, also das connect, sondern die query. Wenn fremde, böse Daten in die Query gelangen, kann dies zu einer MySQL-Injection führen. Mit einer MySQL-Injection kann jemand fremdes SQL Code ausführen, was böse folgen hat. Dagegen kann man sich wehren, wenn man prepared-Statements nutzt. Prepared-Statements werden von MySQLi und PDO unterstützt. Dies solltest du dir anschauen, um die Verbindung Injectionssicher zu machen.
Ich denke damit hast du schon ganz guten Input, mit dem du arbeiten kannst. Sollten noch Fragen offen stehen, kannst du diese gerne stellen, wenn ich sie erspähe antwort ich auch^^
Liebe Grüße -
ggamee schrieb: Prepared-Statements werden von MySQLi und PDO unterstützt.
Kann ich jetzt einfach schreiben:
mysqli_connect($host, $user, $pass);
Muss ich eine Mysqli-Datenbak holen? Oder geht mysqli anders? -
Eine kleine Einführung: http://php.net/manual/de/mysqli.quickstart.prepared-statements.php
MySQLi kann man interessanterweise als Objekt oder Prozedual nutzen. Da du das prozeduale Beispiel gepostet hast, verlinke ich nochmal dashier: http://php.net/manual/de/mysqli.prepare.php.
mysqli_connect verbindet mysql_connect und mysql_select_db:
mysqli_connect($host, $username, $password, $database);
Für weitere kleine Codebeispiele schau dir am besten die Seite für mysqli_prepare an.
MySQLi ist genauso wie PDO nur ein Verbindungstreiber. Die Datenbank dahinter kann eine normale MySQL-Datenbank sein, jedoch hat man einen anderen Verbindungstreiber, der mit den Prepared Statements eine Möglichkeit bietet SQL Injections erfolgreich zu unterbinden, wenn man sich konsequent daran hält. Dadurch kann es die Sicherheit erhöhen.
MySQLi und PDO geben also nur an, WIE dein PHP Server sich zur MySQL Datenbank verbindet, der PHP Server und die Datenbank bleiben dabei die gleichen.
Übrigens, noch etwas interessantes: Die eigentlichen mysql_xxx funktionen werden wohl bald aus PHP entfernt. Soweit ich mich erinnere in den PHP5.5 Changelog gelesen zu haben, wurde mysql_connect und die ganzen mysql_ Funktionen zugunsten von MySQLi und PDO deprecated.
Liebe Grüße -
Ein paar Fragen noch:
1.
hc-tools schrieb:
Was deine MySQL Verbindung angeht: Solange du die Benutzerdaten nicht per GET übergibst und sie in einer PHP Datei zwischen den <?php ?> Tags speicherst, sollte sie eigentlich sicher sein. Hierfür aber natürlich kein Gewähr!
Keine Gewähr? Willst du damit sagen, dass Hacker die Benutzerdaten in PHP lesen könnten?
2.
ggamee schrieb:
Sessions sind nur eine relative Sicherheit. Man kann natürlich IP, User-Agent und andere Merkmale nutzen, um wirklich sicherzugehen, dass es der ursprüngliche Verbindungscomputer ist. Nutzt man diese Merkmale zur Session-Absicherung, ist es für einen Angreifer schwerer eine Session zu übernehmen, auch bei erfolgreich gestohlendem Session-Key, aber nicht unmöglich.
Ich wusste gar nicht, dass man Session komplett stehlen kann. Session werden doch auf dem Client verwendet, oder?
3. Sollte man Passwörter als Session verwenden? -
onur-yavuz schrieb:
Diese Frage ist vielleicht nicht ganz richtig formuliert. Zuerst mal die Grundlagen:
3. Sollte man Passwörter als Session verwenden?
Eine Session zeichnet sich dadurch aus, dass einem Benutzer eine Sessionnummer (Session id) zugewiesen wird. Beim nächsten Aufruf schickt er diese wieder zurück und zeigt dem Server damit wer er ist. Um dies zu realisieren gibt es 2 Möglichkeiten:
1. Du verwendest die PHP-Session:
Am Anfang jedes Programms steht session_start();
Danach kannst du über das Array $_SESSION deine Daten Verwalten, z.B.$_SESSION["name"]="Otto";
und auf einer anderen Seiteecho "Dein Name ist ".$_SESSION["name"];
Du hast für jeden Benutzer ein eigenes Array, also wenn zwei Benutzer gleichzeitig auf der Seite sind, kann jeder seinen eigenen Namen speichern. Die Verwaltung mit den Session Id's und die Speicherung der Daten übernimmt PHP selbst. Du hast keine Arbeit damit.
2. Du machst eigene Sessions:
Du kannst mit setcookie() ein Cookie festlegen, das die Session-Id speichert und diese auf einer anderen Seite wieder in dem Array $_COOKIE auslesen. Die Daten, die dahinter liegen, musst du selbst in einer Datenbank speichern. Es ist etwas komplizierter, aber du kannst z.B. auch mal die Session-Id ändern. Das geht so viel ich weiß bei Variante 1 nicht.
Es ist auf jeden Fall nicht sinnvoll das Passwort als Session-Id zu benutzen, denn das Passwort ist wichtiger, als eine Session-Id. Eine Session ist im besten Fall nach einer Zeit abgelaufen. Wer aber das Passwort hat, kann sich beliebig oft wieder einloggen. Das Passwort sollte also nicht jedes Mal mitgeschickt werden.
onur-yavuz schrieb:
Dies ist hiermit auch geklärt. Eine Session stehlen bedeutet, dass man die Session-Id einer Person herausfindet und in den eigenen Browser einfügt. Man kann dann unter dem Namen der Person surfen.
Ich wusste gar nicht, dass man Session komplett stehlen kann. Session werden doch auf dem Client verwendet, oder? -
Hallo
Möchtest du eine große Seite aufbauen, oder lediglich ein paar Freunden den Login erlauben?
Wenn du dir nur einen privaten Bereich machen willst (z.B. Gästebuchadministration) reicht m.M.n. schon eine einfache Implementierung in PHP (ohne MySQL).
Ansonsten generell zur Passwortsicherheit:
Bei größeren und öffentlichen (=von Google indiziert, mit öffentlicher Registrierung und womöglich noch mit CMS) zum Speichern von Passwörtern keinesfalls Standardsachen nutzen, also einfaches md5() z.B., denn da gibt es schon Rainbowtables für alles bis 15 Zeichen. Klartext natürlich auch nicht.^^
Auch e-mail Adressen müssen nicht im Klartext gespeichert werden, natürlich nur wenn man keine unerwünschten Newsletter verschicken will.
Ich verwende sha512+salt1(sha512+salt2) für pw+email und erlaube maximal 25 Loginversuche (absichtlich so hoch gewählt) von einer IP Adresse innerhalb von 10 Minuten, bei einer Mindestlänge des Passworts von 8 Zeichen und geläufige Sonderzeichen sind erlaubt (z.B. kein äöüß aber -_!?=()" etc.).
Es gibt auch viele öffentlich verfügbare Passwortlisten, wie zum Beispiel diese hier: http://thepiratebay.sx/torrent/5945498/WPA-PSK_WORDLIST_3_Final_%2813_GB%29.rar
In eigenem Interesse sollten Benutzer lieber kein Passwort aus dieser Liste verwenden.
"Gehackt" werden kann eine Seite nur durch ungeprüfte Nutzereingaben. Es gibt dann aber noch exploits, sei es für ein CMS oder gar den ganzen Webserver, deswegen ist es sehr wichtig, dass die Passwörter ordentlich gehasht werden.
Ein SSL Zertifikat ist wichtig damit niemand im selben Netzwerk des Nutzers, oder die NSA an Internetknoten, Passwörter mitschneiden können.
Auch bei SSL Zertifikaten gibt es Unterschiede, zum Beispiel können Diffie-Hellman Parameter genutzt werden, sodass selbst mitgeschnittener Traffic mit dem Zertifikat nicht mehr entschlüsselt werden kann. Darum muss man sich aber selbst kümmern und das wird man bei einem Freehoster wohl nicht bekommen. Notwendig ist das aber nicht unbedingt und ich habe noch keine Webseite außer Google (mit unsicherem RC4) und meine damit gesehen.
TL;DR: Eingaben des Nutzers escapen und die Passwörter ordentlich hashen, SSL Zertifikat draufklatschen, fertig.
Ich verwende lieber Cookies, aber es soll ja Leute geben, die auf Sessions schwören..
mfg
Beitrag zuletzt geändert: 3.12.2013 17:32:34 von voloya -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
