Anmeldung immer überprüfen?
hallo,
ich bin gerade dabei, ein Webportal zu schreiben.
Dabei habe ich eine Frage zum Anmelden, und zwar:
Sollte man jedes mal, wenn eine Seite geladen wird die Anmeldedaten aus der Datenbank abfragen, oder ist es sicher genug, wenn man das in denn Session-Daten speichert?
Vielen Dank schonmal, für eure Hilfe!
Eike
ich bin gerade dabei, ein Webportal zu schreiben.
Dabei habe ich eine Frage zum Anmelden, und zwar:
Sollte man jedes mal, wenn eine Seite geladen wird die Anmeldedaten aus der Datenbank abfragen, oder ist es sicher genug, wenn man das in denn Session-Daten speichert?
Vielen Dank schonmal, für eure Hilfe!
Eike
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 143439
Url: https://administrator.de/contentid/143439
Ausgedruckt am: 15.11.2024 um 05:11 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
es kommt immer darauf an, was für einen Sicherheitsstandard man haben will oder muss.
Eine Sessionvariable zusammen mit einer SSL-Verbindung ist sicherlich für viele Anwendungsfälle OK.
Lediglich ein Cookie zur Identifizierung zu verwenden ist erheblich unsicherer. (In älteren Programmierbeispielen wurde häufig so verfahren, dass im Cookie der Username abgelegt war).
Ich verwende z.B. für (allerdings nur internes Netzwerk) einen GUID als Cookie und eine Verknüpfung zur IP des Rechners, an dem sich der User angemeldet hat und speichere diese zur Identifizierung in einer Datenbank.
Eine Session kann ich nicht verwenden, da die Zugriffe oft zu lange auseinander liegen und die Session somit ablaufen würde. Da ist sicherlich noch kein Verfahren für Onlinebanking, aber für's Intranet reicht es eben aus.
Ein anderer Ansatz wäre, die Sicherheit schon auf der Ebene des Zugriffs zu implementieren (also keine anonymen Zugriffe zulassen).
Dann kümmert sich der Server um die Authentifizierung. Allerdings muss die Anwendung dennoch selbst die Autorisierung für einzelne Zugriffe (wahrscheinlich soll nicht jeder alles dürfen / Nutzer-Rollenprinzip) sicher stellen.
Vielleicht hilft Dir das ja ein wenig bei Deinen Überlegungen weiter.
es kommt immer darauf an, was für einen Sicherheitsstandard man haben will oder muss.
Eine Sessionvariable zusammen mit einer SSL-Verbindung ist sicherlich für viele Anwendungsfälle OK.
Lediglich ein Cookie zur Identifizierung zu verwenden ist erheblich unsicherer. (In älteren Programmierbeispielen wurde häufig so verfahren, dass im Cookie der Username abgelegt war).
Ich verwende z.B. für (allerdings nur internes Netzwerk) einen GUID als Cookie und eine Verknüpfung zur IP des Rechners, an dem sich der User angemeldet hat und speichere diese zur Identifizierung in einer Datenbank.
Eine Session kann ich nicht verwenden, da die Zugriffe oft zu lange auseinander liegen und die Session somit ablaufen würde. Da ist sicherlich noch kein Verfahren für Onlinebanking, aber für's Intranet reicht es eben aus.
Ein anderer Ansatz wäre, die Sicherheit schon auf der Ebene des Zugriffs zu implementieren (also keine anonymen Zugriffe zulassen).
Dann kümmert sich der Server um die Authentifizierung. Allerdings muss die Anwendung dennoch selbst die Autorisierung für einzelne Zugriffe (wahrscheinlich soll nicht jeder alles dürfen / Nutzer-Rollenprinzip) sicher stellen.
Vielleicht hilft Dir das ja ein wenig bei Deinen Überlegungen weiter.
Hallo.
Ich habe es bei einem Intranet-System genau so gemacht wie Du es beschreibst. Das PW steht mit MD5 behandelt in der DB. Beim Login abgeglichen und ein Cookie gesetzt. Bedenke aber, dass Du evtl. Schwierigkeiten mit der Gültigkeit der Session auf dem Server kriegen kannst. Wenn Du den Apache dann nicht selbst betreibst, musst Du bei Deinem Provider betteln gehen...
Grüße,
Mathias
Ich habe es bei einem Intranet-System genau so gemacht wie Du es beschreibst. Das PW steht mit MD5 behandelt in der DB. Beim Login abgeglichen und ein Cookie gesetzt. Bedenke aber, dass Du evtl. Schwierigkeiten mit der Gültigkeit der Session auf dem Server kriegen kannst. Wenn Du den Apache dann nicht selbst betreibst, musst Du bei Deinem Provider betteln gehen...
Grüße,
Mathias
Selbstverständlich muss man nicht bei jeder Seite das Password eingeben.
Hier das Log In Formular:
if ($_REQUEST['action'] == "LogIn")
{
$_SESSION['uname'] = $_REQUEST['username'];
$_SESSION['pword'] = md5($_REQUEST['pword'];
}
$UserIsLogedIn = mysql_query("SELECT * FROM DB WHERE username='".$_SESSION['uname']."' and password='".$_SESSION['pword']."');
Hier das Log In Formular:
<form action="./index.php?action=LogIn" method="post">
<input type="text" name="username">
<input type="password" name="pword">
<input type="submit">
</form>
Sollte man jedes mal, wenn eine Seite geladen wird die Anmeldedaten aus der Datenbank abfragen, oder ist es sicher genug, wenn man das in denn Session-Daten speichert?
PHP's eigener Session-Mechanismus ist "sicher".
Bevor man Anfängt selbst mit Cookies rumzufummeln sollte man sich in das Thema genau einlesen.
Ich wüsste auch nicht wie du bei jedem Aufruf der Seite die Anmeldedaten erneut abfragen willst, denn du löschst das Passwort wie jeder gute Programmierer natürlich sofort nach dem Login aus dem RAM, richtig?
Du könntest also höchstens jedes Mal die Meta-Daten abfragen und das ist einfach eine Design-Entscheidung.
Lediglich ein Cookie zur Identifizierung zu verwenden ist erheblich unsicherer
Richtig, aber Sessions ohne SSL sind heute Standardpraxis - diese Unsicherheit nimmt halt jeder für die alltäglichen Dinge in Kauf.
Wichtige Dinge wie Login, Kontodaten etc. kann man ja über SSL leiten.
Das PW steht mit MD5 behandelt in der DB
MD5 alleine darf nicht mehr verwendet werden, weil das erraten des Ausgangspasswort zu leicht ist. Korrekt wäre z.B.
md5(salt + username + password)
if ($_REQUEST['action'] == "LogIn")
{
$_SESSION['uname'] = $_REQUEST['username'];
$_SESSION['pword'] = md5($_REQUEST['pword'];
}
$UserIsLogedIn = mysql_query("SELECT * FROM DB WHERE username='".$_SESSION['uname']."' and password='".$_SESSION['pword']."');
Diser Code darf niemals und unter keinen Umständen verwendet werden.
Da stecken so viele Sicherheitslücken drin, dass es nur konsequent wäre den Autor mit dem Kopf zuerst einmal durch den Kies zu ziehen.
Zitat von @dog:
Diser Code darf niemals und unter keinen Umständen verwendet werden.
Da stecken so viele Sicherheitslücken drin, dass es nur konsequent wäre den Autor mit dem Kopf zuerst einmal durch den
Kies zu ziehen.
Diser Code darf niemals und unter keinen Umständen verwendet werden.
Da stecken so viele Sicherheitslücken drin, dass es nur konsequent wäre den Autor mit dem Kopf zuerst einmal durch den
Kies zu ziehen.
Wieso ist das unsicher? Ich schreibe meine Logins immer so. Ich sehe da nicht keine Lücke. Ich lerne aber gerne hinzu ;)
Du solltest zumindest die Benutzereingaben (Username, PW) überprüfen (SQL-Injection). Das kann übelst schiefgehen und Deine DB ist futsch. Fällt mir so als erstes ein. Ich würde aber auch noch die $_REQUEST['action'] validieren. Jedenfalls kannst Du die Benutzereingaben nicht einfach in die Session schreiben und sie im SQLStatement verwenden.
Achso. Sollte ja nur Beispielhaft sein.
- mysql_real_escape_string() benutzen
- Und zusätzlich noch übeprüfen ob mehr als 20 Logins in den letzten 30 Minuten versucht worden
- md5(salt + username + password)
(wobei: was ist salt?)
Was fehlt denn da noch ums sicher zu machen.
Oder anders, wie überprüft ihr denn Logins?
- mysql_real_escape_string() benutzen
- Und zusätzlich noch übeprüfen ob mehr als 20 Logins in den letzten 30 Minuten versucht worden
- md5(salt + username + password)
(wobei: was ist salt?)
Was fehlt denn da noch ums sicher zu machen.
Oder anders, wie überprüft ihr denn Logins?
Das Salt ist eine für deine Seite eindeutige Zufällige Buchstabenkombination.
Der Sinn ist folgender:
md5(password) => lässt sich mit einer Rainbow-Table für Passwörter erraten (einfach)
md5(user+password) => lässt sich nur für Benutzer+Passwort Rainbow-Tables erraten (wesentlich schwerer)
md5(salt + user + password) => für die Kombination wird es keine Rainbow-Tables geben, ein neu anlegen ist zu aufwendig (sehr sicher)
Das lässt aber außer acht, dass bei md5() bereits mehrere Kollisionen entdeckt wurden.
Abgesehen davon hat ein Passwort nie etwas in der Session zu suchen.
Nach dem Login muss es verworfen werden und fertig!
Und $_REQUEST sollte man nie benutzen.
Logins kommen per POST also wird doch auch nur $_POST akzeptiert.
$_REQUEST würde auch GET annehmen, womit man viele lustige Dinge machen kann...
Der Sinn ist folgender:
md5(password) => lässt sich mit einer Rainbow-Table für Passwörter erraten (einfach)
md5(user+password) => lässt sich nur für Benutzer+Passwort Rainbow-Tables erraten (wesentlich schwerer)
md5(salt + user + password) => für die Kombination wird es keine Rainbow-Tables geben, ein neu anlegen ist zu aufwendig (sehr sicher)
Das lässt aber außer acht, dass bei md5() bereits mehrere Kollisionen entdeckt wurden.
Abgesehen davon hat ein Passwort nie etwas in der Session zu suchen.
Nach dem Login muss es verworfen werden und fertig!
Und $_REQUEST sollte man nie benutzen.
Logins kommen per POST also wird doch auch nur $_POST akzeptiert.
$_REQUEST würde auch GET annehmen, womit man viele lustige Dinge machen kann...