nicht angemeldet
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
"Love your nation - respect the others."