 Es läuft. Wunderbar. Drei Minuten Nachspielzeit. Willkommen zu meiner Nachmittag-Session. Irgendwie kriege ich es immerhin, doch mich zweimal breitschlagen zu lassen. Egal. Diese Session ist vollkommen unvorbereitet. Also ihr seid genauso vorbereitet wie ich. Das ist super. Mache ich aber hin und wieder gerne Sicherheits-Q&A, also Fragerunde. Ihr fragt, ich antworte und weiß hoffentlich, was dazu zu sagen. Das ist nicht ganz unwahrscheinlich, dass ich wesens irgendwas halbwegs normales dazu beitragen kann. Weil ich mich in meinem tagtäglichen Leben mit diesem Thema regelmäßig beschäftige. Webseiten betreue ich in diesem Thema und auch so ein Newsletter rausbringe. Der allerdings lügt, weil er kommt mittlerweile nur noch monatlich und nicht zweiböchentlich. Aber da stehen immer wieder auch irgendwelche Security-Tipps drin. Insofern hoffe ich, dass ich das ein oder andere dazu beitragen kann, was ihr jetzt wissen wollt. Und ihr dürft jetzt fragen. Und wenn ihr was fragt, ihr habt ja kein Mikro, ich werde das dann immer wiederholen für die Aufnahme. Also nicht wundern. Bitte. Also die Frage, wir starten mit einer extrem speziellen Frage. Super. Normalerweise kommen hier irgendwelche Larry-Fari-Fragen. Als erstes, wir steigen uns langsam rein. Aber mit so einer Frage zu starten, ist schön. Die Frage ist, es hat jemand Tor-Exit-Server IP-Adressen geblockt. Auf der Webseite, für die Webseite, ob man das machen sollte, sollte, müsste. Ich persönlich würde sagen, nö, weil es auch egal. Also ich mache an den Webseiten, was sowas angeht, relativ selten irgendwas. Also auf Webseitebene wohlgemerkt. Wir reden jetzt über WordPress-Umfeld-Webseitebene. Ob irgendetwas auf Hosterebene aus Sicherheitsgründen geblockt wird, wir haben ja auch wieder mal Hoster-Besuch im Plenum sitzen. Also wenn die irgendwas in ihren Security-Einstellungen machen, weil sie glauben, da müsste immer so eine so auf Infrastruktur-Ebene, okay. Aber jetzt auf reiner WordPress-Ebene, nö. Da block ich sowieso eher selten bis nichts. Ja, kannst du direkt einhangen, wenn du möchtest. Ja, ich wiederholt das an den Kürze gleich nochmal. Also die Rückmeldung war tatsächlich, manchmal hat man das auf Kundenanfrage, dass man die Server, die IPs blockt. Aber nur wenn es vorher Vorfälle gab und wenn dann tatsächlich ausschließlich auf Hosting-Ebene, auf Infrastruktur-Ebene, es ist auch vollkommen sinnlos, da jetzt WordPress einzubeziehen oder da nochmal auf der Ebene irgendwie, das sind ein paar Ebenen drüber. Das kann viel früher, kann der Zugriff abgefangen werden. Das spart Performance und das muss nicht auf WordPress-Ebene passieren. Es waren aber andere Meldungen eben noch, die ich bitte. Ja, genau, wenn du über das Tor-Netzwerk gehst, also die Frage war, was das Ganze ist. Also das Tor-Netzwerk ist ja so ein Netzwerk, mit dem du anonym surfen kannst und nicht auffällst. Und am Ende hast du ja so ein Exit-Note. Das bedeutet, das ist der Punkt, wo aus diesem Tor-Netz wieder ins normale Netz, das heißt, das ist die IP-Adresse, die dann angezeigt wird, mit der du quasi eigentlich unterwegs bist. Und das ist dann das, wo alle, die über dieses Netzwerk auf deiner Seite zugrafen, dann quasi rauskämen und die du deswegen erkennen kannst. Ja, das könnten prinzipiell auch legitime Menschen sein. Ja, ja, klar. Genau, also können legitime Sachen sein, deswegen nicht so viel blocken, weil wir erstmal alle Leute zulassen wollen, auch welche, die anonym surfen wollen. Die Frage ist, ob man WordPress noch einsetzen kann, ob das schlau ist, ob das ein empfehlenswertes Tool ist. Also ich nutze WordPress hin und wieder selbst und zwar für genau so ungefähr eine Viertelstunde. Wenn ich eine mir vollkommen unbekannte Seite habe und mit der irgendwas anfangen soll, dann installiere ich WordPress und lasse den Dateiscanner da drüber laufen, um mal zu gucken, ob der irgendwas entdeckt. Das ist so diese erste grobe Prüfung, ob der Schadcode mir quasi mit dem Nacken hinter ins Gesicht springt. Dafür kann man WordPress ganz gut verwenden und wenn das fertig ist, löscht ich WordPress wieder. Grundsätzlich spricht ansonsten jetzt nicht so viel dagegen. Das ist jetzt kein Schrott. Es ist vielleicht nicht zwingend notwendig. Es gibt bessere Sachen. Wenn man diese Funktionen, die WordPress bietet, haben möchte, gibt es bessere Lösungen als WordPress. Aber WordPress ist halt Benutzer einfach. Also wenn ich eine Reputation-Firewall haben will, dann nehme ich was anderes, aber mit WordPress ist sie vielleicht für den normalen Benutzer einfacher zu konfigurieren. DSGVO-mäßig ist das weniger ein Problem. Es gibt drei, vier Sachen, die man überhaupt abschalten sollte. Also diese Bruteforce-Netzwerk-Login-Schutz, weil der IP-Adressen in die Weltgeschichte schickt. Da kann man aber auch, wie ich eben im Vortrag sagte, auch drüber streiten. Also ob das überhaupt DSGVO-relevant ist, werden zwei IP-Adressen verschickt, aber halt von Menschen, die Login-Fehlversuche haben, was potenziell jetzt nicht der normale Besucher ist. Also da kann man dann auch ein bisschen wieder drüber streiten. Und ja, WordPress hatte letzte Woche eine Sicherheitslücke, eine riesengroße, also eine wirklich wahnsinnig große. Es gibt sehr einfache Möglichkeiten in WordPress, die Benutzernamen von WordPress herauszufinden. Also ich brauche da wenige Minuten, dann kann ich dir bei einer normalen WordPress-Seite sagen, wie die Benutzer heißen auf deiner Seite. Und es gibt Menschen, die das als große Sicherheitslücke von WordPress empfinden. Ich gebe zu, ich installiere regelmäßig auch was auf meinen Seiten, um das auszunocken. Jetzt nicht, weil ich das als große Sicherheitslücke empfinde, sondern weil ich da meistens schöne Namen angezeigt haben lassen möchte, statt der eigentliche Benutzernamen. Aber wenn du den Benutzernamen hast, brauchst du halt immer noch ein Passwort. Wenn das Passwort sicher ist, ist es vorkommwurscht, ob jemand den Benutzernamen hat oder nicht. Wenn du dich bei Twitter einloggst, loggst du dich da auch mit deinem Twitter-Benutzernamen ein. Und das ist dein Twitter-Username, also der Twittername. Und bei Twitter kennen wir jetzt auch keiner auf die Idee, dass der Namen in irgendeiner Form zu verstecken wäre, weil der steht sogar auf unseren Batches drauf. Also damit hast du auch schon den Benutzernamen, brauchst nur noch das Passwort desjenigen bei Twitter. Um jetzt zu argumentieren, dass bei WordPress es notwendig wäre, diesen Benutzernamen zu verstecken, muss man jetzt schon um viele Ecken laufen, um das Argument irgendwie valide zu machen. WordPress hat aber eine Funktion, diese Möglichkeiten in WordPress zu blockieren, dass man eben nicht mehr die Benutzernamen rausfinden kann. Die Sicherheitslücke letzte Woche war, dass in der Funktion ein Fehler drin war, so dass man es doch konnte. Also sprich, die Sicherheitslücke in WordPress führte dazu, dass WordPress sich wieder so verhalten hat, als wäre kein WordPress installiert, was jetzt die Benutzernamen in Numeration angeht. Also wegzuwerfen. Ist aber ein klassisches Problem, dass die Security Plugins gerne Security-Lücken haben. Das trifft jetzt nicht nur auf WordPress zu, sondern auch auf die anderen. Es gibt halt eine ganze Menge Code auf das System drauf, um das System sicherer zu machen. Und wenn man pech hat, ist in dem Code aber eine Sicherheitslücke drin. Deswegen ist auch wie immer bei WordPress es sehr hilfreich, möglichst wenig zu tun. Das, was man erreichen will, mit möglichst wenig Ballast, um halt das Risiko zu minimieren, dass da irgendwas drin sich böse auswirkt. Und deswegen sind WordPress und auch iThemes Security um Nummern was anderes zu nennen, damit wir nicht nur über WordPress baschen. Es sind halt so umfangreiche Security-Suite, wo ich jetzt keinen für Steinige, dass er sie nutzt, die ich aber jetzt nicht nutzen würde, weil mir das zu viel Code ist für das, was ich tatsächlich an sinnvollen Maßnahmen erreichen möchte. Zugegeben für den End-Anwender sind die manchmal hilfreicher, weil sie einfacher zu konfigurieren sind und man mit ihnen weniger kaputt machen kann als mit Lösungen, die ich jetzt zum Beispiel einsetzen. Du darfst gerne WordPress einsetzen, ich grinse ein bisschen, aber es ist nicht schlimm. Ich mache tatsächlich ganz ähnliche Dinge, nur ich mache sie selber. Was iThemes und WordPress machen, sind ein paar Sachen abschalten, ein paar Sachen absichern. Und was ich mache, ich habe einen Snippet, so ein HTXS Snippet, also wohl gemerkt, wenn man natürlich mit dem Engine X rumläuft, funktioniert das logischerweise nicht mehr. Aber wenn man jetzt auf dem Apache Server unterwegs ist, habe ich da so ein Snippet, was ich in alle meine Seiten reinprügel. Da sind es ein paar Sachen drin, die man gängigerweise abschalten sollte, die in den allermeisten Fällen sowieso schon hosterseitig abgeschaltet sind. Wir gehen nur nochmal sicher, dass wir das machen. Also als Beispiel, ich muss mal den Maus finden hier oben. Ich kann meinen Fensterversuch ein kleiner zu machen. Ah, guck mal an. Jetzt machen wir noch ein bisschen Schriftgröße größer hier. Dann könnt ihr tatsächlich was sehen, wunderbar. Wahnsinn. Also diese Full Path Disclosure zum Beispiel ist meiner persönlichen Meinung nach ein Bucket WordPress. Das sollte man mit den Core Entwicklern nicht diskutieren, weil dann kriegt man einen auf den Deckel für. Dass es Stellen gibt in WordPress, wo man Dateien aufrufen kann, die eine Fehlermeldung ausgeben und mit dieser Fehlermeldung kann man den vollen Fahrt von WordPress herausfinden. Damit könnte man was anfangen. Die Meinung der Core Entwickler an dieser Stelle ist, das ist ein Fehler in der Server-Konfiguration, das ist nicht unser Problem. Das ist nicht ganz falsch, weil es ist eine Server-Konfigurationsangelegenheit. Sie könnten aber einfache Maßnahmen ergreifen, um das zu verhindern. Das wäre auch gut, aber egal. Aber um das zu vermeiden, also 1&1 hat die Server schon mal gerne so konfiguriert, dass das nicht so richtig ist, ist das ja einfach da. Mit der Konfiguration passiert es halt, dass in den Fällen einfach kein PHP-Fehler ausgegeben wird. Damit das kein PHP-Fehler ausgegeben wird, kann man nicht das Verzeichnis sehen, Ende Gelände. Bei den allermeisten Hosten braucht man das nicht, aber es schadet auch nichts, wenn es drin steht. Man verhindert so den Zugriff auf alle Dateien, die irgendwie nicht offensichtlich sinnvoll sind. Readme, Config, die irgendwie Back-Dateien, die wp-config.pap mal unbennennende die wp-config.back, weil man sie mal sichern will. Ab dem Augenblick kommt irgendwer anders auf die Idee, ihr könnt sie ja lesen, da stehen die Datenbankzugangsdaten drin, wunderbar Treffer. Deswegen blockieren wir sie damit. Die Robotsteaks, die muss natürlich weiter drin bleiben. HTXS und HTPass-WD, irgendwie kein Zugriff drauf, und hier wp-config, wp-sample wie ich mich, readme verhindern. Die Install.pap soll nicht mehr aufrufbar sein, wenn das WordPress fertig installiert ist. Die XML-RPC-Schnittstelle blockieren wir, weil sie fast kein Mensch braucht. Inklude-Dateien sollten nicht aufrufbar sein. Also möglichen Sachen, die Security hätte, habe ich regelmäßig auskommentiert, weil das ist nicht so trivial im WordPress-Umfeld. Also so, wie die jetzt hier stehen, würden sie vieles kaputt machen. Also wenn man die so einkonfiguriert, man kann das schön konfigurieren, das muss man sich aber jede einzelne Seite individuell vornehmen, und dann kann man sie schön machen. Genau, der letzte ist das Problem. Das heißt, deswegen sind die auskommentiert, damit man das individuell dann pro Seite konfiguriert. Aber so als Ganzes und als Snippet zum einfach nur reinkopieren sind, ist das nicht so geeignet. Deswegen ist es immer mit Vorsicht. Und hier unten, das ist so ein schöner Klassiker. Wir verhindern das Ausführen von PHP-Dateien im Uploadsverzeichnis. Weil im Uploadsverzeichnis liegen ja die Mediendateien, also Bilder und Videos und so was. Da liegt keine PHP-Datei. Und wenn da eine liegt, dann ist das eine, die nicht richtig ist. Dann soll die da nicht liegen. Dann soll die erst recht nicht da ausgeführt werden. Das sind auch Dinge, die man mit WordPress und iThemes Security so konfigurieren kann, oder die meisten Sachen davon. Das ist jetzt nicht so, als wäre das Voodoo. Nur das ist halt Werbung. Das ist halt in der HTXS-Datei sehr viel performant. Das ist dann irgendwas konfiguriert. Wobei iThemes Security auch nichts anderes macht, wenn man das Häkchen setzt, als das auch in die HTXS reinzuschreiben. Am Ende kommt das selbe Ergebnis bei rum. Deswegen kann man das Plug-in auch direkt weglassen dafür. Und... Also, wenn du auf Engine X unterwegs bist zum Beispiel, dann hast du sowas wie eine HTXS-Datei nicht. Also die HTXS-Datei ist ja quasi eine Webserver-Konfigurationsdatei, die du in dein Verzeichnis legen kannst und nochmal Zusatzdirektiven angeben kannst, die über das hinausgehen, was du zentral für den V-House oder so konfiguriert hast. Und sowas hat Engine X nicht. Das heißt, wenn du solche Konfigurationen machen willst, musst du das in der Konfigurationsdatei von Engine X machen, die aber zentral liegt, wo du jetzt in einem Web-Posting im Regelfall nicht rankommst. Du kannst halt keine Datei in das Unterverzeichnis legen, um irgendwelche Konfigurationen zu überschreiben. Und wenn du jetzt keinen tollen Zugriff auf dein Server hast, also keinen SSH-Root, irgendwas Zugriff, dann kommst du im Regelfall nicht an die Engine X-Conf dran. Und wenn du da nicht rankommst, hilft dir das alles nicht. Insofern haben die Plugins dann damit ein Problem, die geben dir dann zwar Code aus meistens und sagen, dass ist der Code jetzt basierend auf deinen Einstellungen, bitte füge den in die Engine X-Conf ein. Kannst du meistens aber nicht, weil du nicht an diese Konfigurationsdatei rankommst. Wenn du einen guten Engine X-Hoster hast, dann hat der das aber sowieso drin. Also, dann hat der solche Vorkonfiguration sowieso gemacht. Das ist jetzt, wie gesagt, das ist kein Voodoo, das ist auch das P&P im Upload-Zeich. Wenn da jetzt ein Web-Past-spezifischer Hoster ist mit Engine X-Konfigurationen, natürlich hat der sowas auch in seiner Engine X-Conf dran stehen. Es geht bei all den Sachen eigentlich darum, alles auf den selben Level zu bringen und nur sicherzustellen, dass die Einstellungen da sind. Und als Zweites, um die Frage noch zu beantworten, was das auf meine Tools sind, nutze ich gerne eine Web-Application Firewall. Also etwas, was zum Beispiel auch Word-Fans anbietet. Ich mag die nur nicht von Word-Fans. Ich mag die besser. Und ich nutze dafür ein Pluckin, das heißt Ninja Firewall. Alles, was ihr auf meinem Rechner seht, vergesst ihr sofort, wenn es nicht damit zu tun hat, worüber ich rede. Nicht, dass hier irgendwie gleich Kundendaten auftauchen oder so, dann haben wir hier den Daten schon super gau. Das ist die Ninja Firewall. Die hat mittlerweile doch 20.000 aktive Installationen. Sie wird immer mehr wahrgenommen. Ist ein schönes Produkt. Ist nicht WordPress-spezifisch, also nicht zwingend. Gibt es also auch für andere Applikationen. Im Prinzip ist dieses Pluckin nur die Hülle, um es innerhalb von WordPress zu konfigurieren. Eine Firewall, die sich vor jedem PRP Aufruf hängt und nach gewissen Regeln prüft, was dann da so ankommt und entsprechend blockt, wenn es es doof findet. Und ich kann bestätigen, dass das hilft. Hilft übrigens nichts bei Rateboxes, weil mal abgesehen davon, dass diese Spezielle da nicht so richtig funktioniert, aus Gründen, die vollkommen nachvollziehbar sind, man braucht das Ding aber bei denen auch zum Beispiel nicht. Weil da Hosterseite schon was passiert. Ich habe mir gedacht, wenn der Hoster all solche Spezialitäten nicht anbietet. Wir haben Kunden, von denen wir wissen, dass die irgendwelche Urals WordPress einsetzen aus verschiedenen Gründen auch darauf bleiben. Und wir wissen, dass es Sicherheitslücken gibt in dem System und mit so einer Firewall-Installation davor, trotz Sicherheitslücke, passiert dem System halt nichts, weil die Firewall es blockt. Das ist für den Otto-Normal-Anwender unter Umständen etwas schwieriger zu konfigurieren ist. Das heißt, dieses Produkt ist mit Bedacht einzusetzen. Wer da also sich jetzt nicht so sofort heimisch fühlt, kann sich auch etwas mehr kaputt machen, als das er sicher macht. Deswegen, ich habe eben gesagt, WordPress-Items haben ihre Berechtigung, weil sie für den Endbenutzer unter Umständen ein einfacheres Benutzererlebnis bieten für die Einstellungen, wie sie brauchen. Ich wiederhole nochmal fürs Video. Bei dem Shop zu viele Anmeldungen, Lock-In-Versuche mit nicht existenten Benutzern oder entsprechend falschen Lock-Ins ist dann eine Sperrung der IP-Adressen derjenigen, die sich ein versucht haben, einzulocken. Das halte ich nur dann für notwendig, wenn die Anzahl der Lock-In-Versuche so massiv ist, dass tatsächlich die Performance in die Knie geht. Wenn man tatsächlich merkt, dass andere Menschen sich nicht mehr einlocken können, weil der Server zu hoch belastet ist. Bei einem Nicht-Shop würde ich an der Stelle ein Basic-Off, also ein HTXS-Passwort-Schutz vor die Lock-In-Seite hängen, weil damit das Ganze dann schon auf höherer Ebene abgefangen wird, sodass da nicht PRP und WordPress und Datenbank belastet wird für die Lock-In-Versuche. Bei dem Shop ist das ein bisschen blöd, weil der Shop als solches braucht natürlich den Lock-In und da kann man keinen HTXS-Passwort-Schutz vorsetzen. Mit den IP-Adressen ist das allerdings so eine Sache. Also wenn es geklappt hat, ist es gut. Wenn man an IP-Adressen rundläuft und welches Skript da gerade wie attackiert, ist es tatsächlich so, dass die IP-Adressen so schnell rotiert werden, dass man damit dem Eintragen eigentlich nicht mehr nachkommt. Wichtig ist auch zu erkennen, also diese Lock-In-Versuche auf einer WordPress-Seite passieren jeden Tag auf jeder Webseite andauernd. Ihr müsst nicht glauben, dass eure Webseite bei eurer Webseite das nicht passiert. Ihr habt dann nur noch nichts installiert, um das zu sehen und lasst euch bitte keine E-Mails schicken und eine Lock-In-Versuche. Weil dann habt ihr irgendwann einfach mal ein Problem mit Hunderten von Mails oder so. Es ist vollkommen egal. Wenn euer Passwort sicher ist, ist alles gut. Also wenn ihr ein starkes Passwort habt. Außer, und das ist der einzige Fall, wo man dann reagieren muss, wenn tatsächlich die Performance des Servers so in die Knie geht aufgrund der massiven Lock-In-Versuche. Und wenn es kein Shop ist, Basic-Orth davor, hat man mehr Ruhe und wenn es dann immer noch nicht hilft, dann muss der Hoster ran. Ja, man kann das Lock-In kann man umbenennen, dass Hilf hilft nur eingeschränkt. Also das ist hilft bei ein paar, also je nachdem, welche Script-Kiddie mit welchem Skript wie attackiert, kann es helfen. Bei den Schlauren hilft es wieder nicht. Also es ist halb auch mal die Seite SSL zu verschlüsseln. Weil es schlechte Lock-In-Script-Kiddie Skripte gab, die nur HTTP-Konten nicht verstanden haben, damit nicht mehr agieren konnten. Ich sage mal so, das wird aufhören. Auch die schlechten werden immer besser. Und wenn es mal kurzfristig halb, und mein HTTPS spricht sowieso nichts gegen, aber wenn es mal kurzfristig halb, irgendwann hilft es nicht mehr. Bei einem Shop tatsächlich, wo man das offen halten muss, als Lock-In muss man da ein bisschen rangieren und tatsächlich mit IP-Bereichen Blocken schauen, dass man klar kommt. Wie gesagt, das kann schwierig sein, weil die IP-Adressen teilweise so stark rotieren, dass man da nicht hinterher kommt. Wenn man Glück hat, klappt auch das dann. Wie gesagt, kann gut gehen. Ich bin ansonsten kein Freund davon zu viel am Lock-In-Screen zu tun. An Sicherheitsmaßnahmen, Capture ein oder irgendwelche Zusatz-Ding. Natürlich, 2-Faktor-Otentifizierung funktioniert immer, hilft auch, weil 2-Faktor, 2-Faktor, BAM, kann der Script-Gedie machen, was es will. Ist immer gut. Ob nun über Google Authenticator oder ob es tatsächlich bei Hardware Token oder was auch immer, ist immer eine gute Sache. 2-Faktor, das Plug-In dafür, was man standardmäßig verwendet, sollte 2-Factor sein. Weil 2-Factor ist das Feature Plug-In, was potenziell, jetzt muss ich mir nur mal gucken, welches, das da ist. Genau, das ist das. Feature Plug-In bedeutet, man hat die Hoffnung, dass es irgendwann tatsächlich mal im WordPress Core landet mit dieser Funktion. Wo war ich sonst, bevor mir das Thema 2-Factor einfiel? Dass man nicht zu viel am Lock-In-Bereich macht, weil die allermeisten Leute sichern den Lock-In-Bereich extrem gut ab. Da machen sie alles. Alles wird auf dem Lock-In-Bereich. Das heißt, es gibt die Sicherungsmaßnahmen, alle Plug-Ins, die es gibt, richten sich auf den Lock-In-Bereich. Es gibt einen schönen Blockbeitrag im Internet von einem Kollegen, der schrieb mal, dass es die Weltblechhütte mit der Stahltür. Danke für diese Stahltür, der Rest ist eigentlich schlimmer. Wenn man ein sehr gutes Passwort hat, sehr gut heißt, hieß mal mindestens 12 Zeichen, und ihr müsst nicht komische Sonderzeichen drin haben. Wenn sie drin sind, ist es natürlich noch schwieriger, es zu knacken, aber bei 20 Zeichen könnt ihr auch 20 normale Zeichen nehmen. Vielleicht so ein bisschen Großkleinschreibung und Zahlen helfen natürlich schon. Aber wenn man in der Größenordnung unterwegs ist, hilft es. Natürlich habt ihr für jedes System, wo euch einlockt, ein anderes Passwort, und natürlich könnt euch das alles nicht merken. Deswegen habt ihr ein Passwort-Safe, also so ein Software, mit dem ihr alle eure Zugangsdaten verwaltet. Und dann ist es auch vollkommen egal, wie kompliziert das Passwort ist. Dann ist man gut unterwegs. Und wenn das jeder Benutzer hat, im WordPress, dann braucht man keine Stahltür mehr, weil dann ist das Ding relativ safe. Und mit zwei Faktoren sowieso, dann ist es durch. Das ist, ob man das jetzt nur für Admin-Benutzer machen muss oder ob man das auch für normale Redakteurszugänge machen muss. Das Ding ist ja folgendes. Du hast natürlich recht theoretisch, willst verhindern, dass jemand einen Admin-Zugriff hat. Und dann könnte man auf die Idee kommen, dass das Absichern mit starkem Passwort für Admin-Zugänge reicht. Und wenn jemand als mit einem Redakteurszugang reinkommt, hat er weniger Möglichkeiten, irgendwas kaputt zu machen, dann kannst du relativ schnell wieder was herstellen. Aber, ich meine, es gibt genügend Beispiele, wo Angreifer nicht eine Sicherheitslücke ausnutzen, sondern eine Kombination von mehreren Sicherheitslücken, um ihr Ziel zu erreichen. Und wenn jetzt jemand aus irgendeinem Grund Glück hat und mit einem Redakteurslog reinkommt, und dann gibt es aber eine Sicherheitslücke in dem WordPress-System, welches nur als eingelockter Benutzer ausgeführt werden kann. Und dann eine Privilege-Eskulation, heißt der Fachbegriff dafür, dass du quasi mehr Rechte hast, als du eigentlich haben solltest. Dann hat er plötzlich Admin-Rechte. Und hätte der Redakteur ein sicheres Passwort gehabt, wäre der Typ erst gar nicht da hingekommen, diese Erweiterung der Benutzer-Zugriffsrollen- Erlaubnisse auszunutzen. Also sinnigerweise für alle um definitiv sicher zu sein. Weil man nicht weiß, was noch dazwischen hängt und passieren kann. Also die Frage war jetzt, wie man so mit den Kunden umgeht, wenn die sich zu lasche Passwörter vergeben. Also wenn jetzt jemand in WordPress ein lasches Passwort angebt, dann muss er ja zumindest per Checkbox bestätigen, dass er akzeptiert, dass das ein schwaches Passwort ist. Das sollte eigentlich für jeden Kunden ausreichend Warnung sein, diese Checkbox jetzt nicht anzuhaken und nicht einfach auf OK zu klicken. Ich kann jetzt ohne, dass ich jetzt programmatisch irgendwas tue, dem Kunden erstmal nicht davon abhalten, dass er sich so ein Passwort vergeben. Wenn er dieses Häkchen setzt und ein dreistelliges Passwort vergeben, hat das getan. Natürlich könnte man da eingreifen und sagen, es geht nicht. Und mal als Beispiel iThemes Security, auch wenn ich das sonst nicht generell dann jetzt dafür empfehle, aber das hat zum Beispiel so eine Funktion, weil ich ja Nutzer bitte ein starkes Passwort verwenden. Das heißt, da kannst du das dann nicht tun. Es gibt es auch als Einzellösung. Da muss ja dann nicht ein iThemes sein. Also wenn der Kunde unbelehrbar erscheint und ich eine dauerhafte Verantwortung für die Seite habe, würde ich das tun. Also sichere Passwörter erzwingen. Wenn ich keine dauerhafte Verantwortung für die Seite habe, ja, dann muss der Kunde seine Fehler selber machen. Aber ja. Also das ist das vorstrong Passwords, mit dem man halt sicherstellt, dass es ein sicheres, starkes Passwort sein muss. Was man einstellt, weiter geht es nicht. Das weiß ich nicht. Also die Frage war, ob dieses Plug-in auch die Heverbean Pond Datenbank abfragt. Das ist so ein Datenbank von gelegten Passwörtern, wo man für seine E-Mail-Adresse gucken kann, ob der eigene Datensatz da irgendwie mal in irgendeinem Datenlieg drin war. Weswegen man wenn man sich da selbst prüft, sich überlegt, dass man da Maßnahmen ergreift. Und die Datenbank halt dafür da ist, dass man sagt, hier passen wir auf das Passwort. Also das ist jetzt so bekannt. Das nimmst du mir mal lieber jetzt nicht. Weil das in so einer Datenbank drin ist und automatisch häufig bei solchen Log-In versuchen, während die Password da durchgegangen. Ich weiß, dass es welche gibt. Das Plug-in kannte ich jetzt auch noch nicht. Aber das scheint es nicht zu tun, zumindest nicht nach dem schnellen Durchskrollen. Gibt es aber, ich müsste aber selber jetzt nachgucken, welches das war. Ich wollte doch kein Lego zeigen, verdammt. Seite lesen natürlich. E-Mail-Adresse eingeben und dann sagen die dir du warst drin. Und dann wo, genau, mit welchen Leaks man mit dabei war. Die Frage war, ob WordPress-spezialisierte Hoster sicherer sind als nicht WordPress-spezialisierte Hoster. Nein. Also nicht per se nur, weil sie WordPress optimiert sind. Man hat die Hoffnung, dass WordPress-spezialisierte Hoster sich nicht nur um WordPress-spezifische Performance, sondern auch um WordPress-spezifische Sicherheit kümmern, wenn sie ihr WordPress-spezialisiertes Angebot einrichten. Der See an sich kann man das aber so nicht sagen. Das weiß man nicht. Auch wenn ein Hoster nicht WordPress-spezialisiert ist, sagt das erstmal noch nichts über seine Sicherheitsmaßnahmen aus und wie gut er die im Griff hat. WordPress-spezifisch oder nicht. Er kann ja trotzdem in seiner Web Application Firewall WordPress-spezifische Security Rules drin haben. Genau. Manchmal auf eigenen Infrastruktur-Ebenen und manche halt weniger. Manchmal kann man das am Preis ablesen und manchmal auch nicht. Das kann man so von außen im Regelfall nicht verallgemeinern. Es gibt welche, die machen das. Es gibt welche, die machen das weniger. Es gibt welche, die sind davon WordPress-spezialisiert. Es gibt welche, die müssen das nicht sein und machen es trotzdem. Das ist Querbede. Das ist ein Es ist tatsächlich leider heutzutage immer noch so, dass, wenn man sich die Top 20 Passwords anguckt, dass man immer noch erschrocken ist, welche Passwörter, welche Menschen wann wie vergeben. Und ich sage auch, ich kriege ja Passwörter von meinen Kunden zur Verfügung gestellt, um da Websites und FDP-Zugänge und Hosting-Zugänge. Und ich denke mir zwischendrin auch immer, geiles Passwort, schade. Die sind sehr offensichtlich regelmäßig und das darf man jetzt bei solchen Shop-Loggins auch erwarten. Dass Leute solche tollen Passwörter vergeben. Es geht ein bisschen auch in die Richtung, was ich eben zu Deadlift gesagt habe. Muss das denn für alle sein oder nur für die Admins oder für die Redirekteure nicht? Die WooCommerce Shop-Logins sind zum Beispiel ja dann auf quasi Abonnenten-Ebene. Das ist natürlich die geringste Rolle. Da ist es noch unwahrscheinlicher, dass man so eine Privilege-Escalation hat, aber sie ist nicht ausgeschlossen. Also, dass so jemand mit so einem Blog in irgendwelche Sicherheitslücken ausnutzt, um höhere Rechte zu erzielen, ist wahrscheinlich ja im Umfeld von Rollen, die sowieso irgendwelche Rechte haben. Aber auszuschließen ist das nicht. Mit so einer Abwägung tue ich mir schwer. Ich mich schwer, da kann man jetzt nicht einfach so pauschal sagen. Ich tendiere immer zu den starken Passwörtern, weil ich glaube, man muss die Leute hin und wieder auch mal ein bisschen erziehen. So schwer ist das gar nicht mit den starken Passwörtern. Du hast aber natürlich recht, wenn du jetzt deine Konversion nicht komplett zerstören willst und dir auch irgendwie Geld verdienen willst und bei deinem Käufer darauf bestehst, dass er ein starkes Passwort gibt, dann hat er keinen Bock mehr nach dem fünften Versuch und kauft irgendwo anders. Klar ist ein anderes Thema. Aber irgendwo muss man so einen Mittelweg geben. Also alles unter zwölf ist unsicher. Also alles unter zwölf kannst du auch keins vergeben. Also die Frage war, was für der Mittelweg ist, also wie viele Stellen Passwort haben soll. Also alles unter zwölf kannst du weglassen. Dann brauchst du auch keins zu machen. Reine Mathematik. Also, naja, du musst halt überlegen, das kommt aber ein bisschen drauf an. Du kannst natürlich nach fünf Fehlversuchen einer IP und so, kannst wieder den Locken, dann kannst du das verzögern. Aber es geht einfach darum, wie viele Passwörter mit einem reinen Brute Force, also einfach durchprobieren, wie lange brauchst du, um das Passwort zu knacken. Und lokal geht das natürlich besser. Also da müsstest du die Datenmagnetik haben und kannst lokal. Dann kannst du tausende von Abfragen schnell machen. Wenn du das über das Internet machst, bist du natürlich so ein bisschen auch an die Latents gebunden, hast du vielleicht so fünf Fehlversuche und dann block ich dich oder so. Also da braucht es dann schon länger. Aber so alles unter zwölf ist, hm, acht ist ja häufig der Standard, so für das Passwort mindestens acht Zeichen haben muss. Das ist schon schwach. Und ich sage 20 und irgendwo dazwischen solltest du dich bewegen. Also ganz einfach, um die Frage zu beantworten, also wer Passwörter unter acht Zeichen zulässt, braucht keine Passwörter mehr. Also das ist das Mindeste, was man einstellen sollte. Also irgendeine Mindestlänge. Da muss man ja nicht auf Buchstaben ziffern irgendwas kombinationen gehen, aber eine Mindestlänge, dann wären wir ja schon gut dabei. Da und dann da. Es geht um die Frage Lock-in über Social Media Profile. Ich mag das ja allein aus Datenschutzgründen schon nicht. Da muss ich ja noch gar nicht mit der Sicherheit argumentieren. Ich mag das ja schon alleine, weil die reine Sicherheitsfrage, es ist gar nicht so unsicher von der Prozedur her. Das ist jetzt kein Scheunentor. Aber sich darauf zu verlassen, dass da noch ein Dritter mit dabei ist, das halte ich grundsätzlich für eher schwierig, unabhängig jetzt von einem rein technischen Prozess. Ich würde das nie tun, ich mag das nicht, und ich würde das auch keinem empfehlen. Na ja, also die Frage ist, für wen man das unterbinden kann. Also es gibt ja erstmal in WordPress diese Funktion nicht per se. Die ist ja erstmal nicht da. Das heißt, man muss irgendwie ein Plug-in installieren um diese Funktion möglich zu machen. Und dann muss man halt gucken, ob das Plug-in eine entsprechende Möglichkeit hat, das nur für einzelne Rollen freizuschalten. Und dann kann man das da zum Beispiel nur für die Shoppen-Nutzer machen. Ja, könnte man machen. Aber ich persönlich würde ja generell von abraten. Aber ich weiß, so aus Bequemlichkeitsgründen ist das natürlich eine Sache, die das ein oder andere Mal sehr beliebt ist. Ja, ja, ich weiß. Dann sind wir auch schon wieder fertig. Alles andere müssen wir dann im Nachgang machen. Ich darf ja nicht überziehen, obwohl wir später angefangen haben. Die Frage habe ich nicht verstanden. Na ja, also die Frage war mit der Passwort-Registrierung. In WordPress ist es ja so, wenn du dir ein Benutzer anlegst, dann gibst du entweder dein Passwort mit ein und dann hast du dir selber dein Benutzer angelegt, wenn du die Rechte hast. Aber wenn dir jemand anderes ein Benutzer anlegt, dann schickt WordPress ja einen Link an den jeweiligen, an den neuen Benutzer, aber ohne Passwort drin. Da ist ja nur eine URL drin, klickst du drauf und tippst dann dein eigenes Passwort ein. Das heißt, in dieser E-Mail steht niemals ein Passwort drin, sondern nur so ein Hash. Und der ist, glaube ich, auch nur viel zu kurz gültig. Also wenn ich sauber von meinen Kunden kriege und das einen Tag vergesse am nächsten Tag versuche, ist er meistens schon wieder abgelaufen. Dann kann man über die Passwort-Vergessen-Funktion dasselbe wieder... Also im Prinzip ist das dasselbe wie die Passwort-Vergessen-Funktion. Man legt ein Benutzer an und der hat quasi gar kein Passwort und der Weiß nur seinen Benutzer-Namen und muss da die Passwort-Vergessen-Funktion nutzen. Das ist im Prinzip die Abkürzung. Also Passwort, da werden nicht verschickt. Ja, ist tödlich. Also ich meine Entschuldigung. Die DSGVO sagt mittlerweile ja, dass wir unsere E-Mails aus unseren Webseiten heraus Transportverschlüssel verschicken sollen. Ich werde 90 Prozent haben es nicht gemacht. Das bedeutet aber immer noch nicht, dass die E-Mail selbst verschlüsselt ist. Das ist ja nur der Transportweg. Das ist offen wie ein Scheuentor. Das Schlimme ist ja, sollte es dann jeweils dich sofort einlocken und dein Passwort ändern. Egal was passiert. Das machen die wenigsten, genau. Das gemeine ist, bis du das tust, könnte theoretisch jemand anderes das Ganze schon abgegriffen haben. Die Frage ist, die du dir erstellen musst, ist, wenn du dann selber dich nur einlocken kannst, also der Bösewicht, dein Passwort nicht geändert hat in der Zwischenzeit, war jemand eingelockt als ich und welche Daten konnte er einsehen? Das ist aber dann, da bewegen wir uns dann irgendwann auf einer fiesen Ebene, über die wir diskutieren. Also ein Passwort da verschicken ist generell eigentlich etwas, was ich sehr, sehr schlecht finde. Ich gebe aber zu, dass es Stellen in Prozessabläufen gibt, in denen das fast unvermeidbar ist. Leider. Auch gerne schon mal, es gibt Hoster, wir kommen Mails mit 20 Passwörtern drin. Also das ist ihr Kundenbackend Passwort, das ist ihr FDP Passwort, das ist ihr E-Mail Passwort, das ist das Passwort. Und die Mail bewahren die Kunden dann auch ganz vorsorglich auf, weil die Passwörter braucht man ja alle 20 Jahre mal. Dann brauche ich die Passwörter, dann leiten die mir die Mail weiter, die haben die ja noch im E-Mail-Programm liegen und die ganzen Passwörter stimmen auch alle noch. Das ist nicht so schön, ist nicht so praktisch. Sollte man so nicht tun, also man muss die Passwörter nicht ändern. Sie stehen da in einem Dokument drin, wunderbar, ist alles gut. Das ist suboptimal. Und wenn man es macht, dann muss es eigentlich so sein, dass beim ersten Log in man nichts machen kann, außer das Passwort ändern. Also wenn man nicht das Passwort ändern kommt man zu nichts anderem. Das ist dann die einzige Wahl in der Applikation, jetzt um das zu vermeiden. Aber auch das ist, bitte, ähnlichen WordPress. WordPress verschickt die Mails aber ja auch nicht. Das ist nicht das irgendein Plug-in, wenn man Pech hat oder so, aber WordPress selbst tut das nicht. Wir reden ja so mal ganz allgemein über Applikationen. Das muss man sicherstellen. Dass man nichts anderes tun kann, außer das Passwort ändern. Wie gesagt, bei WordPress sind wir auf der Seite, dass es nur links mit Hash skips, dass man sowieso nur ein Passwort setzen kann. Generell. Da kommt noch eine Hand. Ich komme mich über Zieh mal noch 2 Minuten. So, bitte. Wir haben hier einen Firewalls-Vorschalter auf DNS-Ebene. Cloudflare, Sugary, was es da so alles gibt. Ja, technisch gesehen vernünftige Lösung. DSGVO, ja, wo man was, warum, woher leitet, muss man halt entsprechende Regelungen treffen. Das ist aber leistbar. Kann man machen. Ist aber natürlich Profilevel irgendwo. Also das macht Otto Normalbürger. Also auch wenn die Anbieter, die das machen, einem suggerieren, dass das Kinder leicht ist und man es jederzeit tun sollte. Es ist eher etwas Profilevel, man muss auch wissen, was man tut. Also auch DNS-Manipulation ist ja nicht für jeden Menschen so offensichtlich, um was es da geht. Also für eine stinknormale Webseite mit stinknormalem Besucheraufkommen ist das jetzt nicht so relevant. Also das ist nicht die erste Maßnahme, die einem da einfällt. Das ist eher, da sind wir auf so einem höheren Eben unterwegs und dann kann man sich über solche Lösungen Gedanken machen. Aber im Normalfall, wenn jetzt ein Otto Normalbürger mit einem Otto Normal Webseite zu mir kommt, wäre das nicht die erste Idee, die ich hätte. Jetzt glaube ich, werde ich geschlagen, wenn ich noch weiter mache. Okay, dann hören wir auf. Bitte. Nee, ich habe keine Folien. Wer es noch Fragen hat.