[PHP] Verständnisfrage zu Passwort abfrage

[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

[Waldteufel]

Hi.

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

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.

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

[Delphi-Freak]

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 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!

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*

[Flocke]

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

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.

[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.

@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!! )

LG

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