htaccess - keine Login-Daten im SERVER-Array

[Tom Feller]

Hallo zusammen,

folgendes Anliegen liegen meinen Versuchen zu Grunde:
Ich habe einen Ordner, der einige php5-Dateien enhält. Diese greifen je nach REMOTE_USER auf ein User-Verzeichnis zu, das nur eine XML-Datei mit den anzuzeigenden Daten enthält. Das einzelne Verzeichnis ist per htaccess geschützt.
Damit ich auf das Verzeichnis zugreifen kann, bernötige ich einen LogIn (und damit den REMOTE_USER) bereits im Hauptverzeichnis.
Das habe ich wie folgt gelöst und läuft auch super:

AuthUserFile /home/strato/www/.../.htuser
AuthName "Gesicherter Bereich"
AuthType Basic
require valid-user

Und jetzt wird's kniffelig: Wenn ein User auf die Seite kommt, der sich nicht eingeloggt hat soll auf die gleichen php5-Dateien im Hauptverzeichnis zugegriffen werden - aber auf eine XML-Datei im PUBLIC-Bereich. Auch die Fallunterscheidung ist noch machbar. Aber wie konfiguriere ich die HTACCESS? habe folgendes versucht:

AuthUserFile /home/strato/www/i-/www.i-tn.de/htdocs/.htuser
AuthName "Gesicherter Bereich"
AuthType Basic

Order Deny,Allow
require valid-user
Allow from all
satisfy any

<Files login.php5>
 Deny from all
 require valid-user
</Files>

OK, die Idee war super: Alle können Sich die PUBLIC-Daten anschauen. Die Login-Datei ist geschützt (enthält einen einfachen Javascript-Redirect auf die Hauptseite) und durch den Link erfolgt die Anmeldung. Tatsächlich fragt er auch Username und Passwort ab. Aber sobald man wieder auf der Hauptseite gelandet ist, wird das Feld REMOTE_USER im Serverarray nicht mehr ausgegeben. (und auch kein anderes USER_LOGIN-Feld)

Ich bleibe aber eingelogt, das heisst, beim nächsten Klick auf Login werden die Daten nicht mehr abgefragt. Das Problem ist also ähnlich wie hier: http://forum.de.selfhtml.org/archiv/2004/11/t94808/#m574539

Habe auch schob über print_r($_SERVER) und phpinfo() die verfügbaren Daten durchsucht, ohne Erfolg...

Hat da jemand eine Idee?
Hallo, Welt?

Viele Grüße,
Tom

[Matze]

Hallo,

Ich bleibe aber eingelogt, das heisst, beim nächsten Klick auf Login werden die Daten nicht mehr abgefragt.

läuft dein HTACCESS-Zugang evtl. Cookiebasiert?

Hat da jemand eine Idee?

Ich habe das mal so gelöst, dass ich in der Datei mit dem Redirect eine Session-Variable gesetzt habe.
Die wird dann auf der Hauptseite abgefragt und der entsprechende Inhalt ausgegeben. Ganz einfach und ich brauchte nur eine ganz kleine HTACCESS^^

Grüße, Matze

[Tom Feller]

Ich bleibe aber eingelogt, das heisst, beim nächsten Klick auf Login werden die Daten nicht mehr abgefragt.

läuft dein HTACCESS-Zugang evtl. Cookiebasiert?

Nein, der läuft über die .htaccess:
http://de.selfhtml.org/servercgi/server/htaccess.htm#verzeichnisschutz

Hat da jemand eine Idee?

Ich habe das mal so gelöst, dass ich in der Datei mit dem Redirect eine Session-Variable gesetzt habe.
Die wird dann auf der Hauptseite abgefragt und der entsprechende Inhalt ausgegeben. Ganz einfach und ich brauchte nur eine ganz kleine HTACCESS^^

Habe ich auch schon drüber nachgedacht, einfach den user in ein Cookie zu schmeißen, aber wenn's ohne gehen würde fänd ichs eleganter - und es ist dauch glaube ich sicherer. Handelt sich dahinter um sensibele Adressdaten von verschiedenen Personen...

Grüße, Matze

Cheers :-)

[Matze]

Hallo,

Nein, der läuft über die .htaccess:

Und was denkst du wo die .htaccess deine Daten speichert wenn nicht über
eine Session oder ein Cookie ;)
Mach dir doch mal den Spaß und verweigere Cookies, danach logst du dich ein.

Habe ich auch schon drüber nachgedacht, einfach den user in ein Cookie zu schmeißen, aber wenn's ohne gehen würde fänd ichs eleganter - und es ist dauch glaube ich sicherer. Handelt sich dahinter um sensibele Adressdaten von verschiedenen Personen...

Unsicher würde ich nicht sagen, aber die Session hat mich damals auch gestört.
Vor allem wenn die Session_ID bei Usern, welche keine Cookies akzeptieren,
an die URL angehängt wird.

Grüße, Matze

[Tom]

Hello Matze,

Und was denkst du wo die .htaccess deine Daten speichert wenn nicht über
eine Session oder ein Cookie ;)
Mach dir doch mal den Spaß und verweigere Cookies, danach logst du dich ein.

Der Mechanismus mit HTTP-Status-Code 401 läuft nicht mit Cookies.

http://de3.php.net/features.http-auth

Man kann aber auch auf diesem Mechanismus eine Session aufbauen.
Bei der Session geht es ja nur darum, den Client wiederzuerkennen.
Und das geht auch, wenn er JEDES Mal Passwort und Username mitsendet. :-)

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello Namensvetter, :-)

du kannst im Prinzip auch ohne HT-Access-Zugangsmechanismus des Servers aber trotzdem mit dem Mechanismus "Status 401" auf dem Client arbeiten, wenn Du die Scripte selber schützt.

Voraussetzung ist mMn aber, dass Du PHP als Modul einsetzt.
Kann sein, dass man inzwischen auch in der CGI-Varainte an die beiden Werte herankommt, das weiß ich nicht.

Es gibt Beispiele im Manual:

http://de3.php.net/features.http-auth

$_SERVER['PHP_AUTH_USER']
    $_SERVER['PHP_AUTH_PW']

sind die beiden Variablen, die Du benutzen kannst dafür.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom Feller]

Hello Namensvetter, :-)

:-)

du kannst im Prinzip auch ohne HT-Access-Zugangsmechanismus des Servers aber trotzdem mit dem Mechanismus "Status 401" auf dem Client arbeiten, wenn Du die Scripte selber schützt.

Voraussetzung ist mMn aber, dass Du PHP als Modul einsetzt.

Was bedeutet das?

Kann sein, dass man inzwischen auch in der CGI-Varainte an die beiden Werte herankommt, das weiß ich nicht.

Bin auf einem Apache

Es gibt Beispiele im Manual:

http://de3.php.net/features.http-auth

$_SERVER['PHP_AUTH_USER']
    $_SERVER['PHP_AUTH_PW']

sind die beiden Variablen, die Du benutzen kannst dafür.

Das habe ich auch schon versucht, aber die Variablen werden bei Strato anscheinend nicht unterstützt...?!
In der login.php5 stände dann folgendes:
if(crypt($passOLD,substr($line[1],0,2)) == $line[1]){
 // authentication success.
 $_SERVER['PHP_AUTH_USER'] = $line[0];
 $_SERVER['PHP_AUTH_PW'] = $line[1];
 $line[1] = crypt($passNEW);
} else {
 echo "password incorrect";
 return FALSE;
}

und wenn ich dann auf die Hauptseite komme, steht im Server-Array nix davon...

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Viele Grüße aus Münster

Tom

Tom

[Tom]

Hello,

Voraussetzung ist mMn aber, dass Du PHP als Modul einsetzt.
Was bedeutet das?

Die Weitergabe dieser Werte funktioniert nicht, wenn PHP als CGI läuft, also nicht direkt in den Apachen "eingebaut" ist.

Mit der Funktion php_sapi_name() http://de3.php.net/manual/en/function.php-sapi-name.php kannst Du das abfragen, welche Version bei Dir läuft.

Das habe ich auch schon versucht, aber die Variablen werden bei Strato anscheinend nicht unterstützt...?!

Das liegt dann vermutlich daran, dass PHP als CGI läuft.

In der login.php5 stände dann folgendes:

if(crypt($passOLD,substr($line[1],0,2)) == $line[1])

{

// authentication success.
  $_SERVER['PHP_AUTH_USER'] = $line[0];
  $_SERVER['PHP_AUTH_PW'] = $line[1];
  $line[1] = crypt($passNEW);
}

else
  {

echo "password incorrect";
  return FALSE;
}

und wenn ich dann auf die Hauptseite komme, steht im Server-Array nix davon...

Das ist auch verkehrt herum verstanden.
Frag mal diese beiden Variablen ab, wenn das Script beginnt.

Und wenn nichts drinsteht, dann sendest Du nur einen header.

header('WWW-Authenticate: Basic realm="Toms Seite"');
     header('HTTP/1.0 401 Unauthorized');

Vor dem Header NICHTS anderes senden, auch kein Leerzeichen!

Daraufhin muss der Browser dann das Anmeldefenster Aufklappen.
Wenn Du das ausfüllst und damit einen neuen Request auslöst, muss der Server die beiden Variablen entweder gefüllt haben, oder nicht.

Wenn nein, muss auf jeden Fall ein Wert in $_SERVER["REMOTE_USER"] stehen. Diese Variable ist aber nur vorhanden, wenn der Vorgang mit Status 401 mit einer CGI-Version stattfindet.

Du könntest auch mal schauen, was in den Request-Headern drinsteht.

http://de3.php.net/manual/en/function.getallheaders.php

Ich verstehe immer nicht, warum die Credentials beim CGI nicht da drin stehen sollen.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom Feller]

Die Weitergabe dieser Werte funktioniert nicht, wenn PHP als CGI läuft, also nicht direkt in den Apachen "eingebaut" ist.

Mit der Funktion php_sapi_name() http://de3.php.net/manual/en/function.php-sapi-name.php kannst Du das abfragen, welche Version bei Dir läuft.

Die Unterschiede kannte ich noch gar nicht, was es so alles gibt...
Ja, ist CGI...

Das habe ich auch schon versucht, aber die Variablen werden bei Strato anscheinend nicht unterstützt...?!
Das liegt dann vermutlich daran, dass PHP als CGI läuft.

Jau: PHP läuft bei Strato als CGI

Frag mal diese beiden Variablen ab, wenn das Script beginnt.
Und wenn nichts drinsteht, dann sendest Du nur einen header.

header('WWW-Authenticate: Basic realm="Toms Seite"');
     header('HTTP/1.0 401 Unauthorized');

Vor dem Header NICHTS anderes senden, auch kein Leerzeichen!

OK, will ich machen - aber wie muss ich dann meine HTACCESS schreiben, dass das Skipt weiß, wo es die Zugangsdaten (.htuser) findet? Oder wo kann ich angeben, wo es nach den Zugangsdaten suchen soll?

Daraufhin muss der Browser dann das Anmeldefenster Aufklappen.
Wenn Du das ausfüllst und damit einen neuen Request auslöst, muss der Server die beiden Variablen entweder gefüllt haben, oder nicht.
Wenn nein, muss auf jeden Fall ein Wert in $_SERVER["REMOTE_USER"] stehen. Diese Variable ist aber nur vorhanden, wenn der Vorgang mit Status 401 mit einer CGI-Version stattfindet.

Habe ich versucht, aber er lässt mich jetzt nicht einloggen - auf welche Zugangsdaten greift er jetzt zu?

Du könntest auch mal schauen, was in den Request-Headern drinsteht.
http://de3.php.net/manual/en/function.getallheaders.php

Die Fkt. läuft nicht. Wir dann wohl auch am CGI liegen...

Die Welt könnte so einfach sein...

Vielen Dank soweit und viele Grüße, Tom!
Tom

[Tom]

Hello,

Vor dem Header NICHTS anderes senden, auch kein Leerzeichen!
OK, will ich machen - aber wie muss ich dann meine HTACCESS schreiben, dass das Skipt weiß, wo es die Zugangsdaten (.htuser) findet? Oder wo kann ich angeben, wo es nach den Zugangsdaten suchen soll?

Das Verfahren ist ja dann einwenig anders.
Wenn Du diesen Weg gehst, dann ist nicht mehr der Server derjenige, der den Zugang zu den Verzeichnissen gewährt. Der ist und bleibt über HTTP dann mittels .htaccess verboten. (obwohl man da auch mit doppeltem Boden arbeiten könnte)

Dein Script kann aber Daten, die in diesem von außen geschützten Verzeichnis liegen, an die User ausliefern. Das tut es dann aber nur, wenn diese sich authentifizieren.

Dazu musst Du nur einmal diesen Mechanismus in Gnag setzen, dass der Browser sein Anmeldefenster aufklappt. Das solltest Du auf der Hauptseite anbieten. Dann werden die Daten auf allen von der Hauptseite geborenen Kinder vom Browser automatisch mit an den Server gesendet.

Die Daten kannst Du dann entweder auch aus einer .htaccess-Datei holen. Die müsstest Du dann aber erst parsen, das gesendete Passwort verschlüsseln, (weil es in der htaccess-User-Datei so drinstehen muss) und könntest dann erst vergleichen. Oder aber Du baust Dir eine eigene Userdaten-Datei auf Ein serialisiertes Array und schwupps ist die fertig.

Habe ich hier eben gerade zum testen gemacht.

<?php   ### create_userdata.php ###

$_data = array();
$_data['Thomas'] = 'cafetasse';
$_data['Jürgen'] = 'rosenstock';

$stream = serialize($_data);

file_put_contents('userdata.dat',$stream);

?>

<?PHP
function authenticate()
{
  Header("WWW-authenticate: basic realm="Privater Bereich"");
  Header("HTTP/1.0 401 Unauthorized");

#include("wunderbare_leider_nicht_Seite");

echo "Benutzerdaten erforderlich!";

exit;
}
//-------------- Hauptprogramm -----------------------------------
$data = file_get_contents("userdata.dat");  ## liegt z.B. im include_path

if (!$data) die ("Benutzerdatei ist nicht zugänglich");
$_userdata = unserialize($data);

$_headers = getallheaders();

if (isset($_headers['Authorization']))
{
  $_auth = explode(' ',$_headers['Authorization']);
  $cred = base64_decode($_auth[1]);
  $_UN_PW = explode(':', $cred);

if (isset($_userdata, $_UN_PW[0], $_UN_PW[1], $_userdata[$_UN_PW[0]])
     and ($_UN_PW[1] == $_userdata[$_UN_PW[0]]))
{

## und hier geht es dann weiter mit der Seitenberechnung
    #include("wunderbare_Beguessungsseite");

## usw

}
else
{
  authenticate();
}

$_headers = getallheaders();

$headerhtml = htmlspecialchars(print_r($_headers,1));

echo "<pre>\n";
echo $headerhtml;
echo "</pre>\n";

Ich habe hier den HTML-Teil abgeschnitten, daher vorstehendes in Kurzform.

?>

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom Feller]

Das wäre super wenn das so laufen würde, aber Strato und getallheaders() scheinen sich nicht zu mögen... (una auch nicht die aliase von getallheaders()...)

Fatal error: Call to undefined function getallheaders() in /mnt/.../adressen/output.php5 on line 7

[Tom]

Hello,

Das wäre super wenn das so laufen würde, aber Strato und getallheaders() scheinen sich nicht zu mögen... (una auch nicht die aliase von getallheaders()...)

Fatal error: Call to undefined function getallheaders() in /mnt/.../adressen/output.php5 on line 7

Entschuldige bitte. Steh ja drin in der Funktionsbeschreibung. Das geht auch nur beim Modul.

Ich suche noch nach einer anderen Lösung. Wie vorhin schon geschrieben, muss bei Dir dann $_SERVER['REMOTE_USER'] auftauchen, wenn Du den 401-Dialog einmal erzwungen hast.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

ich glaube, ich ahbe was gefunden für Dich:

http://www.hostsharing.net/dokumentation/www/basic-auth-in-php-abfragen.html

Da musst Du nur mal schnell die Namen austauschen der Variablen und schon müsste es gehen

Ich poste gleich nochmal mein Script mit den neunen Variablennmen, dann brauchst Du nicht soviel zu tippen.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

http://www.hostsharing.net/dokumentation/www/basic-auth-in-php-abfragen.html

<?PHP   ###auth_mit__CGI.php ###

function authenticate()
{
  Header("WWW-authenticate: basic realm="Privater Bereich"");
  Header("HTTP/1.0 401 Unauthorized");

#include("wunderbare_leider_nicht_Seite");

echo "Benutzerdaten erforderlich!";

exit;
}
//-------------- Hauptprogramm -----------------------------------
$data = file_get_contents("userdata.dat");  ## liegt z.B. im include_path

if (!$data) die ("Benutzerdatei ist nicht zugänglich");
$_userdata = unserialize($data);

#$_headers = getallheaders();

if (isset($_SERVER['HTTP_CGI_AUTHORIZATION']))
{
  $_auth = explode(' ',$_SERVER['HTTP_CGI_AUTHORIZATION']]);
  $cred = base64_decode(trim($_auth[1]));
  $_UN_PW = explode(':', $cred);

}

if (isset($_userdata, $_UN_PW[0], $_UN_PW[1], $_userdata[$_UN_PW[0]])
     and ($_UN_PW[1] == $_userdata[$_UN_PW[0]]))
{

## und hier geht es dann weiter mit der Seitenberechnung
    #include("wunderbare_Beguessungsseite");

## usw

}
else
{
  authenticate();
}

$_headers = getallheaders();

$headerhtml = htmlspecialchars(print_r($_headers,1));

echo "<pre>\n";
echo $headerhtml;
echo htmlspecialchars("Username: {$_UN_PW[0]}  Passwort: {$_UN_PW[1]}\n");

echo "</pre>\n";

Ich habe hier den HTML-Teil abgeschnitten, daher vorstehendes in Kurzform.

?>

Schau mal, ob es so funktioniert

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

Ich verstehe immer nicht, warum die Credentials beim CGI nicht da drin stehen sollen.

Bei mir stehen sie drin

(
    [Host] => testserver
    [User-Agent] => Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
    [Accept] => text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    [Accept-Language] => de
    [Accept-Encoding] => gzip,deflate
    [Accept-Charset] => ISO-8859-1,utf-8;q=0.7,*;q=0.7
    [Keep-Alive] => 300
    [Connection] => keep-alive
    [Referer] => http://testserver/~thomas/php4/Authenticate/
    [Cache-Control] => max-age=0, max-age=0
    [Authorization] => Basic VGhvbWFzOmNhZmVrYWtrZQ==
)

$_headers['Authorization'] ist das Feld, dass man auseinandernehmen muss.

$cred = base64_decode($_headers['Authorization']);
  $_UN_PW = explode('.'$cred);

Und hier noch der Ablauf des Ganzen dazu, beschrieben von Dennis Riehle.

Das ist doch nicht normal oder ?!
Unter php.net habe ich keinen Hinweis gefunden woran es liegen könnte.

Wenn du dich per HTTP Authentifizierung bei einem Webserver anmelden möchtest, so setzt dein Browser deine Eingaben wie folgt zusammen:

Username:Passwort

Das kodiert der Browser dann mit Base64 (http://de.wikipedia.org/wiki/Base64) und schreibt als als Authorization Header in den Request rein.
Das könnte z.B. so aussehen:

testuser:testpassword

Ergibt Base64-kodiert:

AHRlc3R1c2VyAHRlc3RwYXNzd29yZA==

Und als Header:

Authorization: Basic AHRlc3R1c2VyAHRlc3RwYXNzd29yZA==

Der Server dekodiert das wieder und trennt Username und Passwort anhand des ersten Doppelpunktes auf. Ergo kannst du im Usernamen keinen Doppelpunkt haben.
Wenn du das Prinzip mal auf alle deine Teste durchgehst, dann wirst du sehen, das der Server immer genau das gemacht hat, nämlich am ersten Doppelpunkt in Username und Passwort aufgeteilt.

Aus einem Username „User:Name” und einem Passwort testpassword wird also:

User:Name:testpassword

Und wenn man der Server es wieder ausliest:

Username: User
  Passwort: Name:testpassword

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom Feller]

Bei mir stehen sie drin

(
    [Host] => testserver
    [User-Agent] => Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
    [Accept] => text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    [Accept-Language] => de
    [Accept-Encoding] => gzip,deflate
    [Accept-Charset] => ISO-8859-1,utf-8;q=0.7,*;q=0.7
    [Keep-Alive] => 300
    [Connection] => keep-alive
    [Referer] => http://testserver/~thomas/php4/Authenticate/
    [Cache-Control] => max-age=0, max-age=0
    [Authorization] => Basic VGhvbWFzOmNhZmVrYWtrZQ==
)

Hmm, bist Du auch bei Strato? oder auch via cgi php unterwegs?

$_headers['Authorization'] ist das Feld, dass man auseinandernehmen muss.

$cred = base64_decode($_headers['Authorization']);
  $_UN_PW = explode('.'$cred);

OK, das wäre es wohl, wenn ich es denn hätte. Aber wie komme ich an das von Dir o.a. Array?
Die Authorization schreibt wird wohl durch WWW-Authenticate in das Array geschrieben, oder? Aber wie gefragt - woher weiß WWW-Authenticate, welche User-Datei es zum Abgleich nehmen muss...

Vielleicht werde ich heute Nacht ja noch fertig...!

[Sven Rautenberg]

Moin!

OK, die Idee war super: Alle können Sich die PUBLIC-Daten anschauen. Die Login-Datei ist geschützt (enthält einen einfachen Javascript-Redirect auf die Hauptseite) und durch den Link erfolgt die Anmeldung. Tatsächlich fragt er auch Username und Passwort ab. Aber sobald man wieder auf der Hauptseite gelandet ist, wird das Feld REMOTE_USER im Serverarray nicht mehr ausgegeben. (und auch kein anderes USER_LOGIN-Feld)

Ich bleibe aber eingelogt, das heisst, beim nächsten Klick auf Login werden die Daten nicht mehr abgefragt. Das Problem ist also ähnlich wie hier: http://forum.de.selfhtml.org/archiv/2004/11/t94808/#m574539

Zwei mögliche Szenarien sind denkbar:

1. Der Browser merkt sich ggf., ob für die Abfrage einer Ressource schon mal ein Passwort verlangt wurde, und sendet bei einem erneuten Request einfach die gespeicherten Anmeldedaten schon mit - oder eben nicht.

2. Der Browser versucht immer, ohne Anmeldedaten Zugriff zu erlangen, und nur beim scheiternden Versuch (Status 401) versucht er, bereits eingegebene Anmeldedaten, die schon mal bei identischem REALM angegeben wurden, mitzusenden. Schlägt auch das fehl, wird erneut das Passwortfenster angezeigt.

Dieses Verhalten ist "normal". Es gibt bei HTTP-Authentifizierung kein "eingeloggt", was man auf andere Seiten mitschleifen könnte, sondern es gilt nur die jeweilige Ressource, und dafür der erlaubte oder verweigerte Zugriff qua definitionem der .htaccess.

Da .htaccess am einfachsten arbeitet, wenn es verzeichnisorientiert eingesetzt wird, solltest du deine URLs für öffentlichen und authentifizierten Zugang ebenfalls separiert verwalten. Dann wird jeglicher Zugriff auf das authentifizierte Verzeichnis mit Passwort und Username abgewickelt, und du hast auf die Information REMOTE_USER Zugriff.

Toms Versuche mit dem Provozieren von Anmeldedaten scheitert meines Erachtens an dem Punkt, wo es darum geht, eine Seite wahlweise unangemeldet oder angemeldet betrachten zu können, denn das grundsätzliche Problem ist ja nicht gelöst: Ohne Anmeldedaten soll ja kein Anmeldefenster erscheinen - aber nur wenn jemals das Anmeldefenster erschien, wird der Browser die Anmeldedaten überhaupt mitsenden.

Abgesehen davon ist ein Verzeichnis, in dem NICHT mit .htaccess der Zugang kontrolliert wird, grundsätzlich unkontrollierter Zugriff von außen möglich. Lediglich die Skripte, die die Authentifizierung prüfen, würden ggf. den Zugriff ablehnen. Es ist von daher taktisch unklug, auf .htaccess zu verzichten.

- Sven Rautenberg

[Tom]

Hello,

Toms Versuche mit dem Provozieren von Anmeldedaten scheitert meines Erachtens an dem Punkt, wo es darum geht, eine Seite wahlweise unangemeldet oder angemeldet betrachten zu können, denn das grundsätzliche Problem ist ja nicht gelöst: Ohne Anmeldedaten soll ja kein Anmeldefenster erscheinen - aber nur wenn jemals das Anmeldefenster erschien, wird der Browser die Anmeldedaten überhaupt mitsenden.

Das mit dem Anmeldefenster lässt sich steuern, indem man den Client ganz bewusst einen 401 anfordern lässt, quasi per "Login-Button". Fortan merkt er sich für den Ressource-Pfad dann Username und Passwort.

Was sich wahrscheinlich nicht regeln lässt, ist das wahlweise Anzeigen oder Ausblenden von Ressourcen im Index. Dafür ist htaccess ja auch nicht gedacht. Oder habe ich jetzt was übersehen?

Abgesehen davon ist ein Verzeichnis, in dem NICHT mit .htaccess der Zugang kontrolliert wird, grundsätzlich unkontrollierter Zugriff von außen möglich. Lediglich die Skripte, die die Authentifizierung prüfen, würden ggf. den Zugriff ablehnen. Es ist von daher taktisch unklug, auf .htaccess zu verzichten.

Meine Idess war da, Verzeichnis immer mit .htaccess schützen und auf diesem Wege gar keinen Zugang zu gewähren, sondern eben nur mit einem Script, dass sich die Dateien dann auf Filesystemebene holt, auflistet und per "Link" an sich selbst zur Verfügung stellt.

Dann kann für jedes File separat geprüft werden, ob es an User ausgeliefert werden darf.
Das ist mit .htaccess und Servermitteln mMn nur sehr umständlich möglich.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Meine Idess war da, Verzeichnis immer mit .htaccess schützen und auf diesem Wege gar keinen Zugang zu gewähren, sondern eben nur mit einem Script, dass sich die Dateien dann auf Filesystemebene holt, auflistet und per "Link" an sich selbst zur Verfügung stellt.

Und wie kommt man per HTTP ohne Anmeldedaten dann an das Skript?

Dann kann für jedes File separat geprüft werden, ob es an User ausgeliefert werden darf.
Das ist mit .htaccess und Servermitteln mMn nur sehr umständlich möglich.

Man kann, wie von Tom in seinem .htaccess beispielhaft demonstriert, pro Ressource (Location oder File) festlegen, welche Zugriffsrichtlinien gelten sollen - sofern man sich die Mühe macht, alle Dateien in einem Verzeichnis zu lagern. Effektiver ist die Verteilung auf mehrere Verzeichnisse, getrennt nach den jeweiligen Zugriffsgruppen bzw. Usern. Das erlaubt dann gleichzeitig auch, auf Dateisystemebene entsprechende Rechtebeschränkungen zu etablieren, sofern das notwendig sein sollte.

Insgesamt kann man sagen, dass dein vorgeschlagener Weg die Sache tendentiell eher verkompliziert, als vereinfacht. Und überdies auch noch unsicherer macht.

- Sven Rautenberg

[Tom Feller]

Hallo Sven,

Zwei mögliche Szenarien sind denkbar:

1. Der Browser merkt sich ggf., ob für die Abfrage einer Ressource schon mal ein Passwort verlangt wurde, und sendet bei einem erneuten Request einfach die gespeicherten Anmeldedaten schon mit - oder eben nicht.

2. Der Browser versucht immer, ohne Anmeldedaten Zugriff zu erlangen, und nur beim scheiternden Versuch (Status 401) versucht er, bereits eingegebene Anmeldedaten, die schon mal bei identischem REALM angegeben wurden, mitzusenden. Schlägt auch das fehl, wird erneut das Passwortfenster angezeigt.

Dieses Verhalten ist "normal". Es gibt bei HTTP-Authentifizierung kein "eingeloggt", was man auf andere Seiten mitschleifen könnte, sondern es gilt nur die jeweilige Ressource, und dafür der erlaubte oder verweigerte Zugriff qua definitionem der .htaccess.

das erklärt das Verhalten - und wahrscheinlich kann man da auch nichts gegen machen, da das Ganze ja anscheinend der Browser entscheidet. Dann muss ich also umdenken...

Da .htaccess am einfachsten arbeitet, wenn es verzeichnisorientiert eingesetzt wird, solltest du deine URLs für öffentlichen und authentifizierten Zugang ebenfalls separiert verwalten. Dann wird jeglicher Zugriff auf das authentifizierte Verzeichnis mit Passwort und Username abgewickelt, und du hast auf die Information REMOTE_USER Zugriff.

Und so habe ich es jetzt auch gemacht. Ich wollte mir das eigentlich ersparen, da ich jetzt zweimal die gleichen Dateien auf dem Server habe und ich auch doppelten Pflegeaufwand habe, aber es führt wohl kein Weg daran vorbei.

Abgesehen davon ist ein Verzeichnis, in dem NICHT mit .htaccess der Zugang kontrolliert wird, grundsätzlich unkontrollierter Zugriff von außen möglich. Lediglich die Skripte, die die Authentifizierung prüfen, würden ggf. den Zugriff ablehnen. Es ist von daher taktisch unklug, auf .htaccess zu verzichten.

Ja, das wollte ich auch nicht...

Du Sven, weißt Du, wie sicher der htaccess-Login ist? Ich habe irgendwo was gelesen von DES-Verschlüsselung der crypt-Funktion, und die hat wohl nur 56 bit. Und trotzt den Standardmäßigem Salt von 2 Ziffern bin ich mir nicht sicher, ob die so generierten Passwörter einem Brut-Force standhalten. Weißt Du was darüber? Oder auch Abhilfe? Denn da ich die Daten des Login-Fenster ja nicht selber Abfrage und überprüfe, sondern das automatisch passiert kann ich ja auch die Verschlüsselungsmethode nicht ändern...
Da irgendeine Idee?

Habe das Ganze jetzt auf jeden Fall aufgeteilt und es läuft so wie gewollt! Habe da wohl etwas zu kompliziert gedacht / bzw. der heutigen IT-Landschaft zu viel zugetraut... ;-)

[Tom]

Hello Tom,

würde mich aber trotzdem noch interessieren, ob Du den Test
https://forum.selfhtml.org/?t=161737&m=1052210
noch durchgeführt hast.

Mich interessiert insbesondere, ob die Server-Variable bei PHP-CGI vorhanden ist.

$_SERVER['HTTP_CGI_AUTHORIZATION']

Ich kann das leider nicht ausprobieren, da alle für mich verfügbaren Server mit der Modulversion ausgestattet sind und ich (jetzt) nicht extra einen hochziehen möchte.

Ich habe mir, durch Deine Aufgabenstellung angeregt, hier eine Variante gebaut, bei der das "Login" quasi "still" stattfinden kann.
Nur durch explizites Klicken auf einen dezenten Button erscheint das Anmeldefenster auf dem Client. Die Anmeldedaten werden dann für die Anmeldeseite (die URL) und alle ihre Unterseiten vom Browser mitgesendet. Ich habe noch keinen gefunden, der das nicht macht.

Alle Verzeichnisse werden nur durch Scripte aufgelistet. Wenn man nicht angemeldet ist, sieht man gar nichts und wenn man angemeldet ist, nur die Dateien (Ressourcen) die man sehen soll.

Direktzugriff ist nicht gestattet.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom Feller]

Hello Tom,

würde mich aber trotzdem noch interessieren, ob Du den Test
https://forum.selfhtml.org/?t=161737&m=1052210
noch durchgeführt hast.

Ich habe die Datei in einem Testverzeichnis abgelegt, das Testverzeichnis ist NICHT durch .htaccess gesichert.
http://www.e-tn.de/sandbox/cgitest/test.php5
Allerdings kann ich mich da nicht einloggen. Wie schon gefragt - woher weiß die function authenticate(), in gegen welche Datei sie die Login-Daten validieren soll? Wo schreibe ich den Username und das Passwort rein?

Mich interessiert insbesondere, ob die Server-Variable bei PHP-CGI vorhanden ist.
    $_SERVER['HTTP_CGI_AUTHORIZATION']

Ja, das wäre interessant...

Ich habe mir, durch Deine Aufgabenstellung angeregt, hier eine Variante gebaut, bei der das "Login" quasi "still" stattfinden kann.
Nur durch explizites Klicken auf einen dezenten Button erscheint das Anmeldefenster auf dem Client. Die Anmeldedaten werden dann für die Anmeldeseite (die URL) und alle ihre Unterseiten vom Browser mitgesendet. Ich habe noch keinen gefunden, der das nicht macht.

Genau DAS war meine Idee!!!

Alle Verzeichnisse werden nur durch Scripte aufgelistet.

Wie meinst?

Wenn man nicht angemeldet ist, sieht man gar nichts

Sollten dann aber schon die öffentlichen Seiten sein bzw. die Daten aus der öffentlichen Ressource geladen werden

und wenn man angemeldet ist, nur die Dateien (Ressourcen) die man sehen soll.

Jau!

Direktzugriff ist nicht gestattet.

Perfekt...

Es bleibt spannend...

[Tom]

Hello,

Ich habe die Datei in einem Testverzeichnis abgelegt, das Testverzeichnis ist NICHT durch .htaccess gesichert.
http://www.e-tn.de/sandbox/cgitest/test.php5
Allerdings kann ich mich da nicht einloggen. Wie schon gefragt - woher weiß die function authenticate(), in gegen welche Datei sie die Login-Daten validieren soll? Wo schreibe ich den Username und das Passwort rein?

Die Funktion authenticate() weiß das gar nicht, die sorgt nur für den Versand des Headers mit dem Statuscode 401.

über doe Zeile

$data = file_get_contents("userdata.dat");  ## liegt z.B. im include_path

wird die Login-Daten-Datei einelesen.
Die solltest Du vorher mit dem Hilfs-Script create_userdata() erzeugt im selben Verzeichnis. Das ist jetzt nur zum testen, später muss die entweder woanders liegen, mit führendem Punkt geschützt werden gegen HTTP-Zugriff oder man nimmt gleich die offizielle .htaccess-Passwrot-Datei. Die müsste dann aber noch geparst werden und außerdem müsste jedes übermittelte Passwort noch verschlüsselt werden vor dem Vergleich. Das aber später.

Mich interessiert insbesondere, ob die Server-Variable bei PHP-CGI vorhanden ist.
    $_SERVER['HTTP_CGI_AUTHORIZATION']
Ja, das wäre interessant...

Das Dumme ist nur, dass die nur vorhanden ist, wenn der Authorization-Header vom Client mitgesandt worden ist und der sendet den nur mit, wenn er einmal durch den Vorgang "Status 401" erfolgreich durchmarschiert ist.

Ich befürchte, dass das Zerlegen des Feldes in "BASIC" n Leerzeichen und den String für Username und Passwort nicht sauber funktioniert, da ich mit explode() in meinem Beispiel nur mit einem Leerzeichen trenne und nicht mit unterschiedlich vielen.

Tausch mal das Stück Code aus

if (isset($_SERVER['HTTP_CGI_AUTHORIZATION']))
{
  #$_auth = explode(' ',$_SERVER['HTTP_CGI_AUTHORIZATION']);

$_auth = preg_split('#\s+#', $_SERVER['HTTP_CGI_AUTHORIZATION']);

$cred = base64_decode(trim($_auth[1]));
  $_UN_PW = explode(':', $cred);
}

Alle Verzeichnisse werden nur durch Scripte aufgelistet.
Wie meinst?

nicht mehr durch den index-Mechanismus des Servers, sondern durch ein Script, dass sich die Dateinamen z.B. mit glob() beschafft und dann eine Link-Liste daraus macht.

Es bleibt spannend...

Ja, denn es lohnt sich nur, das sauber auszuarbeiten, wenn es bei CGI auch funktioniert.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

Allerdings kann ich mich da nicht einloggen. Wie schon gefragt - woher weiß die function authenticate(), in gegen welche Datei sie die Login-Daten validieren soll? Wo schreibe ich den Username und das Passwort rein?

Du hast zwar eine Datei "userdata.dat" im Verzeichnis liegen, darum gibt es keine Fehlermeldung beim file_get_contents(), aber diese Datei ist nicht mit dem Hilfsscript erzeugt worden, was ich Dir gepostet habe. Darum ist sie nicht deserialisierbar und es existieren keine Benutzerdaten im Script

if (isset($_userdata, $_UN_PW[0], $_UN_PW[1], $_userdata[$_UN_PW[0]])
                                               ^^^^^^^^^^^^^^^^^^^^

Das ist die Stelle, an der das Script immer wieder auf authenticate() verzweigt.
Wenn Du die Datei userdata.dat mit dem Hilfsscript erzeugst, könnte der Fehler schon verschwunden sein.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom Feller]

Hallo Tom,

der aktuelle Stand:

http://www.e-tn.de/sandbox/cgitest/init.php5
http://www.e-tn.de/sandbox/cgitest/userdata.dat
http://www.e-tn.de/sandbox/cgitest/test.php5

INIT
<?php   ### create_userdata.php ###
$_data = array();
$_data['Tom'] = 'Tom';
$_data['Gast'] = 'Gast';
$stream = serialize($_data);
file_put_contents('userdata.dat',$stream);
?>

USERDATE
http://www.e-tn.de/sandbox/cgitest/userdata.dat

TEST
Der Aufruf von http://www.e-tn.de/sandbox/cgitest/test.php5 endet mit der in init definierten Benutzerdaten in "Benutzerdaten erforderlich!"

<?PHP   ###auth_mit__CGI.php ###

function authenticate()
{
  Header("WWW-authenticate: basic realm="Privater Bereich"");
  Header("HTTP/1.0 401 Unauthorized");

#include("wunderbare_leider_nicht_Seite");

echo "Benutzerdaten erforderlich!";

exit;
}
//-------------- Hauptprogramm -----------------------------------
$data = file_get_contents("userdata.dat");  ## liegt z.B. im include_path

if (!$data) die ("Benutzerdatei ist nicht zugänglich");
$_userdata = unserialize($data);

#$_headers = getallheaders();

if (isset($_SERVER['HTTP_CGI_AUTHORIZATION']))
{
  #$_auth = explode(' ',$_SERVER['HTTP_CGI_AUTHORIZATION']);

$_auth = preg_split('#\s+#', $_SERVER['HTTP_CGI_AUTHORIZATION']);

$cred = base64_decode(trim($_auth[1]));
  $_UN_PW = explode(':', $cred);
}

if (isset($_userdata, $_UN_PW[0], $_UN_PW[1], $_userdata[$_UN_PW[0]])
     and ($_UN_PW[1] == $_userdata[$_UN_PW[0]]))
{

## und hier geht es dann weiter mit der Seitenberechnung
    #include("wunderbare_Beguessungsseite");

echo "Danke Tom für die Hilfe, es läuft";

}
else
{
  authenticate();
}

$_headers = getallheaders();

$headerhtml = htmlspecialchars(print_r($_headers,1));

echo "<pre>\n";
echo $headerhtml;
echo htmlspecialchars("Username: {$_UN_PW[0]}  Passwort: {$_UN_PW[1]}\n");

echo "</pre>\n";

Ich habe hier den HTML-Teil abgeschnitten, daher vorstehendes in Kurzform.

?>

CU

[Tom]

Hello,

Hallo Tom,

der aktuelle Stand:

http://www.e-tn.de/sandbox/cgitest/init.php5
http://www.e-tn.de/sandbox/cgitest/userdata.dat
http://www.e-tn.de/sandbox/cgitest/test.php5

Ich habe es mir angesehen.

TEST
Der Aufruf von http://www.e-tn.de/sandbox/cgitest/test.php5 endet mit der in init definierten Benutzerdaten in "Benutzerdaten erforderlich!"

Käse.
Dann kommt $_SERVER['HTTP_CGI_AUTHORIZATION'] vermutlich nicht an.
Auf den Versionen mit Aapche und PHP als Modul läuft die andere Version überall.

Dann probier nochmal das.
Mehr fällt mir im Moment nicht ein dazu.

<?PHP

if (!isset($_SERVER['REMOTE_USER'))
  {
     Header("WWW-authenticate: basic realm="Privater Bereich"");
     Header("HTTP/1.0 401 Unauthorized");
  }

echo "<pre>\n";
   echo htmlspecialchars(prin_r($_SERVER,1));
   echo "</pre>\n";

?>

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom Feller]

TEST
Der Aufruf von http://www.e-tn.de/sandbox/cgitest/test.php5 endet mit der in init definierten Benutzerdaten in "Benutzerdaten erforderlich!"

Käse.

Jap

Dann kommt $_SERVER['HTTP_CGI_AUTHORIZATION'] vermutlich nicht an.
Auf den Versionen mit Aapche und PHP als Modul läuft die andere Version überall.

Dann probier nochmal das.
Mehr fällt mir im Moment nicht ein dazu.

<?PHP

if (!isset($_SERVER['REMOTE_USER'))
  {
     Header("WWW-authenticate: basic realm="Privater Bereich"");
     Header("HTTP/1.0 401 Unauthorized");
  }

echo "<pre>\n";
   echo htmlspecialchars(prin_r($_SERVER,1));
   echo "</pre>\n";

?>

Nein, läuft leider auch nicht. Aber hier nochmal die blöde Frage, hab's wohl immer noch nicht verstanden:

Header("WWW-authenticate: basic realm="Privater Bereich"");
Header("HTTP/1.0 401 Unauthorized");

öffnen ein Login-Fenster. Daten werden eingetragen. Womit werden diese Daten verglichen? Wo und wie kann ich einstellen, welche Daten er nehmen soll, wenn NICHT über die .htaccess...?

[Tom Feller]

Ach ja: Das ist das Array nach erfolgreichem LogIn via .htaccess

Array
(
    [TZ] => MET
    [AUTH_TYPE] => Basic
    [DOCUMENT_ROOT] => /home/strato/.../htdocs
    [HTTP_ACCEPT] => image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
    [HTTP_ACCEPT_ENCODING] => gzip, deflate
    [HTTP_ACCEPT_LANGUAGE] => de
    [HTTP_CONNECTION] => Keep-Alive
    [HTTP_COOKIE] => tz_offset=3600; __utma=269952869.2056590294.1187027644.1187028438.1187042090.3; __utmz=269952869.1187027644.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none)
    [HTTP_HOST] => ...
    [HTTP_UA_CPU] => x86
    [HTTP_USER_AGENT] => Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322; InfoPath.2)
    [REMOTE_ADDR] => ...
    [REMOTE_PORT] => ..
    [REMOTE_USER] => gast
    [SCRIPT_FILENAME] => /home/strato/.../cgitest/test.php5
    [SCRIPT_URI] => http://.../cgitest/test.php5
    [SCRIPT_URL] => /.../cgitest/test.php5
    [SERVER_ADMIN] => [e-mail]
    [SERVER_NAME] => ...
    [SERVER_PORT] => 80
    [SERVER_SOFTWARE] => Apache/1.3.37 (Unix)
    [UNIQUE_ID] => ...
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_PROTOCOL] => HTTP/1.1
    [REQUEST_METHOD] => GET
    [QUERY_STRING] =>
    [REQUEST_URI] => /.../cgitest/test.php5
    [SCRIPT_NAME] => /.../cgitest/test.php5
    [PHP_SELF] => /.../cgitest/test.php5
    [REQUEST_TIME] => 1194895794
    [argv] => Array
        (
        )

[argc] => 0
)

[Tom]

Hello,

Ach ja: Das ist das Array nach erfolgreichem LogIn via .htaccess

sieh da sieh da...

aber ohne Authorizatiuon.
Die braucht man nun ja auch nicht mehr, denn wenn das Passwort zu dem User $_SERVER['REMOTE_USER'] nicht gepasst hätte, wäre man ja nicht reingekommen ins Script...

[AUTH_TYPE] => Basic
    [REMOTE_USER] => gast
    [SCRIPT_NAME] => /.../cgitest/test.php5

Mit dem User kannst Du nun natürlich auch in deiner persönlichen Tabelle nachschauen, was dieser darf.

Jetzt wüsste ich gerne noch, ob man das am Apachen auch konfigurieren kann, ob der Authorization-Header mit ins Script übergeben wird, egal ob angemeldet oder nicht ...

ist interessant, was Google da so ausspuckt
http://www.google.de/search?hl=de&q=Apache+['HTTP_CGI_AUTHORIZATION']&btnG=Suche&meta=

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom Feller]

Hallo Tom,

habe Dir vorhin eine Mail geschrieben.

Viele Grüße,

Tom

[Tom]

Hello,

Hallo Tom,
habe Dir vorhin eine Mail geschrieben.

Ich habe die restlichen mir bekannten Möglichkeiten auch ausprobiert.
Mod Rewrite zum Import des Authorization-Headers scheint auch keine Lösung zu sein.
Das wird mit einem 500er Status bestraft.

Wenn man berücksichtigt, dass man die Zeit, die man (hier mit dazulernen) verdaddelt, bezahlen müsste, dann wäre es allemal billiger Strato den Rücken zu kehren und einen Root-Server oder auch nur einen Virtual Server bei einem kooperativeren Partner zu nehmen...

Die Script-basierte Authorisierung kannst Du also vergessen, wenn nicht noch ein schlaeuer Mitleser einen Lösungsvorschlag macht :-(

In der Modulversion bin ich inzwischen so weit, dass es richtig komfortabel wird. Mit einem kleinen "Umsteiger" (Hinweis nach dem "Logout" den Abbrechen-Button vom Anmeldefenster zu drücken, kann man sich sogar wieder "abmelden", also den Browser veranlassen, seine Authorization-Daten wieder fallen zu lassen. Funktioniert sogar im IE 5.5.

Allerdings lobe ich mir da Cookie-basierte-Sessions über SSL. Das macht das Ganze noch angenehmer. Solltest Du Dir vielleicht alternativ auch überlegen.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom Feller]

Hallo Tom,

Wenn man berücksichtigt, dass man die Zeit, die man (hier mit dazulernen) verdaddelt, bezahlen müsste, dann wäre es allemal billiger Strato den Rücken zu kehren und einen Root-Server oder auch nur einen Virtual Server bei einem kooperativeren Partner zu nehmen...

:-) Wo es dann natürlich wieder andere "Pannen" geben kann... Allen in allem ist Strato nicht der Beste, nicht der Billigste, nicht die Beste Hotline, nicht... aber für mich schon ok...

In der Modulversion bin ich inzwischen so weit, dass es richtig komfortabel wird. Mit einem kleinen "Umsteiger" (Hinweis nach dem "Logout" den Abbrechen-Button vom Anmeldefenster zu drücken, kann man sich sogar wieder "abmelden", also den Browser veranlassen, seine Authorization-Daten wieder fallen zu lassen. Funktioniert sogar im IE 5.5.

Hast Du da einen Link? Würde mir das gerne mal anschauen, so zum Appetit holen für einen eigenen / anderen Server...

Allerdings lobe ich mir da Cookie-basierte-Sessions über SSL. Das macht das Ganze noch angenehmer. Solltest Du Dir vielleicht alternativ auch überlegen.

Ich habe jetzt die Dateien in ein öffentliches Verzeichnis gespiegelt. Das ist nicht ganz so elegant, funktioniert aber auch. Und inzwischen sogar mit SSL.

Viele Grüße,

Tom

[Tom]

Hello,

In der Modulversion bin ich inzwischen so weit, dass es richtig komfortabel wird. Mit einem kleinen "Umsteiger" (Hinweis nach dem "Logout" den Abbrechen-Button vom Anmeldefenster zu drücken, kann man sich sogar wieder "abmelden", also den Browser veranlassen, seine Authorization-Daten wieder fallen zu lassen. Funktioniert sogar im IE 5.5.
Hast Du da einen Link? Würde mir das gerne mal anschauen, so zum Appetit holen für einen eigenen / anderen Server...

Das liegt hier lokal.
Auf unseren öffentlichen Servern (leider auch alle bei Strato gemietet) ist momentan der Bär los. Die haben irgendwas in der globalen Firewall geändert und nun gehen HTTP-Posts auf andere Server nicht mehr sauber raus. Mein Partner ist am Rumtoben. Drei bisher gut besuchte Seiten stehen.

Da haben wir Samstag- und Sonntagnacht bis zum Hellwerden gesessen.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom Feller]

Da haben wir Samstag- und Sonntagnacht bis zum Hellwerden gesessen.

Zja, das ist unsere Zeit...
Ich bin schonmal gefragt worden, on ich in einer anderen Zeitzone lebe...

Danke für die Hilfe und bis zum nächsten Mal!

[Tom]

Hello,

<?PHP

error_reporting(E_ALL);

if (!isset($_SERVER['REMOTE_USER']))

{
     Header("WWW-authenticate: basic realm="Privater Bereich"");
     Header("HTTP/1.0 401 Unauthorized");
  }

echo "<pre>\n";

echo htmlspecialchars(print_r($_SERVER,1));

echo "</pre>\n";

?>

Nein, läuft leider auch nicht. Aber hier nochmal die blöde Frage, hab's wohl immer noch nicht verstanden:

Da waren noch Fehler drin.
Ich kann mir aber nicht vorstellen, dass $_SERVER['REMOTE_USER'] auch nicht im Script ankommt.

Header("WWW-authenticate: basic realm="Privater Bereich"");
Header("HTTP/1.0 401 Unauthorized");

öffnen ein Login-Fenster. Daten werden eingetragen.

Das kleine Fensterchen am Client ist die Reaktion auf den 401-Header.
Das zeigt den Teil aus "WWW-authenticate: basic" an, wenn es abgebrochen wird, zeigt es das (valide) HTML-Dokument an, was auf die Header folgen sollte.

Mit OK sendet der Browser nun einen neuen Request an dieselbe URI, es ist nur der HTTP-Header ergänzt durch die Zeile "Authorization Basic SvxyZ2VuOmJpZXJiYXVjaA=="

(hier mit dem verpackten Usernamen "Jürgen" und dem Passwort "bierbauch"

Diese Daten haben wir im Script zerlegt (es zumindest versucht) in die beiden Teile

$_UN_PW[0] und $_UN_PW[1]

Und die haben wir dann verglichen mit den Werten aus der Datei, wir erzeugt hatten.

if (isset($_userdata, $_UN_PW[0], $_UN_PW[1], $_userdata[$_UN_PW[0]])

and ($_UN_PW[1] == $_userdata[$_UN_PW[0]]))
{
  ## OK
}
else
{
    ### nochmal authenticate() aufrufen.
    ### und das Script danach mit exit abbrechen (Das EXIT steckt in der Funktion!)
}

Es ergibt sich also eine Schleife ("Pingpong") mit dem Client.

if (isset($_userdata, $_UN_PW[0], $_UN_PW[1],    ### Sind die Variablen gesetzt?

$_userdata[$_UN_PW[0]])                     ### ist der Schlüssel $_UN_PW[0] im
                                                 ### Array $_userdata vorhanden?

and ($_UN_PW[1] == $_userdata[$_UN_PW[0]]))  ### und ist dessen zugehöriger Wert = $_UN_PW[1]?
{
  ## OK
}

Der Test wird also vom Script vorgenommen.

Mehr steckt nicht dahinter.

Und wenn wir herausfinden könnten, warum im CGI-Script überhaupt keine Authentication Data ankommen, dann kännten wir das auch ausbauen...

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Du Sven, weißt Du, wie sicher der htaccess-Login ist? Ich habe irgendwo was gelesen von DES-Verschlüsselung der crypt-Funktion, und die hat wohl nur 56 bit.

Reine Zugriffskontrolle ohne HTTPS ist komplett als unsicher zu betrachten, weil die Passworte in der Regel unverschlüsselt übertragen werden - zumindest bei der Methode "Basic". Die Passwörter durch andere Methoden zu sichern ist allerdings kaum wirklich sinnvoll, da ja die zu sichernden Inhalte ebenfalls unverschlüsselt übertragen werden. Wenn es um vertrauliche Informationen geht, kommst du um SSL für diesen Bereich der Site nicht drumherum.

Sollte tatsächlich die crypt-Funktion dafür zuständig sein, die Passwörter in der .htusers zu hashen, dann mußt du im extremsten Fall davon ausgehen, dass die dadurch provozierte Maximallänge der Passwörter nur bei 8 Zeichen liegt - alles darüber hinaus wird beim hashen abgeschnitten und bei der Authentifizierung nicht geprüft.

Allerdings ist die crypt-Funktion nicht auf dieses uralte Unix-Verfahren festgelegt, so dass durchaus auch stärkere Hashing-Methoden zum Einsatz kommen könnten. Empfehlenswert ist dennoch, auf die klassische Crypt-Methode zu verzichten, und stattdessen MD5 oder SHA1 zu nehmen.

Und trotzt den Standardmäßigem Salt von 2 Ziffern bin ich mir nicht sicher, ob die so generierten Passwörter einem Brut-Force standhalten.

Du darfst davon ausgehen, dass gecryptete Passwörter, die mit der alten Crypt-Methode erzeugt wurden, knackbar sind. Allerdings setzt das ja voraus, dass jemand Zugriff auf die in der .htusers gespeicherten Passworte hat. Das ist ja aber eher unwahrscheinlich.

Weißt Du was darüber? Oder auch Abhilfe? Denn da ich die Daten des Login-Fenster ja nicht selber Abfrage und überprüfe, sondern das automatisch passiert kann ich ja auch die Verschlüsselungsmethode nicht ändern...

Du darfst davon ausgehen, dass der in REMOTE_USER enthaltene Benutzername vom Apachen gründlich geüprüft wurde und korrekte Daten angegeben hat. Wenn du "sichere" Passwort-Hashes verwenden möchtest, mußt du die lediglich in der .htusers verwenden - auf die wirst du ja wohl Einfluß haben. Den Rest macht der Apache automatisch. Er erkennt das anzuwendende Verfahren automatisch - auch beliebige Mischungen je User sind problemlos machbar.

- Sven Rautenberg

[Tom Feller]

n'Abend!

Reine Zugriffskontrolle ohne HTTPS ist komplett als unsicher zu betrachten, weil die Passworte in der Regel unverschlüsselt übertragen werden - zumindest bei der Methode "Basic". Die Passwörter durch andere Methoden zu sichern ist allerdings kaum wirklich sinnvoll, da ja die zu sichernden Inhalte ebenfalls unverschlüsselt übertragen werden. Wenn es um vertrauliche Informationen geht, kommst du um SSL für diesen Bereich der Site nicht drumherum.

Na, dann richte ich das ein, ist ja kein großes problem, denke ich. Gemacht habe ich's noch nie, aber das wird wohl schon werden...

Sollte tatsächlich die crypt-Funktion dafür zuständig sein, die Passwörter in der .htusers zu hashen, dann mußt du im extremsten Fall davon ausgehen, dass die dadurch provozierte Maximallänge der Passwörter nur bei 8 Zeichen liegt - alles darüber hinaus wird beim hashen abgeschnitten und bei der Authentifizierung nicht geprüft.

Ja, das habe ich auch gelesen... Das ist bei den heutigen Bot-Netzen wirklich nicht viel.
ZITAT:
März 2006 Der FPGA-basierte Parallelrechner COPACOBANA kostet weniger als 10.000 Dollar (Materialkosten) und bricht DES in weniger als 9 Tagen
http://de.wikipedia.org/wiki/Data_Encryption_Standard

Aber wenn ich mal von folgender Rechnugn ausgehe:
56bit effektive Schlüssellänge = 2^56 theoreitsche Möglichkeiten. Macht also theoretisch 2^28 Suchmöglichkeiten = 268.435.456 Fälle.
(siehe heirzu auch http://de.wikipedia.org/wiki/Geburtstagsparadoxon)

Ich schätze, da bekäme ich vorher Post von meinem Provider...

Du darfst davon ausgehen, dass gecryptete Passwörter, die mit der alten Crypt-Methode erzeugt wurden, knackbar sind. Allerdings setzt das ja voraus, dass jemand Zugriff auf die in der .htusers gespeicherten Passworte hat. Das ist ja aber eher unwahrscheinlich.

Ja, das stimmt...

Weißt Du was darüber? Oder auch Abhilfe? Denn da ich die Daten des Login-Fenster ja nicht selber Abfrage und überprüfe, sondern das automatisch passiert kann ich ja auch die Verschlüsselungsmethode nicht ändern...
Du darfst davon ausgehen, dass der in REMOTE_USER enthaltene Benutzername vom Apachen gründlich geüprüft wurde und korrekte Daten angegeben hat. Wenn du "sichere" Passwort-Hashes verwenden möchtest, mußt du die lediglich in der .htusers verwenden - auf die wirst du ja wohl Einfluß haben. Den Rest macht der Apache automatisch. Er erkennt das anzuwendende Verfahren automatisch - auch beliebige Mischungen je User sind problemlos machbar.

Das läuft (bei Strato) zumindest nicht - habe gerade einfach mal interesseweiser den MD5 von gast eingegeben (d4061b1486fe2da19dd578e8d970f7eb) und konnte mich mit gast:gast nicht einloggen...

Kann man davon ausgehen, dass das Login so mit .htfile und SSL sicher ist?

Viele Grüße aus Münster,

Tom

[Sven Rautenberg]

Moin!

Reine Zugriffskontrolle ohne HTTPS ist komplett als unsicher zu betrachten, weil die Passworte in der Regel unverschlüsselt übertragen werden - zumindest bei der Methode "Basic". Die Passwörter durch andere Methoden zu sichern ist allerdings kaum wirklich sinnvoll, da ja die zu sichernden Inhalte ebenfalls unverschlüsselt übertragen werden. Wenn es um vertrauliche Informationen geht, kommst du um SSL für diesen Bereich der Site nicht drumherum.
Na, dann richte ich das ein, ist ja kein großes problem, denke ich. Gemacht habe ich's noch nie, aber das wird wohl schon werden...

So einfach ist das wiederum dann aber doch nicht. Mag sein, dass Strato dir da einen SSL-Proxy zur Verfügung stellt. Der bildet zum Internet hin die Endstelle der SSL-Kommunikation (läuft auch unter einer anderen Domain), leitet die Requests dann aber unverschlüsselt auf deinen Server (durch das interne Strato-Netz). Ist also im Verhältnis natürlich sicherer, als wenn die Daten unverschlüsselt durch das gesamte Internet müssen (Strato wird sich gegen Mitlauscher im eigenen Netzwerk zu schützen wissen, das klappt zumindest nicht unentdeckt), bedeutet aber mindestens mal, dass man diese Sonderkonstruktion in seiner Linkgestaltung beachten muß.

Alternativ, wenn man einen eigenen Server hat, kann man natürlich auch sein eigenes SSL einrichten, mit Zertifikat etc.. Allerdings hast du keinen eigenen Server, ansonsten würdest du dich nicht mit der CGI-Variante von PHP rumärgern... :)

Aber wenn ich mal von folgender Rechnugn ausgehe:
56bit effektive Schlüssellänge = 2^56 theoreitsche Möglichkeiten. Macht also theoretisch 2^28 Suchmöglichkeiten = 268.435.456 Fälle.
(siehe heirzu auch http://de.wikipedia.org/wiki/Geburtstagsparadoxon)

Ich schätze, da bekäme ich vorher Post von meinem Provider...

Nein, kriegst du nicht unbedingt. Entweder probiert jemand alle möglichen 8-Zeichen-Passwörter durch (beginnend mit typischen Wortlisten) - das wird sicherlich irgendwie dumm auffallen. Oder jemand konnte dir deine .htusers-Datei klauen - dann rechnet er die Passworte logischerweise zuhause aus, und meldet sich auf deinem Server erst wieder, wenn er ein Passwort gefunden hat.

Das läuft (bei Strato) zumindest nicht - habe gerade einfach mal interesseweiser den MD5 von gast eingegeben (d4061b1486fe2da19dd578e8d970f7eb) und konnte mich mit gast:gast nicht einloggen...

Logisch. Das MD5-Passwort muß ja auch ganz anders gestaltet sein, damit der Erkennungsmechanismus des Apaches das verarbeiten kann.

Besorg' dir am besten das Programm "htpasswd" (ist bei jeder Installation des Apachen, egal ob Linux oder Windows, dabei). Damit kannst du auf der Kommandozeile .htusers-Dateien mit den Passwörtern erstellen, und zwar in allen denkbaren Hash-Varianten. MD5-Passworte beginnen, wenn ich mich recht erinnere, irgendwie mit {1}$blablba..., und am Ende hängt dann das MD5 aus Salt und Passwort.

Kann man davon ausgehen, dass das Login so mit .htfile und SSL sicher ist?

Du kannst dich darauf verlassen, dass folgende Aussage stimmt: Mit per .htaccess konfigurierter Zugangskontrolle ist garantiert, dass die geschützte Ressource nur dann ausgeliefert wird, wenn Benutzername und Passwort den Zugriff erlauben.

Du kannst prinzipbedingt nicht kontrollieren, ob derjenige, der Benutzername und Passwort korrekt angegeben hat, ein guter oder ein böser Bube ist. Und ohne SSL kannst du logischerweise auch nicht verhindern, dass die Information auf dem Transportweg von anderen bösen Buben abgefangen und kopiert werden könnte.

Wenn der wirtschaftliche Wert der Information als geringer zu bewerten ist, als die Kosten für die Einrichtung eines SSL-Bereichs, dann ist SSL überflüssig. Ansonsten ist es eine Abwägungsfrage.

Wir haben bei SELFHTML aus Sicherheitsgründen sämtliche internen Bereiche, bei denen sich Developer oder Redakteure anmelden können, aus Prinzip mit SSL gesichert. Das Risiko einer Kompromittierung unseres Informationsangebots und die damit verbundenen Kosten sind deutlich größer, als unsere Kosten für die Einrichtung von SSL. Das hat nämlich nur einen kurzen Zeitaufwand für die Konfiguration und 0 Euro für das Zertifikat von CACert gekostet. Dummerweise ist CACert derzeit noch in keinem Browser als vertrauenswürdige Zertifizierungsstelle integriert, man kriegt also dumme Browsersicherheitsmeldungen - für den kommerziellen Einsatz leider noch ungeeignet.

- Sven Rautenberg

[Tom Feller]

Hallo Sven

[SSL einrichten bei Strato]

Habe es mir gerade mal angeschaut, das ist wirklich Idioten-Sicher. Ich rufe die Domain

http://www.i-tn.de einfach über
https://www.ssl-id.de/i-tn.de/

auf und schon ist der ganze Senf verschlüsselt. Geht mit jeder Seite so, die bei Strato gehostet ist. Das ist ja mal Krass. Jetzt habe ich nur noch so eine nervige URl im Browser, aber da könnte man dann ja auch einfach ein Hidden Redirect machen, oder? (Obwohl ich ja sowas eigentlich überhaupt nicht mag...) Wenn nicht störts erstmal auch nicht.
Ist wohl nicht die Top-Lösung, aber funktional erstmal in Ordnung.

Alternativ, wenn man einen eigenen Server hat, kann man natürlich auch sein eigenes SSL einrichten, mit Zertifikat etc.. Allerdings hast du keinen eigenen Server, ansonsten würdest du dich nicht mit der CGI-Variante von PHP rumärgern... :)

Du sagst es...

Oder jemand konnte dir deine .htusers-Datei klauen - dann rechnet er die Passworte logischerweise zuhause aus, und meldet sich auf deinem Server erst wieder, wenn er ein Passwort gefunden hat.

Aber wie kann jemand Zugang auf meine .htuser bekommen? Ich dachte, dass wäre nun wirklich auzuschließen, es sei denn, jemand geht mit Brut Force oder anderen Aktionen direkt an meinen FTP-Account. Aber dann kann er die User-Datendatei ja auch direkt runterladen. Wenn ich's mir Recht überlege, ist das eigentlich das größte Sicherheits-Risiko...

Das läuft (bei Strato) zumindest nicht - habe gerade einfach mal interesseweiser den MD5 von gast eingegeben (d4061b1486fe2da19dd578e8d970f7eb) und konnte mich mit gast:gast nicht einloggen...

Logisch. Das MD5-Passwort muß ja auch ganz anders gestaltet sein, damit der Erkennungsmechanismus des Apaches das verarbeiten kann.
Besorg' dir am besten das Programm "htpasswd" (ist bei jeder Installation des Apachen, egal ob Linux oder Windows, dabei). Damit kannst du auf der Kommandozeile .htusers-Dateien mit den Passwörtern erstellen, und zwar in allen denkbaren Hash-Varianten. MD5-Passworte beginnen, wenn ich mich recht erinnere, irgendwie mit {1}$blablba..., und am Ende hängt dann das MD5 aus Salt und Passwort.

Ah ok, dass mache ich gleich mal, Danke für den Tip!

Kann man davon ausgehen, dass das Login so mit .htfile und SSL sicher ist?
Du kannst dich darauf verlassen, dass folgende Aussage stimmt: Mit per .htaccess konfigurierter Zugangskontrolle ist garantiert, dass die geschützte Ressource nur dann ausgeliefert wird, wenn Benutzername und Passwort den Zugriff erlauben.

Das ist doch mal ne Ansage! Mehr kann man ja heutzutage kaum erreichen, wenn man den Server nicht selber aufsetzt.

Du kannst prinzipbedingt nicht kontrollieren, ob derjenige, der Benutzername und Passwort korrekt angegeben hat, ein guter oder ein böser Bube ist. Und ohne SSL kannst du logischerweise auch nicht verhindern, dass die Information auf dem Transportweg von anderen bösen Buben abgefangen und kopiert werden könnte.

Selbst mit SSL und WPA könnte sich noch jemand daran versuchen - aber ich sichere ja keine Atomkraftwerke gegen Atombomben ab...

Wenn der wirtschaftliche Wert der Information als geringer zu bewerten ist, als die Kosten für die Einrichtung eines SSL-Bereichs, dann ist SSL überflüssig. Ansonsten ist es eine Abwägungsfrage.

Das ist eine vernünftige Regel, sollte man vielleicht mal häufiger Proagieren. Weil sie in die eine wie in die andere Reichtung eine Entscheidung fordert - und ganz häufig machen sich die Leute über Security ja leider zu wenig (oder auch viel zu viele) Gedanken.
Wenn ich also Adressen sichere, die frei zugänglich im Telefonbuch stehen kann der Schaden ja nicht so groß werden. Nun, jetzt habe ich noch E-Mail-Adressen, die will ich natürlich gegen SPAM schützen und und und - aber es ist eben doch was anderes als beispielsweise die Privatnummern der Scheiche dieser Welt...

Wir haben bei SELFHTML

Ah, ich wusste garnicht, dass Du von hier kommst. Um so größer mein Dank, dass Du Dich mit diesem Problem auseinander setzt!

aus Sicherheitsgründen sämtliche internen Bereiche, bei denen sich Developer oder Redakteure anmelden können, aus Prinzip mit SSL gesichert. Das Risiko einer Kompromittierung unseres Informationsangebots und die damit verbundenen Kosten sind deutlich größer, als unsere Kosten für die Einrichtung von SSL. Das hat nämlich nur einen kurzen Zeitaufwand für die Konfiguration und 0 Euro für das Zertifikat von CACert gekostet. Dummerweise ist CACert derzeit noch in keinem Browser als vertrauenswürdige Zertifizierungsstelle integriert, man kriegt also dumme Browsersicherheitsmeldungen - für den kommerziellen Einsatz leider noch ungeeignet.

Tja, aber dafür gibt es auch leider eine Reihe von Zertifizierungsstellen, die den Namen gar nicht verdient haben - und dann gibt es wieder User, die akzeptieren freizügig die Vererbung von Vertrauenseinstellungen...

Aber was will man sagen, am Ende hat noch keiner eine Grippe vom Rechner bekommen.

[Christian Seiler]

Hallo,

mal kurz ein kleiner Exkurs, weil Du's gerade so schön erwähnst:

aber ich sichere ja keine Atomkraftwerke gegen Atombomben ab...

Man braucht Atomkraftwerke nicht vor Atombomben zu schützen: Eine Atombombe wird definitiv *nicht* durch das radioaktive Material in Atomkraftwerken verstärkt werden - denn das Material wird in hinreichend großem Abstand oder mit Regelungsstäben dazwischen aufbewahrt, dass dort keine thermonukleareExplosion in Gang gebracht werden kann. Wenn man also eine Atombombe in der Nähe oder gar in einem Atomkraftwerk hochgehen lassen würde, dann würde die Atombombe auch nicht mehr oder weniger anrichten, als sie sowieso schon anrichten würde (was für sich genommen natürlich schon schlimm genug ist) - aber ein _besonderes_ Gefährdungspotential diesbezüglich stellen Atomkraftwerke nicht dar.

Und auch der GAU bei einem Atomkraftwerk ist definitiv NICHT eine thermonukleare Explosion - das ist auch nicht das, was in Tschernobyl passiert ist (und das war ein GAU). Das schlimmste, was bei einem Atomkraftwerk passieren kann, ist, dass es eine sogenannte Kernschmelze gibt - das heißt: es wird so viel Hitze durch die Kernreaktionen freigesetzt, dass es eine normale chemische Explosion alleine auf Grund der Energiemenge gibt. Eine atomare Explosion bekommt man mit einem Kernkraftwerk nicht hin (die Kernkraftwerke sind so konstruiert, dass alleine auf Grund der Geometrie keine kritische Masse zustandekommen kann [1]). Eine Kernschmerzle ist natürlich auch nicht zu verharmlosen, denn damit geraten jede Menge radioaktiver Materialien in die Atmosphäre und wir sehen ja, was Tschernobyl angerichtet hat.

Ich will hier auch gar keine Gefahr herunterspielen, ich wollte das jedoch nur mal ergänzen, weil sich teilweise hartnäckige Fehlinformationen in der Bevölkerung halten und man in meinen Augen druchaus differenzieren sollte, wenn man über solche Themen spricht.

Ich weiß, Du hast hier nur eine Metapher anbringen wollen und das nicht ganz ernst gemeint ;-), aber es passte halt so schön hier her.

Viele Grüße,
Christian

[1] Gut, wenn man die Brennstäbe sammelt und auf einen Haufen schmeißt, erreicht man die kritische Masse, aber kritische Masse alleine macht noch keine Atombome aus - wenn man zwei Plutioniumhalbkugeln, die zusammen etwas mehr als die kritische Masse besitzen, einfach zusammenhält, dann gibt's einen kleinen Knall und die Dinger fliegen auseinander (wie bei einem Chinaböller, nur halt ungesünder ;-)) - aber eine Atomexplosion findet nicht wirklich statt. Bei einer Atombombe werden die Massenteile des Spaltmaterials mit Sprengstoff so stark aufeinanderzubeschleunigt, dass der Druck, der durch die Energiefreisetzung entsteht, nicht ausreicht, die Teile schnell genug wieder zu trennen, bevor die richtige Kettenreaktion in Gang kommt. Und das ist - zum Glück für uns alle, sonst gäbe es viel mehr Atombomben - alles andere als trivial zu realisieren (und nein, ich habe keine Ahnung, wie das technisch konkret funktioniert, es lohnt sich also nicht, mich in den Iran zu entführen ;-)).

[Dennis]

Hi Sven,

Besorg' dir am besten das Programm "htpasswd" (ist bei jeder Installation des Apachen, egal ob Linux oder Windows, dabei). Damit kannst du auf der Kommandozeile .htusers-Dateien mit den Passwörtern erstellen, und zwar in allen denkbaren Hash-Varianten. MD5-Passworte beginnen, wenn ich mich recht erinnere, irgendwie mit {1}$blablba..., und am Ende hängt dann das MD5 aus Salt und Passwort.

Genau, die Hashs auf MD5-Basis für den Apachen sind etwas anderes als eine einfache MD5-Prüfsumme. Der Eintrag in einer .htpasswd Datei für einen User „user” mit dem Passwort „test” könnte zum Beispiel so aussehen:

user:$apr1$xYWcW/..$QKkGfMB/2Wgu/K5xIp946/

Der Hash des Passworts fängt (speziell für den Apache) immer mit einem apr1 an, genannt Magic String. Danach folgt der Salt, welcher bis zu acht Buchstaben lang sein kann und letztendlich kommt das gehashte Passwort. Diese drei Einzelteile werden dann durch $ getrennt und mit einem $ vorangestellt zusammengefügt.

Die Erstellung eines solchen Hashs ist nicht ganz so trivial. In Perl gibt es dazu Crypt::PasswdMD5, für PHP haben wir das vor einiger Zeit mal als md5crypt übersetzt. Für das „htpasswd”-Programm kannst du mit dem Flag „-m” die sogenannte „MD5 encryption” erzwingen.

Viele Grüße,
  ~ Dennis.

[Tom Feller]

Hallo Dennis,

Die Erstellung eines solchen Hashs ist nicht ganz so trivial. In Perl gibt es dazu Crypt::PasswdMD5, für PHP haben wir das vor einiger Zeit mal als md5crypt übersetzt. Für das „htpasswd”-Programm kannst du mit dem Flag „-m” die sogenannte „MD5 encryption” erzwingen.

ich habe mir gerade die Datei heruntergeladen und eingebaut - super! Läuft problemlos und ab jetzt wird jedes neue oder geänderte Passwort per MD5 codiert, der Rest bleibt erstmal bei DES.

Ich sag mal: .htaccess mit md5 und ssl - da wird's jetzt für Angreifer schon schwer, oder?

Danke für den Tip!

Tom