nicht angemeldet
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.