• Hallo Gast, du kaufst gerne günstig ein und erfährst oft vor deinen Freunden von interessanten Angeboten? Dann kannst du dein Talent als Schnäppchenjäger jetzt zu Geld machen und anderen PCGH-Lesern beim Sparen helfen! Schau einfach mal rein - beim Test der Community Deals!

PCGH & SSL-Verschlüsselung

Deschemi

Komplett-PC-Aufrüster(in)
PCGH & SSL-Verschlüsselung

Wie kommt es eigentlich, das ich beim Aufruf der Seite https://www.pcgh.de lediglich die Meldung kommt: "Dieser Verbindung wird nicht vertraut" und "Wenn Sie normalerweise eine gesicherte Verbindung aufbauen, weist sich die Website mit einer vertrauenswürdigen Identifikation aus, um zu garantieren, dass Sie die richtige Website besuchen. Die Identifikation dieser Website dagegen kann nicht bestätigt werden." und man die Seite als Ausnahme hinzufügen muß?

Letztlich landet man nicht etwa auf einer verschlüsselten Seite von PCGH sondern bekommt die Meldung: "Diese SSL-Seite wird Ihnen präsentiert von web-04. Wir wünschen noch einen schönen Tag!".

PCGH in der Post-Snowden-Ära ohne gültige SSL-Verschlüsselung? Nicht mal bei der Anmeldung via Passwort?
 

Markus_Wollny

Administrator
AW: PCGH & SSL-Verschlüsselung

Hallo,

Wir nutzen auf den Webservern die u.a. auch für PCGH: Computer, IT-Technik und PC-Spiele verwendet werden nur genau ein Zertifikat, das auf den Host ssl.computec.de ausgestellt wurde.

Auf diesen Webservern laufen neben PCGH: Computer, IT-Technik und PC-Spiele auch eine Vielzahl weiterer Hosts, u.a. auch ssl.computec.de. Aufgrund der technischen Spezifikation von SSL können Virtual Hosts auf SSL-Ebene nicht aufgelöst werden (der Hostname ist Teil des HTTP-Headers und somit verschlüsselt); eine Separierung wäre allenfalls für verschiedene IP-Adressen möglich. Da aber die Server für alle Hosts die gleiche IP-Adresse nutzen, wird für alle Hosts bei Aufruf über https das ssl.computec.de-Zertifikat im Kontext des ssl.computec.de-Virtual Hosts ausgeliefert.

Da dieses Zertifikat nur für ssl.computec.de gilt und nicht für PCGH: Computer, IT-Technik und PC-Spiele meldet der Browser, dass die Identität der Webseite nicht bestätigt werden kann. Da es nur diesen einen SSL-Virtual-Host für diese IP-Adresse gibt, werden über https://www.pcgameshardware.de auch keine Inhalte von PCGH: Computer, IT-Technik und PC-Spiele ausgeliefert, sondern die Inhalte von ssl.computec.de.

Dieser SSL-Host wird nur für die Einbindung von Ressourcen wie Magazin-Covers u.ä. auf abo.computec.de, für datenschutz-kritische APIs im Rahmen der Abonnenten-Verwaltung sowie für Facebook-Apps unserer Webseiten genutzt, die SSL zwingend erfordern. Daher bekommt man beim direkten Aufruf von https://ssl.computec.de/ oder https://ssl.pcgameshardware.de/ auch nur diese Testseite zu sehen.

Die Implementierung von SSL für das Login ist aufgrund der Nutzung extern entwickelter Software wie VBulletin nicht ohne weiteres möglich. Veränderungen an dieser Software würden ein wesentlich höheres Sicherheitsrisiko mit sich bringen als der Verzicht auf SSL-Verschlüsselung fürs Login, da solche Veränderungen ein schnelles Update im Falle von Sicherheitspatches mitunter verhindern oder wenigstens erschweren. Solche Updates gab es allerdings gerade in der jüngeren Vergangenheit immer wieder - sowohl für VBulletin als auch für einzelne Komponenten wie Tapatalk, VBSeo und andere von uns genutzte Plugins.

Zum anderen böte eine SSL-Verschlüsselung des Logins keinen echten Sicherheitsgewinn, da anschließend die Session des Users über Session-Cookies gehandelt wird, die ebenfalls notwendigerweise unverschlüsselt übertragen werden. Da SSL-Verschlüsselung nur bei Man-in-the-Middle-Angriffen überhaupt relevant ist, könnte ein solcher Angreifer nach dem erfolgreichen Login auch problemlos das Session-Cookie abfangen und nutzen (Session-Hijacking). Das einzige was zunächst geschützt wäre, ist das Klartext-Passwort, das für das Login genutzt wird. Wenn dieses Passwort jedoch nur auf PCGH genutzt wird und sonst nirgendwo (was wir immer wieder dringend empfehlen), dann hat das Passwort keine höhere Bedeutung als das Session-Cookie.

Eine SSL-Verschlüsselung des Login-Vorgangs allein bringt daher keinen Sicherheitsgewinn, verursacht allerdings Kosten für das Zertifikat, das Zertifikatsmanagement, benötigt eine eigene öffentliche IPv4-Adresse und würde erhebliche Anpassungen an eigener und z.T. auch fremder Software erfordern, was in letzterem Fall einen deutlich erhöhten Patch-Aufwand für Sicherheitsupdates und damit einer verlängerte Zeitspanne zwischen Verfügbarkeit (und damit öffentlicher Bekanntheit der Sicherheitslücke) und Deployment von Updates mit sich bringt, was wiederum ein stark erhöhtes Risiko für die Gesamtheit der Daten darstellen würde. Das ist somit nicht vertretbar.

Die SSL-Verschlüsselung der gesamten Webseite andererseits scheitert unter anderem daran, dass dann alle Inhalte auf der Webseite SSL-verschlüsselt sein müssen - somit könnte praktisch keine Werbung eingebunden werden und Fremd-Software, wie eben z.B. VBulletin bzw. einige Plugins, die z.T. absolute URLs (d.h. mit http://) verwenden, würde damit nicht zuverlässig funktionieren.

Der Heartbleed-Bug zeigt zudem, dass das ganze SSL-Konstrukt an sich höchst fragil und fragwürdig ist. Durch Heartbleed konnten über mehrere Jahre hinweg die privaten Schlüssel von Zertifikaten remote ausgelesen werden. Somit konnte sich ein Man-In-The-Middle-Angreifer Zugriff auf das Zertifikat verschaffen und die Kommunikation zwischen Client und Server problemlos mitlesen. Der Bug ist zwar behoben, aber er zeigt, dass es immer wieder Möglichkeiten gibt, wie Zertifikate vor Ablauf ihrer Gültigkeit kompromittiert werden.

Wird das bemerkt, so kann ein solches Zertifikat zwar revoked und ein neues ausgestellt werden. Das kümmert allerdings die Clients nicht, die akzeptieren auch zurückgezogene Zertifikate weiterhin; die Server der Root-Zertifizierungsstellen würden auch kaum den Ansturm von Requests vertragen, wenn bei jedem Aufruf einer SSL-Ressource die Gültigkeit des Zertifikats dort angefragt werden müsste. Daher ist dieser Test in Chrome defaultmäßig deaktiviert, zumal der Test bei jedem Aufruf auch Zeit kostet und somit das Surfen merklich verlangsamt.

Man kann den Test im Client (z.B. eben Chrome) natürlich manuell aktivieren, doch das bringt ebenfalls rein gar keinen Sicherheitsgewinn: Das Protokoll sieht vor, dass bei einem Timeout bei der Gültigkeitsabfrage das Zertifikat weiterhin als gültig anzusehen ist. Da das wie gesagt nur bei Man-in-the-Middle-Angriffen überhaupt relevant ist, hat dieser Man-in-the-Middle also nichts weiteres zu tun, als die Anfragen an die Root-Zertifizierungsstellen zu droppen, um mit gestohlenen, bereits revokten Zertifikaten auch weiterhin die Kommunikation entschlüsseln zu können.

Daher bleiben wir dabei: SSL ist für unseren Anwendungsfall (Community-Webseiten) nicht wirklich zweckdienlich und bringt viele Probleme mit sich, die wir gar nicht oder nur mit nicht vertretbarem Aufwand lösen könnten. Passwörter sollten grundsätzlich nicht mehrfach verwendet werden - allein damit sinkt der Wert eines Passworts bei Man-in-the-Middle-Angriffen schon beträchtlich. Wenn man zudem über öffentliche WLANs oder anderweitig ungesicherte Verbindungen surft, dann sollte man im Bedarfsfall auf einen vertrauenswürdigen VPN-Anbieter zurückgreifen - ich nutze privat https://www.privateinternetaccess.com, es gibt sicher auch eine Reihe weitere gleichwertige Anbieter.

Die Sache sieht anders aus, wenn wirklich kritische Daten übertragen werden sollen wie Kreditkartendaten oder Bankverbindungen. Unsere Abo-Seite ist daher komplett SSL-verschlüsselt. Bei Forenposts, Kommentaren u.ä. sehen wir aber auch keine besonders hohe Attraktivität für Lauscher.

Viele Grüße

Markus
 

turbosnake

Kokü-Junkie (m/w)
AW: PCGH & SSL-Verschlüsselung

Der Heartbleed-Bug zeigt zudem, dass das ganze SSL-Konstrukt an sich höchst fragil und fragwürdig ist. Durch Heartbleed konnten über mehrere Jahre hinweg die privaten Schlüssel von Zertifikaten remote ausgelesen werden.
Das betrifft nur eine von mehreren Möglichkeiten SSL zu nutzen, nämliche OpenSSL alle anderen SSL Version die im Einsatz sind sind von Heartbleed nicht betroffen, dazu betrifft es nur OpenSSL ab 1.0.1, das heißt alle älteren Versionen sind nicht betroffen.
Zwischen dieser Version und dem Fix in 1.0.1g sind 2 Jahre vergangen, davor hat niemand diese Lücke gemeldet.
Ob sie in dieser Zeit genutzt wurde ist unbekannt.

Die Sache sieht anders aus, wenn wirklich kritische Daten übertragen werden sollen wie Kreditkartendaten oder Bankverbindungen. Unsere Abo-Seite ist daher komplett SSL-verschlüsselt. Bei Forenposts, Kommentaren u.ä. sehen wir aber auch keine besonders hohe Attraktivität für Lauscher.
Dann schließt bitte den Marktplatz.;) Auch dort werden Transaktionen durchgeführt bei denen kritischen Daten, wie Bankverbindungen einsehbar sind. :schief:
 
Zuletzt bearbeitet:

Markus_Wollny

Administrator
AW: PCGH & SSL-Verschlüsselung

Das betrifft nur eine von mehreren Möglichkeiten SSL zu nutzen, nämliche OpenSSL alle anderen SSL Version die im Einsatz sind sind von Heartbleed nicht betroffen, dazu betrifft es nur OpenSSL ab 1.0.1, das heißt alle älteren Versionen sind nicht betroffen.
Zwischen dieser Version und dem Fix in 1.0.1g sind 2 Jahre vergangen, davor hat niemand diese Lücke gemeldet.
Ob sie in dieser Zeit genutzt wurde ist unbekannt.

Es gibt sehr viele Hinweise, dass das durchaus der Fall war. Dass über zwei Jahre alte Versionen nicht betroffen waren hilft im Normalfall wenig weiter, denn in der Regel wird jeder Admin versuchen, die eingesetzte Software auf einem hinreichend aktuellen Stand zu halten. Dass OpenSSL auf einem Webserver über zwei Jahre lang nicht upgedatet wird halte ich für hypothetisch, wer Updates so lange zurückhält handelt fahrlässig. Ebensowenig hilfreich ist der Hinweis, dass "nur" OpenSSL betroffen war, denn das kommt eben auf Loadbalancern, Reverse Proxies und Webservern wesentlich häufiger zum Einsatz als irgendeine andere SSL-Bibliothek. Selbst Windows-Maschinen stehen häufig hinter *nix-Loadbalancern, auf denen dann SSL terminiert wird und OpenSSL zum Einsatz kommt.

Dann schließt bitte den Marktplatz.;) Auch dort werden Transaktionen durchgeführt bei denen kritischen Daten, wie Bankverbindungen einsehbar sind. :schief:

Die müssen ja nicht unbedingt per PM weitergegeben werden, richtig? Und schon gar nicht, wenn man weiß, dass man durch ein offenes WLAN gefährdet ist. So oder so kann jeder selbst entscheiden, wie hoch das Risiko von Man-in-the-Middle Angriffen zu bewerten ist und ggf. eben wie angesprochen einen VPN-Tunnel verwenden. Gegen PM-Abhorchen wäre zudem eine reine Absicherung des Logins nutzlos - und komplett auf SSL umzustellen funktioniert wie beschrieben aufgrund der Werbeeinbindung nicht. Im Gegensatz zu eBay, Amazon und anderen Markplätzen verdienen wir an Transaktionen nichts, sondern sind auf Werbeeinnahmen angewiesen.

Viele Grüße

Markus
 
Zuletzt bearbeitet von einem Moderator:

turbosnake

Kokü-Junkie (m/w)
AW: PCGH & SSL-Verschlüsselung

.Dass über zwei Jahre alte Versionen nicht betroffen waren hilft im Normalfall wenig weiter, denn in der Regel wird jeder Admin versuchen, die eingesetzte Software auf einem hinreichend aktuellen Stand zu halten.
Dass OpenSSL auf einem Webserver über zwei Jahre lang nicht upgedatet wird halte ich für hypothetisch, wer Updates so lange zurückhält handelt fahrlässig
1.0.1 ist nicht die einzige aktuelle OpenSSL Version. 1.0.0 wird mit 1.0.0l wird ebenso noch unterstützt, ein Verweilen auf einer weiterhin gepflegten Libary wird in keinem Fall Nachteile in der Sicherheit haben. Sondern ist wie es sich jetzt herausgestellt sogar sicherer gewesen als ein Update auf 1.0.1.
Daran ist ebenso kein fahrlässig Verhalten erkennbar.
Sofern 1.0.1 verwendet wurde, die Version aber ohne Heartbeat-Support kompiliert wurde bestand ebenso keine Gefahr.
Das bedeutet das selbst wenn 1.0.1 genutzt wurde kann man nicht davon ausgehen das diese Seite betroffen war.
Daraus folgt auch das der Bereich in dem ein Angriff möglich war, voraussetzt das eine entsprechende OpenSSL Version mit Heartbeat im Einsatz war, deswegen ist auch legitim von "nur" zusprechen.

Die müssen ja nicht unbedingt per PM weitergegeben werden, richtig?
Wie sonst? Mails sind auch nicht mehr als Postkarten, da diese kaum verschlüsselt verschickt werden. Sowas wäre ohne weiteres möglich, aber es wird kaum genutzt.

Und schon gar nicht, wenn man weiß, dass man durch ein offenes WLAN gefährdet ist.
Wir wissen weder ob der Provider zu dem anderen Provider die Mails verschlüsselt überträgt, noch ob der Empfänger in einem offenen WLAN surft. Das liegt außerhalb der Kontrolle des Absenders, der Empfänger wird beim einloggen kaum daran denken das jemand in dem Moment seine Login Daten holen kann bzw viel mehr an die Konsequenzen.

So oder so kann jeder selbst entscheiden, wie hoch das Risiko von Man-in-the-Middle Angriffen zu bewerten ist und ggf. eben wie angesprochen einen VPN-Tunnel verwenden.
Kann man nicht, da man nie weiß wie der gegenüber handeln wird, das liegt außerhalb der Kontrolle von einem selber.

Gegen PM-Abhorchen wäre zudem eine reine Absicherung des Logins nutzlos - und komplett auf SSL umzustellen funktioniert wie beschrieben aufgrund der Werbeeinbindung nicht.
Profit ist euch also wichtiger als die Sicherheit eurer Nutzer? Mal hoffen das da nichts schief geht, sonst gibt es ein ernsthaftes Problem.
 
Zuletzt bearbeitet:

Markus Wollny

Administrator
Es ist keine Frage, ob Profit wichtiger ist als Sicherheit. Es ist Tatsache, dass ein Betrieb der Webseite ohne Werbeeinnahmen nicht möglich ist. Es steht Dir jederzeit frei, das Angebot zu diesen Bedingungen zu nutzen oder auch nicht. Ich denke, wir haben hier klar dargestellt, wie die Sachlage aussieht. Zu Deinen Anregungen einzelne Pakete von Hand zu selektieren und zu kompilieren spare ich mir mal auch jeden Kommentar, sorry. Natürlich kann sich jeder in seiner Freizeit die Welt so zurechtstricken wie er sie gerne hätte, Webserver und SSL-Libraries am besten selbst schreiben... Praxistauglich ist so etwas allerdings leider absolut nicht. Tatsachen zu ignorieren, die nun denke ich hinreichend erklärt sein sollten, wird diese Diskussion jedenfalls kaum weiterbringen.

Viele Grüße

Markus
 
  • Like
Reaktionen: ZAM

turbosnake

Kokü-Junkie (m/w)
AW: PCGH & SSL-Verschlüsselung

Zu Deinen Anregungen einzelne Pakete von Hand zu selektieren und zu kompilieren spare ich mir mal auch jeden Kommentar, sorry
Ich habe nie den Vorschlag gemacht Pakete zu selektieren ich sagte nur das Heartbleed kein zwingender Bestandteil betroffener OpenSSL Versionen sein muss. Da man beim kompilieren Heartbeat deaktivieren und das eine vorgesehene Funktion ist.
Nach dem was ich gelesen habe ist es nicht mehr an Aufwand als hiermit zu kompilieren
-DOPENSSL_NO_HEARTBEATS.Dazu ist das in Android ab 4.1.2 standardmäßig so eingestellt.
Ich kenne mich in dem Bereich allerdings auch nicht wirklich aus, aber es ist nicht unmöglich es so zumachen.

Natürlich kann sich jeder in seiner Freizeit die Welt so zurechtstricken wie er sie gerne hätte, Webserver und SSL-Libraries am besten selbst schreiben... Praxistauglich ist so etwas allerdings leider absolut nicht.
Daraus ist OpenSSL btw entstanden, genauer deswegen
Ein wenig bekanntes Detail aus der OpenSSL-Genesis ist, dass das mal SSLeay hieß — eay sind die Initialen des initialen Autoren, Eric Young —, und der hat das Projekt gestartet, weil er lernen wollte, wie die Division von 1024-Bit-Zahlen funktioniert.
Quelle
 
Zuletzt bearbeitet:

Markus Wollny

Administrator
Pakete werden bei den meisten Distributionen nicht von Hand kompiliert. Wir setzen Debian ein, auch Ubuntu, Redhat, CentOS, SuSE etc. basieren auf Binär-Paketen. Selbst Nutzer von Source-Distros wie Gentoo werden wohl kaum in hellseherischer Weisheit Heartbeat für OpenSSL deaktiviert haben, diese Diskussion ist daher recht müßig, allenfalls auf theoretischer Ebene relevant.
Wir waren aufgrund unserer Loadbalancing-Infrastruktur von Heartbleed nicht unmittelbar betroffen, doch das war nicht weil wir diese Architektur als Schutz vor Heartbleed so gewählt hatten. Auf der anderen Seite war u.a. ein Yahoo von dem Bug betroffen, obwohl vielleicht ein solcher Großkonzern noch eher Ressourcen für einen Code-Audit einer so wichtigen Library gehabt hätte.

Viele Grüße

Markus
 
  • Like
Reaktionen: ZAM

Trefoil80

BIOS-Overclocker(in)
AW: PCGH & SSL-Verschlüsselung

Der Punkt mit dem Marktplatz und den verbundenen Zahlungsdaten (PNs) halte ich in der Tat für kritisch! Das hatte ich gar nicht bedacht.
Ich hoffe, diese Daten sind verschlüsselt in Eurer Datenbank hinterlegt!

Bezügl. SSL: Warum bekommt es denn Computerbase hin, zumindest teilweise mit SSL zu verschlüsseln (Login-Bereich/Mixed Mode)? Mit Werbung scheint es dort kein Problem zu geben.

Ich denke, mit ein bisschen Aufwand sollte es schon möglich sein, das Sicherheitsniveau auf PCGH anzuheben.
 

lomex11

Schraubenverwechsler(in)
AW: PCGH & SSL-Verschlüsselung

Ich habe hier schon etwas zum Thema "Klartextpasswort in Aktivierungsemail" geschrieben: Hier klicken

Der Thread wurde geschlossen mit dem Verweis dass hier weiter diskutiert werden soll.

Ich möchte gerne auf Trefoil80 eingehen:

Natürlich sollte man überall ein anderes Passwort verwenden, es sollte möglich lang sein usw usw.
Aber Tatsache ist, dass die meisten Nutzer immer noch einfache Passwörter verwenden und dies auch gerne auf allen Seiten die sie verwenden. Es geht hierbei also nicht um den Schutz von erfahrenen Nutzern sondern um den Schutz eben dieser die es nicht besser wissen. Ich habe den Thread nicht erstellt, weil ich um mein eigenes Passwort besorgt war, ich verwende nämlich ein eindeutiges für dieses Forum, sondern generell über die Fahrlässigkeit im Umgang mit den Passwörtern der User.
 
G

Gast20140707_2

Guest
AW: PCGH & SSL-Verschlüsselung

Wer statt eines Passwort sich einen persönlichen Algorithmus angewöhnt lächelt nur über dergleichen Probleme.

Somit hat man auf jeder Webseite ein eigenständiges Passwort ohne sich mehr als eine Vorgehensweise merken zu müssen.
 

Trefoil80

BIOS-Overclocker(in)
AW: PCGH & SSL-Verschlüsselung

Algorithmus? Klick...

Im Falle "Passwort" würde ich mir einfach eine "Grund-Passphrase" (also einen kompletten Satz) überlegen, und den immer mit Teilen des jeweiligen Onlinedienstes ergänzen.
Von jedem Wort immer die Anfangsbuchstaben nehmen.

Beispiel:
Mein Passwort bei PCGH kennen exakt 0 fremde Personen!

Passwort:
MPbPCke0fP!

Sorry, aber wer heutzutage immer noch bei mehreren (relevanten!) Diensten die gleichen Passwörter verwendet, hat es echt nicht kapiert...
 
Zuletzt bearbeitet:

Icephoen1x

Komplett-PC-Aufrüster(in)
AW: PCGH & SSL-Verschlüsselung

Na und? Hat trotzdem nix mit dem eigentlichen problem zu tun. Heutzutage ist es nunmal standard passwörter verschlüsselt zu speichern, und dafür gibt es auch gute gründe. Überleg dir mal jemand erbeutet dein passwort und geht dann im Marktplatz unfug treiben zum Beispiel. Ausserdem ist es unrealistisch zu glauben jeder hat ein passwort das er nur auf pcgh benutzt. Sagen wir mal pcgh wird opfer eines hackerangriffes und der hacker erbeutet email addressen und passwörter. Was meinst du wohl bei wievielen emails er sich mit dem pcgh passwort einloggen kann?
Entschuldigung aber "benutz ein sicheres passwort" ist ein dummes argument.
 

Trefoil80

BIOS-Overclocker(in)
AW: PCGH & SSL-Verschlüsselung

Ich halte nix davon, die Sicherheit komplett auf den Dienstanbieter abzuschieben.

Natürlich sind die Forenbetreiber von PCGH angewiesen, sorgsam mit den Daten umzugehen und die Passwörter verschlüsselt abzuspeichern.
Du darfst aber trotzdem nach den ganzen Skandalen Dein Hirn einschalten, den Popo aus dem Sessel hieven und Dir sinnigerweise ein brauchbares --> Passwortkonzept <-- überlegen!
 

turbosnake

Kokü-Junkie (m/w)
AW: PCGH & SSL-Verschlüsselung

Ein sicheres PW ist verschwendet, wenn der Dienstanbieter keine sichere Infrastruktur anbietet.:schief:
Deswegen kann man gleich ein unsicheres benutzen, wenn der Dienst keine relevant Daten braucht oder man meidet ihn ganz, wenn dort relevante/wichtige Daten liegen sollen.
Ist ein Grundprinzip das man anwenden sollte.

Dir sinnigerweise ein brauchbares --> Passwortkonzept <-- überlegen!
Alles was für andere nachvollziehbar ist sollte man vermeiden.
 

Icephoen1x

Komplett-PC-Aufrüster(in)
AW: PCGH & SSL-Verschlüsselung

Was bringt ein brauchbares passwortkonzept wenn das passwort im klartext gespeichert wird. Ein schwer zu knackendes passwort bringt nur dann was, wenn man es überhaupt knacken muss. Dank regelmäßig auftauchender programmierfehler ist es ja durchaus denkbar das mal jemand passwörter ausliest. Wenn die dann nicht verschlüsselt sind kann er sich einfach mal mit user x einloggen und unfug treiben. Überleg mal jemand würde einfach im namen eines vertrauenswürdigen users geschäfte im marktplatz machen.
 

Trefoil80

BIOS-Overclocker(in)
AW: PCGH & SSL-Verschlüsselung

Mit einem Passwortkonzept hast Du aber dann den Schaden aber nur bei einem Dienst. Nicht bei mehreren...
 

PCGH_Stephan

Administratives Postpanoptikum
Teammitglied
AW: PCGH & SSL-Verschlüsselung

Das Passwort wird lediglich bei seiner Erstellung im Klartext verschickt, aber nicht im Klartext gespeichert. (Falls der E-Mail-Account kompromittiert ist, ist es egal, ob das Passwort im Klartext ausgelesen oder via Passwort-Vergessen-Funktion zurückgesetzt werden kann.) Die Passwörter für alle Nutzer-Accounts sind gesalzen und doppelt gehasht.
 

lomex11

Schraubenverwechsler(in)
AW: PCGH & SSL-Verschlüsselung

Das Passwort wird lediglich bei seiner Erstellung im Klartext verschickt, aber nicht im Klartext gespeichert. (Falls der E-Mail-Account kompromittiert ist, ist es egal, ob das Passwort im Klartext ausgelesen oder via Passwort-Vergessen-Funktion zurückgesetzt werden kann.) Die Passwörter für alle Nutzer-Accounts sind gesalzen und doppelt gehasht.

Vielen Dank für deine Rückmeldung. Genau darum ging es ja auch in meinem Post. Das Passwort sollte nicht als Klartext per E-Mail verschickt werden. Ich finde es schon erstaunlich, dass hierfür die Gründe, besonders in einem PC-Forum nicht offensichtlich sind.

1. Das Passwort liegt nun unverschlüsselt im Posteingang.
2. Das Passwort liegt unter Umständen lokal auf dem Rechner in Outlook/Thunderbird usw.
3. Man ist in einem Internetcafe oder z.B. Universität und es lässt sich nicht vermeiden, dass der Sitznachbar mitliest.
...

Besonders in dem Fall, dass der Nutzer sein Passwort auf mehreren Seiten verwendet, ist das besonders problematisch. Man kann natürlich nun, wie schon oft hier gemacht, argumentieren dass man das nicht machen soll. Allerdings ist es eher so das der GROSSTEIL der Nutzer einfache Passwörter verwendet und häufig auch das gleiche Passwort auf vielen Seiten. Durch das Ändern einer einzigen Codezeile könnt ihr dieses Problem lösen. Oder man diskutiert weiter herum dass es die Verantwortung des Nutzers ist. Aber wieso ein Sternchen (***) Feld wenn ihr danach das Passwort eh im Klartext rum schickt?
 

marvinj

PCGH-Community-Veteran(in)
SSL-Zertifikat

Morgen,
heute versuchte ich mal PCGH per veschlüsselter Verbindung aufzurufen. Allerdings stimmt da wohl was mit dem Zertifikat nicht, bzw. es wurde kein dediziertes für die PCGH-Website und die pcghx.de Domain hinterlegt. Wahrscheinlich ist dies gewollt, aber für die heutige Sicherheit :gruebel::-_-:. So ein Zertifikat von einer CA kostet n' Appl' und n' Ei ;)
ssl_pcgh.png

Oder ist der Plan, dass hier sowieso nichtkritische Inhalte widergegeben werden, und somit auf eine SSL/TLS Verschlüsselung verzichtet wird?
Gruß
 

marvinj

PCGH-Community-Veteran(in)
AW: SSL-Zertifikat

Interessant zu lesen, habe ich wohl in der Suche übersehen. Dennoch ist das doch wirklich keine Lösung...
 
Oben Unten