Simple Passwortverwaltung für Apache mit htaccess

[fastix®]

Moin!

Ich habe für den Indianer eine _wirklich_ kleine Passwortverwaltung gestrickt.

http://www.fastix.de/r/htpasswd.txt

Herunterkopieren, nach beliebig.php umbennen (und gut merken), aufrufen und dann erst einen Benutzer anlegen, bevor gesperrt wird!
Erster Schwachpunkt: geht nicht auf Windows-Kisten.

Den Rest stelle ich zur Diskussion.

So belassen legt das Ding, wenn nicht vorhanden, folgende Dateien an:

.htaccess
.htpasswd

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[ChrisB]

Hi,

Den Rest stelle ich zur Diskussion.

if (isset($_POST['user']) && $_POST['user'] && isset($_POST['pass']) && ($_POST['pass'])) {  
 #Benutzer anlegen  
 $user=strtolower(trim($_POST['user']));

Gibt's einen guten Grund, warum du hier den Benutzernamen in Kleinbuchstaben umwandelst?

MfG ChrisB

[fastix®]

Moin!

Gibt's einen guten Grund, warum du hier den Benutzernamen in Kleinbuchstaben umwandelst?

[x] gefixt. Jetzt kann er alles verwenden, außer den Zeichen, die htpasswd2 ablehnt.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Sven Rautenberg]

Moin!

Ich habe für den Indianer eine _wirklich_ kleine Passwortverwaltung gestrickt.

In der viele unlogische Dinge passieren.

Erster Schwachpunkt: geht nicht auf Windows-Kisten.

Weil du nicht MD5 zum Passworthashen benutzt.

Außerdem unlogisch: Für das Hinzufügen des neuen Users benutzt du einen Systemaufruf von htpasswd2, zum Löschen und alle andere Aufgaben benutzt du es nicht.

Sicherheitslücke: Du übergibst der Kommandozeile ohne Escaping Dateiname, Username und Passwort!!!

Unschönheit: Deine Funktionsnamen fangen mal mit großen, mal mit kleinen Buchstaben an.

Unschönheit 2: Deine Funktionen sitzen unlogisch platziert zwischen Hauptprogramm und Ausgabe.

Unschönheit 3: getDirName() geht auch viel einfacher: return dirname($_SERVER['SCRIPT_FILENAME']);

Unschönheit 4: Indem das Skript selbst die Dateien .htacess und .htpasswd anlegt, werden diese bei vielen Providern nicht mehr per FTP zugänglich sein, Kopieren oder Löschen funktioniert dann nicht. Das ist durchaus sehr dramatisch!

Es finden sich sicherlich noch deutlich mehr Unschönheiten. Kommentar bis jetzt: Guter Versuch, schlechteste Ausführung.

- Sven Rautenberg

[Sven Rautenberg]

Moin!

Sorry, aber das hier muss ich nochmal deutlicher erklären, um die Dramatik dieser Zeile zu betonen:

Sicherheitslücke: Du übergibst der Kommandozeile ohne Escaping Dateiname, Username und Passwort!!!

Man kann beliebige Systemkommandos im Kontext des Webserverusers ausführen! Dazu muss man einfach nur "passende" Usernamen oder Passworte benutzen.

So, wie das Skript derzeit ist, ist es gefährlich und sollte sofort offline genommen werden!

- Sven Rautenberg

[fastix®]

Moin!

Moin!

Sorry, aber das hier muss ich nochmal deutlicher erklären, um die Dramatik dieser Zeile zu betonen:

Sicherheitslücke: Du übergibst der Kommandozeile ohne Escaping Dateiname, Username und Passwort!!!

[x] gefixt. Danke!

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Jonathan]

Hallo fastix®,

[x] gefixt. Danke!

Sieht mir immer noch nicht vertrauenswürdig aus.

system('htpasswd2 -b "'.MyShellEscape($config['userfile']).'" "'.MyShellEscape($user).'" "'.MyShellEscape($pass).'"', $error);

Was passiert den, wenn ich als user »peter\« und als passwort »&& shutdown now && « oder ähnliches angebe?

Was kommt raus?

htpasswd2 -b userfile "peter\" "&& shutdown now && "

Blöd, was? Ich meine, ich habe jetzt nicht getestet, ob das wirklich so funktioniert, vo allem mit dem überflüssigen Anführungszeichen hinten, aber es sieht schon sehr gefährlich aus.

Du musst z.B. verhindern, dass man selbst Backslashes einbaut um deine Backslashes zu escapen, welche die Anführungszeichen escapen sollen.

Jonathan

[fastix®]

Moin!

Was passiert den, wenn ich als user »peter\« und als passwort »&& shutdown now && « oder ähnliches angebe?

Was kommt raus?

htpasswd2 -b userfile "peter\" "&& shutdown now && "

Blöd, was?

Nein. Das kann nicht rauskommen. Ich habe nach dem Hinweis noch mal nachgesehen und was nachgebessert.

Innerhalb des in quotas übergeben Strings kann, muss und darf ich nur das Quotierungszeichen selbst (hier: ") und den Backslash maskieren. Sonst verändere ich das Passwort. Das Problem bei den vorgefertigten Funktionen ist die Dokumentation:

Zitat:
"escapeshellarg() fügt einfache Anführungszeichen um eine Zeichenkette herum ein und maskiert alle existierenden einfachen Anführungszeichen innerhalb der Zeichenkette"

... stimmt schon mal unter Windows nicht und hilft einen Dr... wenn ein freundlicher Benutzer ein wenig "mitescapt". Da ist ja meine (aktuelle) Version sicherer...

htpasswd2 -b ".htpasswd\"" "peter" "&& shutdown now &&"

kommt raus. Dieser Punkt ist jetzt safe.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Dennis]

Hi fastix®,

[x] gefixt. Danke!

„MyShellEscape()” - Autsch.

Abgesehen davon, dass deine Escape-Funktion jede Menge an Eventualitäten nicht berücksichtigt (Jonathan sprach das ja bereits an), wofür bringt PHP bitte schön eine Funktion escapeshellarg() mit?

Weiteres Problem: Unter SuSE hast du Glück, htpasswd2 existiert, liegt in /usr/bin und somit im Bereich von $PATH.
Unter Debian und Unbuntu sieht das anders aus, dort heißt das Tool (ja, auch bei Apache 2) htpasswd und wird somit von deinem Programm nicht gefunden.
Ich meine mich zu entsinnen, dass wenn man Apache selbst kompiliert zudem htpasswd standardmäßig in /usr/sbin landet und somit für einen normalen User nicht im Bereich von $PATH enthalten ist.

Warum willst du überhaupt htpasswd verwenden? Wie Sven bereits sagte, solltest du die Passwörter grundsätzlich erst mal auf MD5-Basis haschen, da diese Hashs sowohl unter Windows, wie auch unter Unix funktionieren (htpasswd -m ist dein Freund).
Da du die Benutzer ja sowieso manuell, also mit Lese- und Schreibbefehlen von PHP löschst, anstatt mit htpasswd, würde ich in diesem Fall dazu tendieren, die Benutzer auch mit reinem PHP anzulegen, wodurch du nicht vom von der Verfügbarkeit von htpasswd abhängig bist.
Eine entsprechende Funktion zum MD5-Hash für den Apache findest du hier.

Viele Grüße,
  ~ Dennis.

[Sven Rautenberg]

Moin!

[x] gefixt. Danke!

„MyShellEscape()” - Autsch.

Doppel-Autsch...

Abgesehen davon, dass deine Escape-Funktion jede Menge an Eventualitäten nicht berücksichtigt (Jonathan sprach das ja bereits an), wofür bringt PHP bitte schön eine Funktion escapeshellarg() mit?

Was mir an dem ganzen Skript absolut nicht gefällt, sind die diversen beiläufigen System-Shell-Aufrufe, die an den verschiedendsten Orten eingestreut werden, ohne sofort ins Auge zu fallen.

Dabei halte ich es insbesondere für problematisch, dass es gar keine Regelmäßigkeit gibt, ob für eine Aktion jetzt nur PHP-Mittel benutzt werden, oder ob ein externes Shell-Kommando zum Einsatz kommt. Mal ist es so, mal ist es anders.

Und wenn dann die Shell bemüht wird, um irgendeine Trivialität zu erledigen, mangelt es notorisch immer wieder am Escaping! Dabei ist es aus meiner Sicht absolut unerheblich, ob die jeweils benutzten Variablen eigentlich statische und vernünftige Werte enthalten - Fakt ist, dass sie dies nicht zwingend in jeder Situation tun müssen, und dass es vom Sicherheitsapekt her eine extrem schlechte Idee ist, in einer konkreten Programmzeile eine potentielle Sicherheitslücke offen zu lassen mit dem Argument, dass man eben anderswo, wo der Aufruf dieser Sicherheitslücke gestartet wird, ganz besonders aufpasst, dass auch nichts passiert.

Resultat: Anstatt an genau einer Stelle aufzupassen und Gegenmaßnahmen zu ergreifen, vervielfältigt man das Problem, indem man jetzt an jeder Stelle, die die Funktion aufruft, aufpassen und Gegenmaßnahmen ergreifen muss. Das ist allein schon vom Effektivitätsgedanken her Unsinn, kein Programmierer schreibt Code zweimal, wenn er ihn nur einmal schreiben muss. Von der unweigerlichen Gefahr, das Aufpassen an einer entscheidenden Stelle doch einmal vergessen zu können, ganz abgesehen.

Im Einzelnen:

if (! file_exists($config['userfile'])) {  
 system("touch ".$config['userfile']);  
}  
  
if (! file_exists($config['htaccessfile'])) {  
 system("touch ".$config['htaccessfile']);  
}

http://de.php.net/touch

$users=trim(cut -d: -f1 $userfile);
http://de.php.net/file_get_contents + explode + explode + Arraybearbeitung

Weiteres Problem: Unter SuSE hast du Glück, htpasswd2 existiert, liegt in /usr/bin und somit im Bereich von $PATH.
Unter Debian und Unbuntu sieht das anders aus, dort heißt das Tool (ja, auch bei Apache 2) htpasswd und wird somit von deinem Programm nicht gefunden.
Ich meine mich zu entsinnen, dass wenn man Apache selbst kompiliert zudem htpasswd standardmäßig in /usr/sbin landet und somit für einen normalen User nicht im Bereich von $PATH enthalten ist.

Auf meinem Gentoo-System existiert nur /usr/sbin/htpasswd, und ein Link /usr/sbin/htpasswd2 auf dieses Programm.

Warum willst du überhaupt htpasswd verwenden? Wie Sven bereits sagte, solltest du die Passwörter grundsätzlich erst mal auf MD5-Basis haschen, da diese Hashs sowohl unter Windows, wie auch unter Unix funktionieren (htpasswd -m ist dein Freund).

Ich habe keine grundsätzlichen Einwände, zur Erreichung rascher Ergebnisse genau die Tools einzusetzen, die dafür geschaffen wurden, rasche Ergebnisse zu erzielen.

Das Problem ist nur, dass es sachgemäß passieren muss. Kommandozeilentools in der Hand eines fähigen Admins sind eine gute Sache. Integriert in ein Webskript aber erhalten sie potentiellen Kontakt zu einer großen Welt des Bösen - also muss man hier extreme Vorsicht walten lassen.

htpasswd ist halt das ideale Tool, um schnell und ohne Umwege Useraccounts in einer .htpasswd-Datei zu managen. Nur: Wenn ich dieses Tool nutze, dann auch zu 100% für alle Funktionen, und natürlich entsprechend abgesichert.

Da du die Benutzer ja sowieso manuell, also mit Lese- und Schreibbefehlen von PHP löschst, anstatt mit htpasswd, würde ich in diesem Fall dazu tendieren, die Benutzer auch mit reinem PHP anzulegen, wodurch du nicht vom von der Verfügbarkeit von htpasswd abhängig bist.

Das ist sicherlich eine sehr gute Idee. Viele Shared-Hosting-Accounts verbieten den Zugriff auf Funktionen wie system(), um genau solche Probleme mit Skripten zu verhindern, wie hier in der ersten Version zu sehen war.

Eine entsprechende Funktion zum MD5-Hash für den Apache findest du hier.

Das Problem ist halt: Solch eine Funktion muss man entweder aufwendig selbst schreiben, oder in den Weiten des Webs ausfindig machen.

Auf der anderen Seite: Solch eine Aufgabe ist schon so uralt und hat schon so viele Admins geärgert, dass es extrem unwahrscheinlich ist, dass da noch niemand was erstellt hat. Und tatsächlich: Da gibts auch was von PEARiopharm! - dummerweise nur zum Handling des .htaccess-Files, nicht für .htpasswd. Was mich zu dem Schluss kommen läßt, dass entweder der Bedarf doch nicht so riesig ist, weil für größeren Bedarf kein .htpasswd eingesetzt wird, sondern z.B. mod_access_mysql mit Datenbankanbindung (und wie man die DB mit PHP nutzt, ist bekannt), und für den kleinen Bedarf anscheinend der Shell-Aufruf von htpasswd ausreicht.

- Sven Rautenberg

[fastix®]

Moin!

Was mir an dem ganzen Skript absolut nicht gefällt, sind die diversen beiläufigen System-Shell-Aufrufe, die an den verschiedendsten Orten eingestreut werden, ohne sofort ins Auge zu fallen.

Dabei halte ich es insbesondere für problematisch, dass es gar keine Regelmäßigkeit gibt, ob für eine Aktion jetzt nur PHP-Mittel benutzt werden, oder ob ein externes Shell-Kommando zum Einsatz kommt. Mal ist es so, mal ist es anders.

Das war dem schnellen Ergebnis geschuldet.

Und wenn dann die Shell bemüht wird, um irgendeine Trivialität zu erledigen, mangelt es notorisch immer wieder am Escaping!Dabei ist es aus meiner Sicht absolut unerheblich, ob die jeweils benutzten Variablen eigentlich statische und vernünftige Werte enthalten -

Du meinst, ich sollte auch quasi fest verdrahtete Werte escapen?

Fakt ist, dass sie dies nicht zwingend in jeder Situation tun müssen, und dass es vom Sicherheitsapekt her eine extrem schlechte Idee ist, in einer konkreten Programmzeile eine potentielle Sicherheitslücke offen zu lassen mit dem Argument, dass man eben anderswo, wo der Aufruf dieser Sicherheitslücke gestartet wird, ganz besonders aufpasst, dass auch nichts passiert.

Na, ich weiss nicht: Ich habe das ja nicht als bibliothek geschrieben um den Code an anderer Stelle weiterzuverwerten.

Resultat: Anstatt an genau einer Stelle aufzupassen und Gegenmaßnahmen zu ergreifen, vervielfältigt man das Problem, indem man jetzt an jeder Stelle, die die Funktion aufruft, aufpassen und Gegenmaßnahmen ergreifen muss.

http://de.php.net/touch

gute idee.

$users=trim(cut -d: -f1 $userfile);
http://de.php.net/file_get_contents + explode + explode + Arraybearbeitung

wenn schon file +trim +explode

Auf der anderen Seite: Solch eine Aufgabe ist schon so uralt und hat schon so viele Admins geärgert, dass es extrem unwahrscheinlich ist, dass da noch niemand was erstellt hat.

Wer pear verwenden kann (und darf), der hat mit dem Rest erst recht kein Problem.

Und tatsächlich: Da gibts auch was von PEARiopharm! - dummerweise nur zum Handling des .htaccess-Files, nicht für .htpasswd.

Du sagst es. Löst nur ein Teilproblem.

Was mich zu dem Schluss kommen läßt, dass entweder der Bedarf doch nicht so riesig ist, weil für größeren Bedarf kein .htpasswd eingesetzt wird, sondern z.B. mod_access_mysql mit Datenbankanbindung (und wie man die DB mit PHP nutzt, ist bekannt), und für den kleinen Bedarf anscheinend der Shell-Aufruf von htpasswd ausreicht.

Und was ist mit dem Bedarf der vielen kleinen Website-Betreiber, die ihre 3-15 Benutzer von geschützten Verzeichnissen verwalten wollen? Die müsste jedesmal die Dienste von fremden Webseiten in Anspruch nehmen, wissen auch nicht, ob es funktioniert...

Ich werde mir dennoch die md5-Lösung mal anschauen, dass auf vielen hosts die system-Aufrufe gecancelt werden ist ein nicht zu schlagendes Argument, vor allem hinsichtlich der Zielgruppe.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Sven Rautenberg]

Moin!

Und wenn dann die Shell bemüht wird, um irgendeine Trivialität zu erledigen, mangelt es notorisch immer wieder am Escaping!Dabei ist es aus meiner Sicht absolut unerheblich, ob die jeweils benutzten Variablen eigentlich statische und vernünftige Werte enthalten -

Du meinst, ich sollte auch quasi fest verdrahtete Werte escapen?

Besteht die Möglichkeit, dass der Anwender aus irgendeinem Grund beispielsweise ein Leerzeichen in den Konfigurationswert einträgt? Ja. Also...

Es geht dabei weniger um die Tatsache, dass diese Möglichkeit unwahrscheinlich ist (wobei Leerzeichen in Pfadnamen gerade unter Windows ja nicht unwahrscheinlich sind), sondern darum, dass es im Sinne des Sicherheits-Audits darum geht, potentielle Schwachstellen erst gar nicht entstehen zu lassen.

Wenn man sich den Quellcode durchliest, dann will man in jeder Zeile - für sich genommen - sehen, dass für die Sicherheit alles getan wurde. Bestenfalls guckt man noch in die Zeilen unmittelbar drumherum - obwohl das schon suboptimal ist. Ganz blöd ist es, wenn man sich bei Betrachtung der Zeile erst Gedanken machen muss, welche Werte denn potentiell in der Variablen stehen könnten, und wo man sehen kann, wie sie dorthin gelangen.

Fakt ist, dass sie dies nicht zwingend in jeder Situation tun müssen, und dass es vom Sicherheitsapekt her eine extrem schlechte Idee ist, in einer konkreten Programmzeile eine potentielle Sicherheitslücke offen zu lassen mit dem Argument, dass man eben anderswo, wo der Aufruf dieser Sicherheitslücke gestartet wird, ganz besonders aufpasst, dass auch nichts passiert.

Na, ich weiss nicht: Ich habe das ja nicht als bibliothek geschrieben um den Code an anderer Stelle weiterzuverwerten.

Das ist doch aber irrelevant. Dein Code steht jetzt erstmal im Internet und ist hier verlinkt, also ist anzunehmen, dass die Funktionen eventuell doch mal isoliert Verwendung finden, ohne diese Sicherheitsüberlegungen.

- Sven Rautenberg

[fastix®]

Moin!

Na, ich weiss nicht: Ich habe das ja nicht als bibliothek geschrieben um den Code an anderer Stelle weiterzuverwerten.

Das ist doch aber irrelevant. Dein Code steht jetzt erstmal im Internet und ist hier verlinkt, also ist anzunehmen, dass die Funktionen eventuell doch mal isoliert Verwendung finden, ohne diese Sicherheitsüberlegungen.

Da sollte es aktuell nicht auszusetzen geben. Beim Aufruf werden die Parameter von htpasswd2 einzeln in Quotas gepackt und diese zuvor "escapt".

Die Systemaufrufe bis auf den von htpasswd habe durch die php-Derivate ersetzt.

Eine Version mit den Funktionen von Dennis Riehle habe ich auch fertig und die läuft auch nachdem ich eine kitzekleine Anpassung vorgenommen habe. Ich habe aber die Funktionen von Dennis Riehle (mit ergänztem Kommentar) nicht als externe Bibliothek includiert, sondern in den Funktionsbereich übernommen.

Jetzt braucht es wohl die Erlaubnis von Dennis um das zu veröffentlichen.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Dennis]

Hi fastix®,

Jetzt braucht es wohl die Erlaubnis von Dennis um das zu veröffentlichen.

Steht in der md5crypt.lib.php doch eigentlich drin, dass das unter der Beer-Ware License läuft (da auch das Original, welches ich in PHP übersetzt habe darunter stand).
Aber ich habe dir auch grade noch mal deine E-Mail beantwortet…

Viele Grüße,
  ~ Dennis.

[fastix®]

Moin!

Hi fastix®,

[x] gefixt. Danke!

„MyShellEscape()” - Autsch.

Abgesehen davon, dass deine Escape-Funktion jede Menge an Eventualitäten nicht berücksichtigt (Jonathan sprach das ja bereits an), wofür bringt PHP bitte schön eine Funktion escapeshellarg() mit?

Das Problem bei den vorgefertigten Funktionen ist die Dokumentation:

Zitat:
"escapeshellarg() fügt einfache Anführungszeichen um eine Zeichenkette herum ein und maskiert alle existierenden einfachen Anführungszeichen innerhalb der Zeichenkette"

"escapeshellarg() adds single quotes around a string and quotes/escapes any existing single quotes allowing you to pass a string directly to a shell function and having it be treated as a single safe argument."

Wenn die Dokumentation stimmt, dann nützt mir das nichts. Was ist mit Maskierungszeichen?

Weiteres Problem: Unter SuSE hast du Glück, htpasswd2 existiert, liegt in /usr/bin und somit im Bereich von $PATH.

Unter Debian und Unbuntu ... [Red Hat, selbst kompiliert]

...

[x] gefixt: Das Binary lässt sich jetzt in der Konfiguration eintragen.

[x] Ich werde mir dennoch mal das von Dennis verlinkte Skript anschauen.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[fastix®]

Moin!

Eine entsprechende Funktion zum MD5-Hash für den Apache findest du hier.

Viele Grüße,
  ~ Dennis.

Ich habe eine Version ohne Systemaufrufe und mit Deiner(?) md5crypt-1.0.lib - allerdings musste ich zwei Zeilen anpassen, weil "global $itoa64;" bei es mir nicht "tut". Die Zeilen 54 und 70 übrigens. (Der Grund für die unendliche Schleife war schnell gefunden...)

php -v liefert bei mir:
(PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 21 2008 17:53:26)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies)

Die Unsicherheiten aus der 'normalen' Version sind raus.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[fastix®]

Moin!

In der viele unlogische Dinge passieren.

Nun ja... erster Versuch.

Weil du nicht MD5 zum Passworthashen benutzt.

hm. Da hat er mich nicht reingelassen... das habe ich für später vorgesehen, da muss ich noch was nachschauen. (Salt?)

Außerdem unlogisch: Für das Hinzufügen des neuen Users benutzt du einen Systemaufruf von
htpasswd2, zum Löschen und alle andere Aufgaben benutzt du es nicht.

siehe oben. Das ist quasi die Vorbereitung.

Sicherheitslücke: Du übergibst der Kommandozeile ohne Escaping Dateiname, Username und Passwort!!!

[x]gefixt. Allerdings ist der Dateiname "hart codiert", keine Benutzereingabe im eigentlichen Sinn.

Unschönheit: Deine Funktionsnamen fangen mal mit großen, mal mit kleinen Buchstaben an.

[x]gefixt.

Unschönheit 2: Deine Funktionen sitzen unlogisch platziert zwischen Hauptprogramm und Ausgabe.

Die habe ich normalerweise in einem Include. Seit in php die Funktionen auch unten stehen können sind die mir dort lieber. Ich progge eigentlich immer so. Programm - Routinen - Ausgabe.

Unschönheit 3: getDirName() geht auch viel einfacher: return dirname($_SERVER['SCRIPT_FILENAME']);

[x]gefixt.

Unschönheit 4: Indem das Skript selbst die Dateien .htacess und .htpasswd anlegt, werden diese bei vielen Providern nicht mehr per FTP zugänglich sein, Kopieren oder Löschen funktioniert dann nicht. Das ist durchaus sehr dramatisch!

Die Alternative wäre dem Benutzer anzuzeigen, dass diese nicht existieren. In der Konsequenz ist das aber auch unschön und nicht komfortabel. Diese werden übrigens auch nur angelegt, wenn die nicht existieren.

Zudem: hängen die Rechte, eine Datei zu löschen oder umzubenennen nicht an den Rechten des Verzeichnisses, in dem diese ist? Das heißt: die so angelegten Dateien sollten auch per FTP-löschbar sein.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[fastix®]

Moin!

Erst einmal: Dank allen Helfern!

Die soweit bereinigte, auch auf Linux/Unix/BSD/Windows-Kisten und auch ohne das Recht, Systembefehle auszuführen, funktionierende Version findet sich hier:
http://www.fastix.de/r/htpasswd2.txt

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®