Mit wenigen Klicks eben Let's Encrypt auf meinem Webspace aktiviert. Schön mit SSL-Zwang und das Zertifikat ist auch nicht der letzte Rotz. Für mein Wiki reicht das locker.
Kostenpunkt: 0 EUR
Mein Anbieter: all-inkl.com
Mit wenigen Klicks eben Let's Encrypt auf meinem Webspace aktiviert. Schön mit SSL-Zwang und das Zertifikat ist auch nicht der letzte Rotz. Für mein Wiki reicht das locker.
Kostenpunkt: 0 EUR
Mein Anbieter: all-inkl.com
Is halt immer die Frage, wie es mit dem Support is. Ich hab mir Let's Encrypt natürlich auch schon überlegt. Aber wahrscheinlich müßte ich die Updatescripte massiv patchen/portieren, damit sie auf meinem *hust* Windows 2000 laufen. Ich mein, modernes Perl wär ja da... so isses ned.
Aber bisher hat mich schlicht und einfach der Aufwand davon abgehalten. Und modernes SSL/TLS kann ich sowieso ned. Mein feuchter Wunschtraum, die WAMPS Kette selbst für 2k zu kompilieren (theoretisch möglich, in der Praxis ein Suizidmotivator) wird wohl ein solcher bleiben. OpenSSL war noch simpel, also ein modernes SSL mit TLS 1.2 auf 2k zu bauen? Das is Sandkiste! Mit links! Aber den Rest, uargh....
Lehre? Es ist immer eine Frage des Aufwandes, entweder weil das Zielsystem aus der Steinzeit stammt wie bei mir, oder weil der Anbieter evtl. keinen Plan von Let's Encrypt hat. Was dann?
Serverumzug?
Antwort darauf ist in der Regel - und zu Recht - ein "rofl, sicher ned"...
Grad mal geschaut, weil ich eh Ordnung und Platz schaffen muß..
Bei mir läufts auch über Let's Encrypt Authority X3 mit sha256RSA
standartmäßig aktiviert
Ob und wie sicher das Passwort sein muss, das möge jeder für sich selber entscheiden.
Aber ich finde es ziemlich fahrlässig heutzutage ein Passwort im Klartext zu übertragen, zumal es mit Let's encrypt ja nicht mal mit zusätzlichen Kosten verbunden ist.
HTTPS macht aber auch außerhalb vom Login Sinn. Zum Beispiel wenn man nicht möchte dass jeder andere sehen kann welche Seite genau man sich gerade ansieht. Oder weil sie sich auch positiv auf das Google Ranking auswirkt. Und die Last dürfte auch nicht so hoch sein, kleiner Auszug aus der Wikipedia:
Zitat2010 verursachte die Verschlüsselung bei Gmail weniger als 1 % der CPUs-Last, weniger als 1 KB Arbeitsspeicherbedarf pro Verbindung und weniger als 2 % des Netzwerk-Datenverkehrs.
Alles in allem finde ich, dass eine https-Verbindung eigentlich mittlerweile Standard sein sollte, selbst wenn es nur für einen privaten Blog ist.
Ich hätte ja gerne eine web Ansicht von VA damit ich auf meinem Handy bessere Übersicht habe.
Ich hätte ja gerne eine web Ansicht von VA damit ich auf meinem Handy bessere Übersicht habe.
VoodooAlert nur auf Röhrenmonitor!
Schau schau, der neue Firefox 52 (der übrigens TLS 1.3 kann) motzt schon rum:
http://www.xin.at/thrawn/pics/sc…gin-warning.png
Firefox 52 warnt vor dem Einloggen auf plaintext HTTP Seiten (Klicken zum Vergrößern)
Schau schau, der neue Firefox 52 (der übrigens TLS 1.3 kann) motzt schon rum:
Nicht nur Firefox
Ich fände es nicht schlecht, mal etwas von Seiten der Administration zur Thematik zu vernehmen
[align=justify]Hah? Ich hoffe doch Mal sehr stark, daß das Forum das Passwort stark hashed überträgt, alles andere wäre ja heutzutage kompletter Wahnsinn. Bei klassischem htpasswd/htdigest isses halt nur MD5 (nutze ich für Lowsec), bei besserer Webauth so wie hier wird das Pwd doch wohl hoffentlich von einem JavaScript stark hashed und nur der Hash übertragen? Mei meinen Webforms mit PHP Backend nehme ich da aktuell SHA256.
Moment, verwechselst Du jetzt Hashing mit Verschlüsselung? Das Hashing passiert doch immer erst auf dem Server, nicht auf dem Client. Alles andere ergibt auch keinen Sinn.
Aber gerade weil das Hashing auf dem Server passiert, ist es natürlich um so wichtiger, dass eine Transportverschlüsselung existiert.
Seit letsencrypt gibt es da eigentlich auch keine Ausreden mehr. Und selbst wenn DER Aufwand schon zu viel sein sollte, könnte man im Notfall ja sogar auf self-signed-Zertifikate setzen.
Du irrst in dem Punkt: Ein gutes Passwort sollte am Client hashed werden, und nur der Hash sollte übertragen, und am Server in einer Datenbank hinterlegt werden. Beim Login erzeugt der Client den Hash aus dem eingegebenen Passwort erneut, und der wird übertragen, und mit dem serverseitig hinterlegten verglichen. Stimmen sie überein, gelingt der Login. Die einzige Maschine die jemals ein Plaintext Passwort gesehen hat, ist die Clientmaschine unter der völligen Kontrolle des Benutzers.
Der Server darf das Plaintextpasswort gar nie erst sehen!
So funktioniert auch das simple htdigest (statt plain htpasswd), auch wenn es nur einen schwachen MD5 Hash nutzt. Es ist recht wahnsinnig, ein Formularfeld, das ein Passwort beinhaltet einfach so zu übertragen, selbst wenn man HTTPS hat. Wer sagt denn, daß der Serverbetreiber nicht selbst korrumpiert ist? Der Server darf nie ein Plaintextpasswort sehen.
Um sicherzustellen, daß das funktioniert, muß nur gewährleistet sein, daß das Javascript am Frontend und das serverseitige Script im Backend den selben Hashingalgorithmus nutzen. Dann funktioniert das!
Moderne Browser können per JavaScript stark hashen. Und serverseitige Interpreter wie PHP oder Perl können das selbstverständlich auch - und so sollte man es machen!
Edit: Ah, selbst wenn der Server keine Hashinglibraries hätte, auch egal. Der muß ja nicht wissen welche Hashtypen er vergleicht. Ein simpler Stringvergleich reicht ja auch...
[align=justify]Der Server darf das Plaintextpasswort gar nie erst sehen!
Der Satz ist völlig richtig, Deine Schlussfolgerung aber imho falsch. Wenn Du clientseitig hashst, ist ja gerade der Hash das "neue" Passwort. Es reicht also völlig aus, den Hash mitzuschneiden um Zugriff zu erlangen - das ursprüngliche Passwort ist ja nicht mehr nötig.
Das ist doch gerade der Sinn des Hashings: Trotz bekanntgewordenem Hash (z.B. durch Datenbankleak) kann ich nicht auf den oder andere Dienste zugreifen. Wenn aber der Hash ohne weitere Berechnung zur Authentifikation reicht, ist doch das Ursprungspasswort völlig irrelevant. Ich kann das auf dem Client noch 100 mal hashen - das was authentifiziert, was an den Server geht, ist entscheidend.
Das sieht übrigens auch Apache so und empfiehlt htdigest gerade NICHT:
Zitat von "Apache"However, this does not lead to a significant security advantage over basic authentication. On the other hand, the password storage on the server is much less secure with digest authentication than with basic authentication. Therefore, using basic auth and encrypting the whole connection using mod_ssl is a much better alternative.
und weiter:
Zitat von "Apache"Another problem is that the storage of the passwords on the server is insecure. The contents of a stolen htdigest file can be used directly for digest authentication. Therefore using mod_ssl to encrypt the whole connection is strongly recommended.
Quelle: http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html
Edit: Ah, selbst wenn der Server keine Hashinglibraries hätte, auch egal. Der muß ja nicht wissen welche Hashtypen er vergleicht. Ein simpler Stringvergleich reicht ja auch...
Genau das ist der Denkfehler. Wenn ich nur noch Stringvergleiche mache, ist vollkommen irrelevant ob der String vor der Übertragung mit 0 Hashings entstanden ist oder mit 1000. Fange ich den String ab (auf dem Transportweg oder in der Datenbank), habe ich alles was ich brauche.
Und noch mal gut formuliert auf Stackoverflow: http://stackoverflow.com/questions/2091…an-basic-or-not (erste Antwort)
Ah, du hast völlig recht!
Das war in der Tat mein Denkfehler und nicht der deine! Ich habe mir meine Implementierung nochmal angesehen, und es ist eine Kombination aus beidem. Ich hashe scheints clientseitig um den Transfer über's Kabel zu sichern, und serverseitig ein zweites Mal mit Salt.. Deswegen mußte ich das Passwort auch einmal von Plain in PHP hashen, jetzt weiß ich's wieder..
Eh, jo, mein Fehler, und ein schwerwiegender dazu.
OK, danke, Du hast mich echt zum Zweifeln gebracht.
Also - zurück zum Thema: HTTPS (zumindest optional) auch für VA anzubieten fänd ich richtig!
Hmm, ich sehe grade, VA liegt bei HostEurope. Die bieten SSL an, aber nur von kommerziellen CAs, soweit ich das sehen kann. Es läuft also letzten Endes wohl einfach auf's Geld hinaus. Die billigste SSL Option kostet bei denen 2.49€ im Monat, dazu gibt's einen Testzeitraum von 30 Tagen.
Klingt nicht nach viel, aber ein bissl was isses halt auch. Knapp 30€ im Jahr.
Vielleicht finden sich ja ein paar Mitglieder die die 30 € spenden? Oder vielleicht gleich mehr, damit wir nicht nächstes Jahr wieder anfangen müssen zu sammeln.
Wenn man quartalsweise selbst Hand anlegt ist ein kostenloser Betrieb via Let's Encrypt möglich.
https://sebastianbrosch.blog/2017/host-euro…ypt-einrichten/
Verstehe ich nicht, warum die das nicht anbieten.
Wenn man das als Admin manuell machen muß, geht einem das halt sehr schnell Mal gewaltig auf die Nerven...
In der Tat. Da würde sich HostEurope wohl auch keinen Zacken aus der Krone brechen, wenn Sie das automatisert und kostenlos mit anbieten würden.