[PHP] Verständnisfrage zu Passwort abfrage

[Assun]

Moin ;-)

Ich will ein Single-User-Loginsystem in PHP coden.

Doch ist es sicher, einfach eine php file namens "password.php" zu erstellen, in der das Passwort steht und diese zu includen und den wert der Eingabe zu vergleichen ?

ich meine den PHP Code bekommt man ja nie zu gesicht und password.php einfach so aufrufen kann man ja auch nicht.

Oder kann die variable $Passw zum Bleistift einfach so von ner externen Seite aus ausgelesen werden?

Frage : Ist dieser Weg also sicher ?

Bin dankbar für jeden Tipp ;-)

Gruß Assun

[Neuni]

Solange du nicht einfach das pw in ne datei schreibst sondern sowas wie:

Code:

<?php
$pw = 'lala';
?>

machst kann nix passieren.

[Pr0g]

An die Daten sollte keiner rankommen, wenn sie in einer PHP Datei stehen. Du kannst auch noch folgendes machen:

Code:

//password.php
<?php
  if (!defined('IN_LOGIN')) {
    die;
  }
  $pass = 'xyz';
?>

Code:

//login.php
<?php
  define('IN_LOGIN', true);
  include('password.php');
  ...
?>

Sollte aber nicht nötig sein.

Sicherheitslücken können nur durch andere Scripte auf deiner Seite entstehen. Bspw. wenn du eine Dateiauflistung oder so hast, mit der man die Dateien auch ansehen kann. Viele denken dann man könnte nur im aktuellen Verzeichnis surfen, dabei reicht meist ein einfaches ../ aus um ins nächst höhere Verzeichnis zu gelangen.

[Mystic]

Ansonsten kann man dir noch empfehlen nur die Hash des Passworts abzuspeichern und dann beim Login das eingegebene Passwort zu hashen und dann die Hashes zu vergleichen.

http://de2.php.net/sha1
http://de2.php.net/md5
http://de2.php.net/crypt

[bigg]

Ich nutze für solche Geschichten ".Htacess".
Das erspart einem das gewurschelt per SID.

Noch ein Tipp:
Die Datei mit dem Passwort würde ich ".ht_xxxx" nennen.
Ganz einfach weil Apache diese im Normalfall nicht anzeigt.

[Pr0g]

Da würde ich die Datei doch lieber als PHP lassen und außerhalb des Webverzeichnisses auf den Server legen. So kann nur das PHP Script drauf zugreifen, der User über den Browser aber nicht direkt.

[bigg]

Zitat:

Da würde ich die Datei doch lieber als PHP lassen und außerhalb des Webverzeichnisses auf den Server legen. So kann nur das PHP Script drauf zugreifen, der User über den Browser aber nicht direkt.

Sofern die Möglichkeit besteht, klar.

[Flocke]

Die sauberste Lösung ist es, wie Mystic schon geschrieben hat, mit dem Hash des Passworts zu arbeiten.

Noch "sauberer" ist die Variante, die die Ermittlung des Hashes schon beim Client macht, da dann das Kennwort *NIE* im Klartext über's Internet geht. Eine Artikel darüber gibt's bei SelfHTML hier.

[Assun]

aber ist es nicht möglich einfach von einem anderen server aus mit einer php file die genauso aussieht :

Zitat:

//login.php
<?php
define('IN_LOGIN', true);
include('password.php');
...
?>

auf meinen Server meine passw variable zuzugreifen ?

[Flocke]

Wenn die PHP-Seite über http abgerufen wird (und nur das können andere Server), dann bekommt man ja nicht den Quelltext sondern das Ergebnis zu sehen. Wenn die Passwortdatei also kein "echo $password;" macht, dann passiert garnichts. Rufe deine Passwortdatei doch mal direkt im Browser auf (natürlich nicht von der Festplatte sondern über den Server), dann siehst du was passiert.

[jfheins]

Nein, denn wen du auf deinem Server diese Datei includest, dann includest du den Source, wenn du Sie von woanders includest, includest du die Ausgabe ;)

Datei:

Code:

<php
$pass="passwort";

echo '<php
$pass="falsch";
?' + '>';

?>

Wenn du Sie includest, ist $pass gleich passwort, wenn Sie von einem anderen Server includest wird, ist $pass gleich falsch ;)

[Assun]

ok ! in dem Fall nehme ich

Zitat:

//password.php
<?php
if (!defined('IN_LOGIN')) {
die;
}
$pass = 'xyz';
?>

und

Zitat:

//login.php
<?php
define('IN_LOGIN', true);
include('password.php');
...
?>

;-)

Vielen Dank für eure Hilfe :thumb:

[Waldteufel]

Hi.

Zitat:

Zitat von Assun

aber ist es nicht möglich einfach von einem anderen server aus mit einer php file die genauso aussieht :

Zitat:

//login.php
<?php
define('IN_LOGIN', true);
include('password.php');
...
?>

auf meinen Server meine passw variable zuzugreifen ?

Nein! Der Vorgang bei include() sieht ungefähr so aus:
Pseudo-Code:

Code:

include ($file) {
  $f = open($file); // Öffnen
  parse($f); // Einlesen und verarbeiten
  close($f); // Schließen
};

Wenn also nun dein Skript include('password.php') aufruft, öffnet der Server die Datei und parst sie. Eventuell vorhandene Variablen sind nach include('password.php') verfügbar.

Bei Dateien auf einem anderen Server hingegen wird etwa folgendes ausgeführt:
Pseudo-Code:

Code:

include ($file) {
  $f = HTTP_Request($file);
  parse($f);
  close($f);
};

Wenn dein Skript aber include('http://sonstwo.issaauejal.xyz/topf-secret.php') aufruft, schickt der Server einen HTTP-Request an http://sonstwo.issaauejal.xyz mit der Bitte, doch die Datei topf-secret.php zurückzuschicken. Der Server http://sonstwo.issaauejal.xyz bemerkt nun, dass topf-secret.php PHP-Code enthält und führt diesen aus. Das Ergebnis bekommt dann dein Skript zu Gesicht.

PS: So gesehen kann man auf Server B dynamisch ein PHP-Skript generieren, dass dann von Server A eingebunden und ausgeführt werden kann...
Mir schwirrt der Kopf :drunken:

PPS: Die Server und Skriptnamen habe ich mir ausgedacht. Jedwede Ähnlichkeiten mit lebenden oder verstorbenen Servern und Skripten sind rein zufällig und nicht beabsichtigt. :mrgreen:

PPPS und Edit: Jetzt hab ich mir so viel Mühe gegeben und die Frage ist bereits beantwortet :cry:

[Delphi-Freak]

Zitat:

Zitat von Flocke

Noch "sauberer" ist die Variante, die die Ermittlung des Hashes schon beim Client macht, da dann das Kennwort *NIE* im Klartext über's Internet geht. Eine Artikel darüber gibt's bei SelfHTML hier.

Irgendwie ist das aber sinnwidrig.

1.Fall: Nehmen wir einmal an, die Hasherzeugung geschieht am Server. Jetzt liest irgendeiner die Datei am Server aus, wie auch immer, kann diesen Hash aber nicht an das PHP-Script schicken, da dieses den Hash nocheinmal verHASHen würde und dann wieder ein falscher herauskommen würde -> keine Authentifizierung möglich.

2.Fall: Nehmen wir nun an, der Hash wird am Client erzeugt und als Hash an den Server geschickt. Nun liest irgendjemand den Hash am Server aus und schickt diesen direkt an den Server (er muss ja nicht das Login-Formular verwenden) -> Authentifizierung möglich.

Dadurch würde das verHASHen am Client überhauptnichts bewirken (außer dass ein Spion, der den Datenverkehr mitliest, das Passwort nicht im Klartext weiß, was er sont wo anders verwenden könnte, wo der Benutzer auch das gleiche Passwort verwendet), für die Authentifizierung selbst am Server braucht er ja den Hash und nicht das tatsächliche Passwort.

Ich hoffe, ich habe mich verständlich ausgedrückt, sonst bitte rückfragen, da es ja durchaus zum Thema passt. Meines Erachtens wäre die Verschlüsselung via SSL die sicherste Variante.

LG, Gerhard

[jfheins]

Zitat:

Zitat von Delphi-Freak

Meines Erachtens wäre die Verschlüsselung via SSL die sicherste Variante.LG, Gerhard

Das schon, aber es ist sicherer, den Hash beim User zu erzeugen, als auf dem Server.

Nehmen wir uns einen Haxx0r, der den Datenverkehr eines normalen Loginvorgangs mitliest:

Serverhash:

Das Passwort wird mitgeschickt - der Haxx0r weiß jetzt das Passwort (dass du vielleicht auch für andere Sachen genutzt hast).

Clienthash:

Es wird das Passwort gehasht und an den Server geschickt - der Haxx0r weiß nicht das Passwort.

Haxx0r, der die Datenbank knackt, in der die ganzen Hashes gespeichert sind:

Serverhash: Der Haxx0r kann sich nicht mit dem DB-Hash anmelden, er tauscht den Hash gegen einen eigenen und meldet sich mit dem neuen Passwoert an.

Clienthash: Der Haxx0r kann sich damit anmelden.

Der Clienthash ist also sicherer, weil der Haxx0r nie das Klartextpasswort zu Gesicht bekommt ;)

[Delphi-Freak]

Das wird eine interessante Diskussion! :wink:

Du hast angenommen, dass wenn jemand das PW aus der DB auslesen kann, es dann auch verändern kann; sowie, dass der Benutzer das PW öfters verwendet.

Gehen wir von den entgegengesetzten Bedingungen aus (für die DB kann man ja auch Schreibe- und Leserechte getrennt setzen (wenn mich nicht alles täuscht) oder das PW könnte auch in einer Datei gespeichert werden, wie oben besprochen, was das Gegenteil der ersten Bedingung rechtfertigen würde; über die 2. Bedingung kann man nichts aussagen, wobei ich dir recht geben muss, dass viele Leute die PWs öfters verwenden dürften), so ist es besser, den Hash erst am Server zu bilden.

*schon gespannt auf deine Antwort bin* :mrgreen:

[Flocke]

Zitat:

Zitat von Delphi-Freak

Irgendwie ist das aber sinnwidrig.

Zur Verdeutlichung ein Beispiel wie ich es verwende:

1. Auf dem Server sind in der Datenbank *NUR* die MD5-Hashes der Passwörter abgespeichert.

2. Beim Aufruf der Loginseite generiert der Server einen neuen Zufallsschlüssel und merkt ihn sich zusammen mit REMOTE_ADDR und der Uhrzeit in einer speziellen Tabelle. Diesen Zufallsschlüssel nenne ich jetzt mal "Challenge". Er wird auch als verstecktes Feld in das Formular eingebaut.

Code:

<script type="text/javascript" language="JavaScript" src="md5.js"></script>
<script type="text/javascript" language="JavaScript">
<!--
  var submitted = false;

  function doChallengeResponse() {
    password = document.loginform.login_p_field.value;
    document.loginform.login_p_field.value = "";

    if (submitted) {
      alert("Die Daten wurden bereits abgeschickt!");
      return false;
    } else if (password) {
      password = MD5(password);
      str = "(" + document.loginform.login_username.value + "|" + password + "|" + document.loginform.login_challenge.value + ")";
      document.loginform.login_response.value = MD5(str);
      submitted = true;
      return true;
    } else {
      alert("Sie müssen zur Anmeldung ihr Kennwort eingeben");
      return false;
    }
  }
//-->
</script>

<form action="login.php" method="post" name="loginform" autocomplete="off" onSubmit="doChallengeResponse();">
<input type="hidden" name="login_challenge" value="<?php echo $challenge; ?>">
<input type="hidden" name="login_response"  value="--------------------------------">


Benutzer: <input type="text" name="login_username" value="" size="30" maxlength="20">


Kennwort: <input type="password" name="login_p_field" value="" size="30" maxlength="20">


<input type="submit" name="login_submit" value=" Anmelden "></p>
</form>

3. Wenn der Client jetzt seinen Namen und sein Kennwort in das Formular einträgt und auf "Anmelden" klickt, dann passiert das folgende:

a) Das Passwort-Feld wird ausgelesen, geleert und der String wird mit MD5 gehasht.
b) Aus Benutzername, MD5 aus (a) und Challenge vom Server wird ein neuer MD5-Hash gebaut.
c) Der Benutzername, die Challenge und der MD5-Wert aus (b) werden an den Server geschickt.

4. Der Server liest die angegebene Challenge (falls vorhanden) aus der Datenbank und löscht den Satz. Danach kann er überprüfen, ob der Client mit REMOTE_ADDR die Challenge überhaupt benutzen darf und ob seine Kombination aus Benutzername + MD5(Kennwort) + Challenge denselben Wert ergeben.

Ist nicht auf meinem Mist gewachsen. Ist ein abgewandeltes System von dem, das Typo3 für das Backend benutzt.

Zuguterletzt natürlich noch: Wenn es wirklich sicher sein soll, dann sollte man natürlich unbedingt eine verschlüsselte Verbindung benutzen.

[Nachtrag]

Probleme kann es hier dadurch geben, dass bei Sonderzeichen (ä, ö, ü, also nicht-ASCII) der Browser des Client ggf. einen anderen Zeichenwert benutzt als der Server, also dass der MD5-Hash von "häh" auf dem Client und auf dem Server unterschiedlich sind. 100% kriegt man das nur, wenn man keine Sonderzeichen im Namen und Kennwort erlaubt.

Um das "etwas" zu umgehen, habe ich die aufgeführte md5.js etwas modifiziert (die allerletzte Routine). Hab' aber auch schon erlebt, dass es bei einem deutschen User trotzdem nicht mit Sonderzeichen ging.

Code:

/* Modified 2003-11-08 by V. Siebert to use charCodeAt to accept international characters */

function MD5(entree) 
{
 var l,s,k,ka,kb,kc,kd;

 init();
 for (k=0;k<entree.length;k++) {
   l=entree.charCodeAt(k);
   update(l);
 }
 finish();
 ka=kb=kc=kd=0;
 for (i=0;i<4;i++) ka+=shl(digestBits[15-i], (i*8));
 for (i=4;i<8;i++) kb+=shl(digestBits[15-i], ((i-4)*8));
 for (i=8;i<12;i++) kc+=shl(digestBits[15-i], ((i-8)*8));
 for (i=12;i<16;i++) kd+=shl(digestBits[15-i], ((i-12)*8));
 s=hexa(kd)+hexa(kc)+hexa(kb)+hexa(ka);
 return s; 
}

[jfheins]

Das ist einfach so :mrgreen:

Nein, ok:

Die sicherheitsrelevanten Daten in einer Datei zu speichern, ist schonmal *äh* suboptimal. Warum alles in der DB speichern, und die Passwörter in einer Datei ? ausserdem müsste man die Datei extra sichern etc. Wir gehen also von einer herkömmlichen Speicherung (uinj verschlüsselter Form) in einer Mysql-DB aus.

Wenn man an die Datenbank (oder auch diese PW-Datei) durch Injections rankommt, hat man meistens auch Schreibrechte - wie willst du sonst einen neuen User anlegen, oder ein PW ändern ?

Dann ist also quasi alles verloren, man könnte auch gleich ein DROP DATABASE `dp` machen ;)

Und wenn man den Datenverkehr mithört, kann man sich sowiso einloggen - wenn der Typ es nicht mitbekommt und sein PW ändert ;)

Ich glaube dieser Beitrag von Hagen unterstützt ebenfalls meine Meinung ("Das Passwort sollte unbedingt auf dem Client Rechner per Script vor dem versenden mit MD5 gehasht werden. ")

Das System von Flocke ist natürlich noch besser, als nur das PW verschlüsselt zu schicken ;)

Zusammenfassend: Das ist einfach so. :mrgreen:

[negaH]

Flockes Methode setzt aber voraus das auf dem Server das Benutzerpasswort lesbar gespeichert wird.
Besser ist es doppelt zu hashen. D.h. auf dem Server steht beim Benutzerpasswort nur ein unveränderlicher und einmal bei der Anmeldung erzeugter Zufallssalt + der MD5 Hash über das Kennwort. Alles andere ist absolut korrekt so wie es Flocke benutzt. Nurdas eben nun dieser "Verify MD5 Abdruck" in dieses Protokoll eingebettet wird, statt dem echten Benutzerkennwort.

Damit verlässt das Passwort niemals den Rechner des Klienten. Wird nämlich der Server hijacked hätten die Angreifer wiederum alle Passwörter lesbar zur Verfügung. Der Server ist also Sicht des Klienten ebenfalls ein Sicheheitsrisiko für dessen Passwort.

Gruß Hagen

[Delphi-Freak]

Also gut, ich gebe mich geschlagen. :mrgreen:

@Flocke:
Ja, das gefällt mir schon besser!

Da hätte ich eine andere (ähnliche) Idee:
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.
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.

Übrigens in diesem Fall wird das PW in der DB auch nur geHASHt gespeichert, es hat zwar nur den Sinn, dass man das PW im Klartext für andere Accounts nicht verwenden kann, aber immerhin)

(Sowas gefällt mir!! :stupid: :stupid: )

LG

PS: Endlich komme ich zum Abschicken, dauern neue Beiträge

[Flocke]

Zitat:

Zitat von negaH

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

Ähhh ... :gruebel: 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:

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 :stupid: :mrgreen:

Zitat:

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:

Zitat von Flocke

Zitat:

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 :stupid: :mrgreen:

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:

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 :mrgreen:

[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