nicht angemeldet
Passwortschutz aus der Ferne?
Liebe Forumer,
das Thema "wie kann ich Seiten vor Zugriffen mit Passwort schuetzen" ist ja fast so alt (aber nur fast *g*) wie der Homepage-Bau. Nun sind es ja meistens diejenigen, die danach fragen, die keine ordentlichen Webhostingangebote nutzen und von ihrem Provider z.B. kein Web-Interface fuer htaccess-Schutz angeboten bekommen. Fuer solche Leute gibt es nun http://www.kennwortschutz.de/.
Und das geht so: in den HTML-Code einer eigenen Seite, die man schuetzen will, soll man etwas in dieser Art eingeben:
<script src="http://www.filz.net/kws/gate.php?ID=1"></script>
(nur ein Beispiel, funktioniert in dieser Form nicht)
Kurzum: ein PHP-Script auf einem fremden Server wird aufgerufen, und dieses Script managt die Authentifizierung.
Mich wuerde interessieren, ob jemand Erfahrung damit gemacht hat und das als ordentliche Web-Service-Loesung empfehlen kann, die zumindest mal einen Link im Linkverzeichnis verdient haette.
viele Gruesse
Stefan Muenz
-
Liebe Forumer,
Mich wuerde interessieren, ob jemand Erfahrung damit gemacht hat und das als ordentliche Web-Service-Loesung empfehlen kann, die zumindest mal einen Link im Linkverzeichnis verdient haette.
Die erste Erfahrung ist die, dass man mit Netscape 4.79 (Linux) die angegebene Adresse gar nicht ansurfen kann.
Bis auf den oberen Balken ist nichts zu sehen. Erst wenn ich Javascript deaktivere, sehe ich den übrigen Text.
Aber dann sehe ich nirgendwo ein Textfeld, wo ich den angebotenen Passwortschutz-Test durchführen kann.Mein Fazit: ein klarer Fall von unzulänglich getesteter HTML-Seite. Wie sollte es da mit PHP-Scripts besser sein?
Forget it!Ciao
Wolfgang Pichler
-
Hallo Stefan,
Und das geht so: in den HTML-Code einer eigenen Seite, die man schuetzen will, soll man etwas in dieser Art eingeben:
<script src="http://www.filz.net/kws/gate.php?ID=1"></script>Mich wuerde interessieren, ob jemand Erfahrung damit gemacht hat und das als ordentliche Web-Service-Loesung empfehlen kann, die zumindest mal einen Link im Linkverzeichnis verdient haette.
das war doch keine ernsthafte frage?!
passwortschurz durch <scrip> ???
*lol*grüße
Thomas
na dann mal die seite ohne aktivierte scripting:
<img src="http://www.meta-text.net/etc/nixmitschutz.gif" border=0 alt=""> -
Hallo Stefan,
das Thema "wie kann ich Seiten vor Zugriffen mit Passwort schuetzen" ist ja fast so alt (aber nur fast *g*) wie der Homepage-Bau. Nun sind es ja meistens diejenigen, die danach fragen, die keine ordentlichen Webhostingangebote nutzen und von ihrem Provider z.B. kein Web-Interface fuer htaccess-Schutz angeboten bekommen. Fuer solche Leute gibt es nun http://www.kennwortschutz.de/.
sollte es nicht besser www.seitenverstecken.de heißen?
Und das geht so: in den HTML-Code einer eigenen Seite, die man schuetzen will, soll man etwas in dieser Art eingeben:
<script src="http://www.filz.net/kws/gate.php?ID=1"></script>
(nur ein Beispiel, funktioniert in dieser Form nicht)toller Schutz, die Demo ausprobiert, ohne JavaScript läuft da nix
und Seiten verstecken kann ich auch ohne einen externen Anbieter:
http://www.filz.net/kws/anleitung.htm (die soll "geschützt" sein)Viele Grüße,
Stefan-
Hi,
bei mir funktioniert die Seite schon, aber wie Stefan schon sagte:
toller Schutz, die Demo ausprobiert, ohne JavaScript läuft da nix
und Seiten verstecken kann ich auch ohne einen externen Anbieter:
http://www.filz.net/kws/anleitung.htm (die soll "geschützt" sein)Jetzt schaut euch mal die geschützte Seite an! http://www.filz.net/kws/anleitung.htm
Links oben:"Das war es schon . . .
So funktioniert _Konnwortschutz.de_ aus der Sicht der Besucher Ihrer Seite.
Einfach das Login und Kennwort eingeben, OK drücken und Sie befinden sich auf der geschützten Seite."Die können nichtmal ihre eigene URL richtig schreiben! :)
Naja, Fazit: Gute Idee, schlechte Umsetztung ...
MfG Thomas B
-
Hallo Thomas,
Naja, Fazit: Gute Idee, schlechte Umsetztung ...
entschuldige meine Nachfrage, aber was genau ist hier eine gute Idee?
Die Sache ist genauso sinnvoll, wie der sogenannte "Passwortschutz"
per JavaScript. Ob ich jemand eine e-Mail schicken, mit dem Inhalt:"Bitte gehe auf meine Website http://domain.xy/ und logge Dich mit
dem Namen 'Gast' und dem Passwort 'geheim' ein."ist praktisch genauso sicher wie:
"Bitte besuche http://domain.xy/schwerzuerraten.html und gib diese
Adresse niemand weiter, danke."Der Vorteil der zweiten Variante ist, dass man sich bewußt ist, dass
kein *Schutz* existiert und man sich unnötige Arbeit für die Scripte
(oder gar Anmeldung bei www.kennwortschutz.de *lol*) spart ;-)Viele Grüße,
StefanPS: Schutz sind Sachen wie .htaccess o.ä..
-
Hallo Stefan
Naja, Fazit: Gute Idee, schlechte Umsetztung ...
entschuldige meine Nachfrage, aber was genau ist hier eine gute Idee?
Ich meine die gute Idee, den Leuten die keine Möglichkeit haben ihre Seiten per .htaccess zu schützen, eine Alternative zu geben. Leider, wie man sieht ist es nicht einfach!
MfG zurück Thomas B
-
Hi Stefan
PS: Schutz sind Sachen wie .htaccess o.ä..
Leider hat mir noch keiner erklärt welchen Vorteil htaccess gegenüber der
schwerzuerraten.html-Variante bietet, beide male läuft es auf
bruteforceangriffe hinaus!Oder?
Bye
Rolf-
Hallo Rolf,
Leider hat mir noch keiner erklärt welchen Vorteil htaccess gegenüber der
schwerzuerraten.html-Variante bietet, beide male läuft es auf
bruteforceangriffe hinaus!.htaccess:
Der Benutzername und das Passwort müssen ermittelt werden.
Der Benutzername steht in den Logfiles.
Die Seite ist nicht aufrufbar, selbst von der URL bekannt ist.
Die Kombination von Benutzername und Passwort macht es auch dem
unerfahrenen Nutzer ersichtlich, dass man diese Angaben nicht ein-
fach so weitergeben sollte.
... einige Dinge mehrschwerzuerraten.html
Es muß nur der URL erraten werden, u.U. helfen Referrer, Telnet o.ä.
dabei. Es kann nicht nachvollzogen werden, ob ein bestimmter Nutzer
aussergewöhnlich oft auf die geschützten Dateien zugegriffen hat.
Die Weitergabe der URL ist, besonders bei größeren Personenkreisen,
nicht kontrollierbar.
... einige Dinge mehrInsgesamt spricht nicht viel dagegen, bei einem kleinen Personen-
kreis (wenige Leute) die Methode schwerzuerraten.html zu verwenden,
besonders wenn es sich um einen eng begrenzten Zeitraum und keine
hochsensiblen Daten handelt.Viele Grüße,
Stefan-
Hi,
.htaccess:
Der Benutzername steht in den Logfiles.Insbesondere:
Ein gescheiterter Zugriff ist ein dem Webserver begreifliches Ereignis.So, wie man eine Error-404-Seite definieren kann, kann man auch eine
Error-403-Seite definieren. Und die kann ein CGI-Skript sein.
Das heißt, man kann als "Verteidiger" auf den "Angriff" gezielt reagieren.
Man kann beispielsweise die IP-Adresse eines "penetranten" Angreifers auf
eine Schwarze Liste setzen und die nächsten <n> Zugriffe automatisch ab-
weisen, selbst wenn er das Passwort erraten hat. Gegen eine solche Ver-
teidigung würde ein einfaches brute force schon nicht mehr durchkommen!Ein schwerzuerraten.html nicht zu finden ist dagegen ein normales 404-
Ereignis. Der Server hat kaum eine Chance, dies als "böswillig" zu ver-
stehen, ohne zahlreichen "gutwilligen" Besuchern unnötigerweise eins
"reinzuwürgen".Es muß nur der URL erraten werden, u.U. helfen Referrer, Telnet o.ä.
dabei.Oder sonstige Protokolle eines auf dem Weg befindlichen Proxy-Servers.
Wobei insbesondere das eigentliche Passwort bei Server Authentication
inzwischen auch verschlüsselt geschickt werden kann.Es kann nicht nachvollzogen werden, ob ein bestimmter Nutzer
aussergewöhnlich oft auf die geschützten Dateien zugegriffen hat.Gff. schon - durch Analyse des Access-Log (IP-Adresse).
Der Unterschied ist, daß der 403-handler sofort eingreifen kann; wenn
der Server-Admin sein Logfile prüft, ist es vielleicht schon zu spät.Viele Grüße
Michael-
Hi Stefan & Michael
Vielen Dank für die Antworten, hab einiges dazugelernt :)
... aber ich will nochmal systematisch nachfragen:.htaccess:
Der Benutzername und das Passwort müssen ermittelt werden.Naja beim anderen auch, wenn du User+Passwd.html machst (evtl. mit JS)
Der Benutzername steht in den Logfiles.
Oder in "schwerzuerraten.html" (s.o.)
Die Seite ist nicht aufrufbar, selbst von der URL bekannt ist.
???
Die Kombination von Benutzername und Passwort macht es auch dem
unerfahrenen Nutzer ersichtlich, dass man diese Angaben nicht ein-
fach so weitergeben sollte.OK, Sicherheitspsychologie! Ließe sich mit JS auch erreichen, aber andere
Diskussion...schwerzuerraten.html
Es muß nur der URL erraten werden, u.U. helfen Referrer, Telnet o.ä.
dabei.Ui Referrer ist natürlcih ne häßliche Sache, da müßte man also ein
"logout.html" dazwischenschalten.Es kann nicht nachvollzogen werden, ob ein bestimmter Nutzer
aussergewöhnlich oft auf die geschützten Dateien zugegriffen hat.Sollte ich das können? Mancher Nutzer würde sowas begrüßen (Datenschutz)!
Die Weitergabe der URL ist, besonders bei größeren Personenkreisen,
nicht kontrollierbar.Zugegeben es ist einfacher eine URL weiterzumailen als noch User und Passwd
mitzugeben.Mann könnte aber (verzeiht meine Fantasie) per JS aus User+Passwd+Datum
und MD5 jeweils eine URL generieren die sich halt jeden Tag ändern müßte...
:) (Hoffend dass es keine Kollisionen gibt *fg*)Insbesondere:
Ein gescheiterter Zugriff ist ein dem Webserver begreifliches Ereignis.So, wie man eine Error-404-Seite definieren kann, kann man auch eine
Error-403-Seite definieren. Und die kann ein CGI-Skript sein.Gutes Argument, dass geht nicht mit JS reparieren.
Das heißt, man kann als "Verteidiger" auf den "Angriff" gezielt reagieren.
Man kann beispielsweise die IP-Adresse eines "penetranten" Angreifers auf
eine Schwarze Liste setzen und die nächsten <n> Zugriffe automatisch ab-
weisen, selbst wenn er das Passwort erraten hat. Gegen eine solche Ver-
teidigung würde ein einfaches brute force schon nicht mehr durchkommen!Bringts das? Der Angreifer müßte so intelligent sein neue IP's zu faken.
Auch bei Schwerzuerraten.html kann ich in die Logfiles schauen, und wenn
10000 mal mehr Zugriffe als normal stattfinden kann ichs mir denken!Also wenn schwer dann richtig schwer!!!
Ein schwerzuerraten.html nicht zu finden ist dagegen ein normales 404-
Ereignis. Der Server hat kaum eine Chance, dies als "böswillig" zu ver-
stehen, ohne zahlreichen "gutwilligen" Besuchern unnötigerweise eins
"reinzuwürgen".s.o.
Es muß nur der URL erraten werden, u.U. helfen Referrer, Telnet o.ä.
dabei.Wieso Telnet??? Das Directory sollte schon nicht lesbar sein!
Oder sonstige Protokolle eines auf dem Weg befindlichen Proxy-Servers.
Wobei insbesondere das eigentliche Passwort bei Server Authentication
inzwischen auch verschlüsselt geschickt werden kann.Hmm, wie kann ich die Passwortverschlüsselung erzwingen? Ich schau lieber
gleich mal in die Feature-Artikel von diesem Schröpl ;)Es kann nicht nachvollzogen werden, ob ein bestimmter Nutzer
aussergewöhnlich oft auf die geschützten Dateien zugegriffen hat.Gff. schon - durch Analyse des Access-Log (IP-Adresse).
Der Unterschied ist, daß der 403-handler sofort eingreifen kann; wenn
der Server-Admin sein Logfile prüft, ist es vielleicht schon zu spät.403 ist natürlich schöner als 404, aber haben normale Provider-Kunden
denn Zugriff auf die Handler?Viele Grüße
Rolf-
Hi Rolf,
Die Seite ist nicht aufrufbar, selbst von der URL bekannt ist.
???s/von/wenn/
Es nützt nichts, wenn Du jemandem über die Schulter schaust oder seine
Bookmarks liest.Das heißt, man kann als "Verteidiger" auf den "Angriff" gezielt reagieren.
Man kann beispielsweise die IP-Adresse eines "penetranten" Angreifers auf
eine Schwarze Liste setzen und die nächsten <n> Zugriffe automatisch ab-
weisen, selbst wenn er das Passwort erraten hat. Gegen eine solche Ver-
teidigung würde ein einfaches brute force schon nicht mehr durchkommen!
Bringts das? Der Angreifer müßte so intelligent sein neue IP's zu faken.Er müßte auf die Idee kommen, mit einer solchen Verteidigung zu rechnen!
Wer tut das? Der normalen 404-Meldung kannst Du nicht ansehen, ob mein CGI-
Skript sie zu recht oder zu unrecht schickt.Auch bei Schwerzuerraten.html kann ich in die Logfiles schauen, und wenn
10000 mal mehr Zugriffe als normal stattfinden kann ichs mir denken!Ja. Du siehst dann, daß jemand eingebrochen ist. Aber das ist dann zu spät.
Es muß nur der URL erraten werden, u.U. helfen Referrer, Telnet o.ä.
dabei.
Wieso Telnet??? Das Directory sollte schon nicht lesbar sein!Alles mögliche sollte nicht lesbar sein. Auch Dein access_log nicht, in
welchem der Name der URLs drin steht, die ServerAuthentication aber nicht.Oder sonstige Protokolle eines auf dem Weg befindlichen Proxy-Servers.
Wobei insbesondere das eigentliche Passwort bei Server Authentication
inzwischen auch verschlüsselt geschickt werden kann.
Hmm, wie kann ich die Passwortverschlüsselung erzwingen? Ich schau lieber
gleich mal in die Feature-Artikel von diesem Schröpl ;)Nicht, solange kein Netscape-Browser das versteht.
Wenn einer rauskommt, der das kann, werde ich den Artikel wohl anpassen
müssen.Es kann nicht nachvollzogen werden, ob ein bestimmter Nutzer
aussergewöhnlich oft auf die geschützten Dateien zugegriffen hat.
Gff. schon - durch Analyse des Access-Log (IP-Adresse).Ja, aber zu spät (siehe oben).
Der Unterschied ist, daß der 403-handler sofort eingreifen kann; wenn
der Server-Admin sein Logfile prüft, ist es vielleicht schon zu spät.
403 ist natürlich schöner als 404, aber haben normale Provider-Kunden
denn Zugriff auf die Handler?Sie brauchen dafür nur ein AllowOverride in der .htaccess - genau wie für
die ServerAuthentication auch.Viele Grüße
Michael-
Hi Michael
Er müßte auf die Idee kommen, mit einer solchen Verteidigung zu rechnen!
Wer tut das? Der normalen 404-Meldung kannst Du nicht ansehen, ob mein CGI-
Skript sie zu recht oder zu unrecht schickt.Ach so, du meinst der angreifer kann nicht unterscheiden ob er wegen des falschen Passwortes oder
wg. einer Blockade abgewiesen wird und macht seinen
BruteForceAngriff bis in alle Ewigkeit weiter?Viele Grüße
Rolf-
Hi Rolf,
Der normalen 404-Meldung kannst Du nicht ansehen, ob mein CGI-
Skript sie zu recht oder zu unrecht schickt.
Ach so, du meinst der angreifer kann nicht unterscheiden ob er
wegen des falschen Passwortes oder wg. einer Blockade abgewiesen
wird und macht seinen BruteForceAngriff bis in alle Ewigkeit weiter?genau das.
Der Angreifer hat nämlich ein Problem: Er kann sich nicht darauf ver-
lassen, das Kennwort herauszubekommen, indem er alle Möglichkeiten
ausprobiert.Wenn sein Angriff beispielsweise vier Wochen dauert, dann kann sich
das Kennwort zwischendurch geändert haben. Und wenn es sich von einem
noch nicht probierten in einen bereits probierten Wert ändert, dann
wird der Angreifer in diesem Durchgang keinen Erfolg mehr haben.Viele Grüße
Michael
-
-
-
-
-
-
-
-
-