LanX: Passwortschutz aus der Ferne?

Beitrag lesen

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