12
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 143439
Url: https://administrator.de/contentid/143439
Printed on: April 25, 2024 at 05:04 o'clock
12 Comments
Latest comment
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 vor es ohne SSL laufen zu lassen(vor allem aus Kostengründen).
Es muss ja nicht so sicher sein, wie beim Onlinebanking. Allerdings wollte ich wegen der Zeit wissen, ob man nicht einfach den Usernamen und den Passwort-Hash in einer Session-Variable speichern kann, der dann sozusagen als "Ausweis" gilt.
Dann müsste man nicht jedes mal beim Seitenaufruf in der Datenbank nachschlagen, ob der Benutzer mit dem Passwort existiert.
Eike
ich habe vor es ohne SSL laufen zu lassen(vor allem aus Kostengründen).
Es muss ja nicht so sicher sein, wie beim Onlinebanking. Allerdings wollte ich wegen der Zeit wissen, ob man nicht einfach den Usernamen und den Passwort-Hash in einer Session-Variable speichern kann, der dann sozusagen als "Ausweis" gilt.
Dann müsste man nicht jedes mal beim Seitenaufruf in der Datenbank nachschlagen, ob der Benutzer mit dem Passwort existiert.
Eike
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
Das ist nicht das Problem, ich habe einen eigenen Server. Und wenn das mit der Sicherheit klar geht, dann mach ich dass so.
Vielen Dank für die Hilfe!
Eike
Vielen Dank für die Hilfe!
Eike
Hallo,
wo liegt denn das Problem beim permanenten Abfragen? Die Datenverbindung wird ja vermutlich eh immer aufgebaut werden, und auf eine Query mehr kommst nicht an. Ich würde es nur mit permanenter Abfrage machen.
mfG
wo liegt denn das Problem beim permanenten Abfragen? Die Datenverbindung wird ja vermutlich eh immer aufgebaut werden, und auf eine Query mehr kommst nicht an. Ich würde es nur mit permanenter Abfrage machen.
mfG
Wozu soll das gut sein? Das PW müsste in beiden Fällen auf dem Client gespeichert werden, schließlich soll der user doch sein PW nicht ständig eingeben müssen...
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...
