[PHP] Verständnisfrage zu Passwort abfrage

[Flocke]

Zitat von negaH:

Flockes Methode setzt aber voraus das auf dem Server das Benutzerpasswort lesbar gespeichert wird.

Ähhh ... nein.

Auf dem Server speichere ich nur den MD5-Hash des Passworts, allerdings ohne Zufalls-"Salt".

Dabei geht es mir nur darum, dass nicht jemand, der zufällig über die (meine) Schulter in die Datenbank sehen kann, weiß, dass "klaus" das Kennwort "erwin" hat. Er sieht halt nur, dass der MD5-Hash des Passworts "fa126e0adce0fc4de59812b270dff77f" ist - selbst wenn er sich das merken kann, kann er ohne spezielle Skript-Kenntnisse damit nichts anfangen.

Ich schicke nur das "Salt" zum Client, da er das für die Anmeldung braucht und bekomme
- Benutzername
- Salt
- MD5('(' + Benutzername + '|' + MD5(Kennwort) + '|' + Salt + ')')
wieder zurück (Salt wäre nicht unbedingt nötig).

Damit kann ich auf dem Server prüfen, ob das Kennwort korrekt war (bzw. ob der Hash übereinstimmte).

Außerdem kann ich einschränken, dass ein "Salt" nur ein einziges mal und nur von einer IP-Adresse benutzt werden darf.

[Flocke]

Zitat von Delphi-Freak:

Wenn man Challenge und Benutzername mitschickt, dann kann man ja durch ausprobieren auf den Passwort-Hash zurückschließen, von diesem dann auf das Passwort selbst.

Da hätte ich gerne eine "performante" Lösung von dir gesehen

Zitat von Delphi-Freak:

Meine Idee also: Man überschickt nur Hash(Challenge+'*'+Hash(PW)) und den Benutzernamen; am Server wird nach einem Challenge, zu IP & Benutzername passend, gesucht, der Hash aus diesem plus PW-Hash aus DB erzeugt und dann mit dem Hereinkommenden verglichen.
Ein Mitlesender hat also Benutzername und einen Hash aus Challenge und PW, Challenge ist längst nirgends mehr gespeichert und so kann er auch nicht auf das PW zurückschließen.

Ist ja so ähnlich, wie ich geschrieben habe - die Challenge könnte man auch weglassen und nicht wieder mit zurückschicken. Wer aber beide "Wege" abhört, der hat die Challenge ja schon.


Womit ich noch nicht ganz glücklich bin ist, wie es danach weitergeht - also die laufende Authentifizierung, solange der User angemeldet bleibt. Momentan mache ich das über jeweils neu generierte Challenges und Hashes, die als Cookies hinterlegt werden und auch nur eine gewisse Gültigkeit haben. Die könnte man aber abfangen und ein Replay versuchen.

Weiß einer von euch einzuschätzen wie sicher PHP Sessions sind?

[negaH]

nicht ganz

1.) Client sendet LoginName := Hash(NameSalt || eindeutigen Namen) an Server
2.) Server sucht mit spezielle Methode in DB nach LoginName == Hash(NameSalt || BenutzerName aus DB)
3.) Server sendet PasswortSalt aus Datensatz + ChallengeSalt aus dem Datensatz an Client
3.) Client sendet LoginVerifierClient := Hash(ChallengeSalt || Hash(PasswortSalt || Passwort))) an Server
4.) Server erzeugt LoginVerifierServer := Hash(ChallengeSalt || HashPasswortAusDB)
5.) Server acceptiert wenn LoginVerifierClient == LoginVerifierServer

So, nun existiert in der Serverdatenbank nur zwei Felder -> NameSalt, NameHash, PassworrtHash, PasswordSalt
Wird der Server hijacked so muß der Angreifer erstmal in der Lage sein
1.) einen eindeutigen Namen zu einem PasswortHash zuzuordnen, unmöglich bei ausreichend sicherem Hash.
2.) per Brute Force das Passwort zum Password Hash knacken, unmöglich da es unendlich viele Passwörter gibt die identisch zum gespeicherten Hash sein müssen.

Allerdings gibt es immer noch ein Problem warum diese Protokoll nicht wasserdicht sein kann.
Die Man in the Middle Attack. Dabei gehen wir davon aus das eine dritte Partei, nennen wir sie mal Nsa, die komplette Kommunikation belauschen und verändern kann.
Nsa gibt sich dem Client gegenüber als Server aus, und dem Server gibt sich Nsa als Client aus. Jeder Protokollschritt oben wird nun durch Nsa in beiden Richtungen ausgeführt. Die weitere Kommunikation zwischen Client<->Sever kann nun Nsa durch Client<->Nsa<->Server mitlauschen und sogar manipulieren.

Ein dagegen sicheres Protokoll ist das SRP, Secure Remote Protocoll.

Gruß Hagen

[Delphi-Freak]

@Flocke:

Ich würde den Salt auf keinen Fall wieder mitschicken, da der Server ihn ja gar nicht mehr verwendet. Dadurch ist es eigentlich nur ein weiteres Sicherheitsrisiko, weil die Wahrscheinlichkeit kleiner ist, dass dieser jemand auch das Login-Formular mitgelauscht hat. Deshalb würde ich es nicht mitschicken.

Zitat von Flocke:

Zitat von Delphi-Freak:

Wenn man Challenge und Benutzername mitschickt, dann kann man ja durch ausprobieren auf den Passwort-Hash zurückschließen, von diesem dann auf das Passwort selbst.

Da hätte ich gerne eine "performante" Lösung von dir gesehen

Sicher, es geht nicht sehr schnell, aber immerhin. Wenn damit wichtige Daten (wie z.B. Bankverbindungsdaten oder so) geschützt sind (was zwar bei diesem Prinzip überhaupt nicht zu empfehlen ist), so zahlt es sich durchaus aus, einen Rechner ein paar Tage rattern zu lassen, bis er das PW ausfündig gemacht hat. Hacker treiben manchmal einen ziemlichen Aufwand!


@negaH:

Das wird dann aber etwas kompliziert. Ich glaube, da ist es einfacher auf SSL oder so etwas zurückzugreifen.


LG, Gerhard

[jfheins]

Zitat von Delphi-Freak:

Wenn man Challenge und Benutzername mitschickt, dann kann man ja durch ausprobieren auf den Passwort-Hash zurückschließen
[...]
einen Rechner ein paar Tage rattern zu lassen, bis er das PW ausfündig gemacht hat. Hacker treiben manchmal einen ziemlichen Aufwand!

Klar kann man einen Rechner ein paar Tage Jahrzehnte rechnen lassen, wenn ich mich mal eben ´kurz beim Onlinebanking einloggen möchte

[negaH]

@Flocke: sorry, dann habe ich wohl was falsch verstanden.

Zitat:

Ich würde den Salt auf keinen Fall wieder mitschicken, da der Server ihn ja gar nicht mehr verwendet. Dadurch ist es eigentlich nur ein weiteres Sicherheitsrisiko, weil die Wahrscheinlichkeit kleiner ist, dass dieser jemand auch das Login-Formular mitgelauscht hat. Deshalb würde ich es nicht mitschicken.

Ist im Grunde egal ob man die Salts versendet oder nicht, dadurch wrid das Protokoll nicht unsicherer, aber auf Server Seite benötigt man zu dieem Zeitpunkt noch keine Session Werte.

Der Salt kann egal in welcher Richtung abgelauscht werden und dann entstprechend dem Protokoll mißbräuchlich verwendet werden. Zudem hat er eine ganz andere Aufgabe in dem Protokoll, nämlich den Schutz des Paswortes vor Brute Force Angriffen auf den Passwort Hash. Der Salt ist also kryptographisch gesehen eh ein öffentlicher Wert, also könnte man diesen erst zum Client und Client dann samt anderen Daten wieder zurück zum Server schicken, das spielt keine Rolle. Der Server muß sich diesen Wert dann nicht unbedingt merken, falls in dem Protokoll noch andere Merkmale benutzt werden die sicherstellen das der Protokoll Ablauf in der korrekten Reihenfolge durchgeführt wurde.

Das heist: es handelt sich immer um ein Mehrstufen-Protokoll. Bei solchen Protokollen ist die Reihenfolge der Abarbeitung der einzelnen Schritte ein wichtiges Sicherheitsmerkmal. Auch die Zusammengehörigkeit der einzlenen Schritte aufeinander ist ein Sicherheitsmerkmal. Es darf also nicht möglich sein das man einzelne Schritte überspringt oder deren Reihenfolge ändert oder an beliebigen Schritten neu einsteigen kann.


Gruß HAgen