Sicherheitslücke .htpasswd???

[timm]

Hallo zusammen,
ich habe folgendes bemerkt und wäre für jede erklärung dankbar:

Als ich mich mal wieder in einer Protected Area einloggen wollte und mein Passwort gerade nicht da hatte hab ich abgebrochen und dann zufällig einmal den Browserbutton "Zurück" und dann nochmal "Vorwärts" betätigt.
Und...
Schon war ich drin.

Da ich auch selbst bestimmte Bereiche mit htpasswd sichere hab ichs da auch erstmal probiert und überall hats geklappt.
Nur bei den Servern, bei denen nicht Standardmäßig "Authorisation Required" stand, wurde ich erneut nach einem Passwort gefragt.

Gibs erklärungen???

Was kann ich machen um eine erneute Passwort- Abfrage zu erzwingen???

Dank schon mal...

Timm

[Sven Rautenberg]

Moin!

ich habe folgendes bemerkt und wäre für jede erklärung dankbar:

Als ich mich mal wieder in einer Protected Area einloggen wollte und mein Passwort gerade nicht da hatte hab ich abgebrochen und dann zufällig einmal den Browserbutton "Zurück" und dann nochmal "Vorwärts" betätigt.
Und...
Schon war ich drin.

Es ist nicht auszuschließen, dass da jemand schlampig gearbeitet und sich eine Sicherheitslücke eingebaut hat. Man kann HTTP-Authorisation nämlich mit mehr als nur .htaccess herstellen.

Was kann ich machen um eine erneute Passwort- Abfrage zu erzwingen???

.htaccess ist in dieser Hinsicht eigentlich sicher, jedenfalls ist mir noch nichts bekannt worden, dass es in irgendeiner Weise versagt.

Solange wir also nicht wissen, wie der Zugangsschutz auf der fraglichen Seite realisiert wurde, kann niemand sagen, warum dort etwas falsch läuft.

- Sven Rautenberg

[Sönke Tesch]

Als ich mich mal wieder in einer Protected Area einloggen wollte und mein Passwort gerade nicht da hatte hab ich abgebrochen und dann zufällig einmal den Browserbutton "Zurück" und dann nochmal "Vorwärts" betätigt.
Und...
Schon war ich drin.

Lustig, funktioniert an diesem Ende der Leitung aber nirgends.

Da ich auch selbst bestimmte Bereiche mit htpasswd sichere hab ichs da auch erstmal probiert und überall hats geklappt.

Wie sieht Deine .htaccess aus?

Nur bei den Servern, bei denen nicht Standardmäßig "Authorisation Required" stand, wurde ich erneut nach einem Passwort gefragt.

Was bitte meinst Du mit "nicht standardmäßig"? Entweder man muß sich irgendwo einloggen oder man muß es nicht.

Gruß,
  soenk.e

[timm]

Was bitte meinst Du mit "nicht standardmäßig"? Entweder man muß sich irgendwo einloggen oder man muß es nicht.

wenn man auf abbrechen klickt gibts entweder ne standardanzeige vom jeweiligen webserver oder eine selbstdefinierte failed seite
timm

[Matze]

Historyback Vrlauf und die lokal gespeicherten Seiten machen so manchmal unverständliches und scheinbar unmögliches möglich.
Wenn Du schon einmal af einer Seite eingeloggt warst und danach über history bzw. im Verlauf auf besuchte Seiten gehst...
Kommt es durchaus vor, dass Du wieder auf den Server kommst.
Das hat jedoch nicht´s mit einer sichrheitslücke zu tun sondern liegt in erster Linie daran, ob Du eine Session nach einer gewissen Zeit wieder löscht oder nicht.

Zu deutsch:
Wenn Du Deinem Server nicht sagst, dass ein Login nach 60 minuten inaktivität nicht mehr gültig ist.... dann kannst Du getrost jahre spähter dich wieder einloggen indem Du ein im Verlauf bestehende Seite mit existierendem Login wieder einlogst.
Verstanden?

Gruss Matze

[Sven Rautenberg]

Moin!

Zu deutsch:
Wenn Du Deinem Server nicht sagst, dass ein Login nach 60 minuten inaktivität nicht mehr gültig ist.... dann kannst Du getrost jahre spähter dich wieder einloggen indem Du ein im Verlauf bestehende Seite mit existierendem Login wieder einlogst.

HTTP-Authentifizierung kennt keine Gültigkeitszeit.

- Sven Rautenberg

[Henner]

HTTP-Authentifizierung kennt keine Gültigkeitszeit.

HTTP-Basic-Authentisierung kennt keine Gültigkeitszeit.

H.

[Christian Seiler]

Hallo Henner,

HTTP-Basic-Authentisierung kennt keine Gültigkeitszeit.

Nenne mir bitte eine andere HTTP-Authentifizierungsart, die eine Gültigkeitszeit besitzt und die offizieller Standard ist.

Christian

[Henner]

Nenne mir bitte eine andere HTTP-Authentifizierungsart, die eine Gültigkeitszeit besitzt und die offizieller Standard ist.

HTTP Digest Authentication.
(solange du RFCs als offizielle Standards betrachtest)

H.

[Christian Seiler]

Hallo Henner,

HTTP Digest Authentication.

Es ist zwar möglich (und es wird auch im RFC 2617 als Beispiel beschrieben) über Digest Authentication das zu realisieren, jedoch ist es nicht direkt Teil des Standards.

(solange du RFCs als offizielle Standards betrachtest)

Tue ich.

Christian

[Henner]

HTTP Digest Authentication.

Es ist zwar möglich (und es wird auch im RFC 2617 als Beispiel beschrieben) über Digest Authentication das zu realisieren, jedoch ist es nicht direkt Teil des Standards.

Hmm, sondern was? Indirekt?
Wenn ja, was bedeutet das?

H.

[Christian Seiler]

Hallo Henner,

Hmm, sondern was?

Ein Adjektiv fällt mir dazu nicht ein.

Ich ziehe das Pferd mal von hinten auf: Wenn es direkt im Standard verankert wäre, dann gäbe es im Standard eine Vorschrift, wie so ein "Zeitlimit" auszusehen hätte. (Zum Beispiel ) Gibt es aber nicht. Es gibt wie gesagt nur ein Beispiel, wie es aussehen _könnte_:

| A nonce might, for example, be constructed as the base 64 encoding of
| time-stamp H(time-stamp ":" ETag ":" private-key)
(RFC 2617)

Wichtig sind hier die Wörter "might" und "example".

Anderes Beispiel: HTTP kennt ja schließlich auch keine Foren, (wie dieses hier) sie sind nicht Teil des Standards. Dennoch ist es möglich, mit HTTP und HTML Foren zu realisieren.

Christian

[Henner]

Ich ziehe das Pferd mal von hinten auf: Wenn es direkt im Standard verankert wäre, dann gäbe es im Standard eine Vorschrift, wie so ein "Zeitlimit" auszusehen hätte. (Zum Beispiel ) Gibt es aber nicht. Es gibt wie gesagt nur ein Beispiel, wie es aussehen _könnte_:

Ich schlage vor, du liest dir auch den Rest des RFCs durch. Zum Beispiel (aber nicht nur) den Abschnitt über MD5-sess. Für mich ist hier EOD, das wird mir langsam zu einseitig.

H.

[Christian Seiler]

Hallo Henner,

Ich schlage vor, du liest dir auch den Rest des RFCs durch.

Bitte unterstelle mir nicht, dass ich ihn nicht gelesen hätte.

Zum Beispiel (aber nicht nur) den Abschnitt über MD5-sess.

Ich sehe keine Relevanz von MD5-sess bei diesem Thema. MD5-sess verwendet lediglich weniger Informationen für den MD5-Hash, damit der Server das Klartextpasswort nicht kennen muss, um den Benutzer zu authentifizieren.

Für mich ist hier EOD,

Tolle Einstellung, andere Leute als inkompetent darzustellen, (siehe oben) weil Du keine Argumente mehr hast.

Nenne die entsprechende Stelle aus RFC 2617, die meine vorherigen Aussagen widerlegt oder höre auf, Dinge zu behaupten, die nicht stimmen. Wenn Du zu keinem von beidem bereit bist, dann kannst Du auch eine weitere Antwort unterlassen.

Christian

[Henner]

Ich schlage vor, du liest dir auch den Rest des RFCs durch.
Bitte unterstelle mir nicht, dass ich ihn nicht gelesen hätte.

Natürlich nicht.

Zum Beispiel (aber nicht nur) den Abschnitt über MD5-sess.

Ich sehe keine Relevanz von MD5-sess bei diesem Thema.

Das ist ganz allein dein Problem.

MD5-sess verwendet lediglich weniger Informationen für den MD5-Hash, damit der Server das Klartextpasswort nicht kennen muss, um den Benutzer zu authentifizieren.

Nein. Da du den RFC gelesen hast, solltest du es eigentlich besser wissen.

Für mich ist hier EOD,

Tolle Einstellung, andere Leute als inkompetent darzustellen, (siehe oben) weil Du keine Argumente mehr hast.

Was du in meine Handlungen hineininterpretierst, ist mir eigentlich egal.

Ich zitiere dich mal:

Nenne mir bitte eine andere HTTP-Authentifizierungsart, die eine Gültigkeitszeit besitzt und die offizieller Standard ist.

Nun, das hab ich ich getan. Daher EOD.

oder höre auf, Dinge zu behaupten, die nicht stimmen.

Spaßvogel ;-)

H.

[Sven Rautenberg]

Moin!

Nenne mir bitte eine andere HTTP-Authentifizierungsart, die eine Gültigkeitszeit besitzt und die offizieller Standard ist.

Nun, das hab ich ich getan. Daher EOD.

Stimmt aber nicht so ganz.

Ja, Digest-Auth besitzt die Mechanismen, dass der Server einen zeitlich befristeten Challenge generiert.

Sollte der Client also irgendwann die Credentials mit einem zu alten Challenge (im RFC nonce genannt) kombinieren, kann der Server mit einem neuen 401 Unauthorized reagieren. Hierbei sollte er allerdings das Stale-Flag auf true setzen, damit der Client erkennen kann, dass nicht die Credentials falsch sind, sondern nur der nonce-Wert veraltet ist, und ein neuer nonce im 401 mitgeliefert wird. Es wird erwartet, dass der Client dann ohne Nachfrage beim User die ihm bekannten Credentials erneut mit dem neuen nonce kombiniert und abschickt.

Mit anderen Worten: Das Verhalten ist absolut identisch zu dem der Basic-Authentifizierung.

Eine wirkliche zeitliche Begrenzung der Gültigkeit der Anmeldung muß weiterhin mit einer serverseitigen Auswertelogik erfolgen: Man speichert den Zeitpunkt des letzten Requests des Users und verweigert einfach einen anmeldungslose Request, wenn seit dem letzten Request zuviel Zeit vergangen ist. Bei Basic-Auth sendet man dann einfach einen 401 zurück, bei Digest-Auth darf man beim 401 aber keinesfalls Stale = True zurücksenden, sondern muß ebenfalls im Prinzip ganz von vorn beginnen.

Denn der Client speichert die einmal eingegebenen Credentials und wird sie, solange er nicht darüber informiert wird, dass diese falsch sind (eben per 401) bei weiteren Requests immer wieder verwenden.

oder höre auf, Dinge zu behaupten, die nicht stimmen.

Spaßvogel ;-)

Stimmt aber.

- Sven Rautenberg

[Thoralf]

Hallo auch,

rein zufällig hab ich kürzlich erst etwas über HTTP-Authentifizierung mit PHP gelesen und dabei folgendes gesehen:

<!-- Beginn Auszug aus dem PHP-Manual -->
<?php
  function authenticate() {
   Header( "WWW-Authenticate: Basic realm="Test Authentication System"");
   Header( "HTTP/1.0 401 Unauthorized");
   echo "You must enter a valid login ID and password to access this resource\n";
   exit;
  }

if(!isset($PHP_AUTH_USER) || ($SeenBefore == 1 && !strcmp($OldAuth, $PHP_AUTH_USER)) ) {
   authenticate();
  }
  else {
   echo "Welcome: $PHP_AUTH_USER<BR>";
   echo "Old: $OldAuth";
   echo "<FORM ACTION="$PHP_SELF" METHOD=POST>\n";
   echo "<INPUT TYPE=HIDDEN NAME="SeenBefore" VALUE="1">\n";
   echo "<INPUT TYPE=HIDDEN NAME="OldAuth" VALUE="$PHP_AUTH_USER">\n";
   echo "<INPUT TYPE=Submit VALUE="Re Authenticate">\n";
   echo "</FORM>\n";
  }
?>

Tests mit Lynx haben gezeigt, dass Lynx die Authentifizierungsinformationen bei Erhalt einer 401-Meldung nicht löscht. Ein Klick auf den Zurück- Button und danach auf Vorwärts wird die angeforderte Adresse öffnen (und zwar so lange, bis die Identifizierung der Benutzer geändert wird).

<!-- Ende Auszug aus dem PHP-Manual -->

Ich denke mal dies dürfte dein Problem erklären.

MfG Thoralf