Ruhig Blut bei Updates

Neulich war es soweit, ein Update von WordPress mit fatalen Folgen für den einen oder anderen.
Das Gute ist des Besseren Feind, heißt ein Sprichwort, aber neu ist nicht automatisch besser oder gut.
Abgesehen von einigen Wenigen die ständig die neuesten Versionen testen müssen, gibt es für die Meisten wohl keinen Grund, gleich die neueste Version zu installieren. Denn genau genommen betätigt man sich damit als Betatester, wie auch im oben angemerkten Fall.
Und gerade bei Kundenprojekten kann man es sich eigentlich nicht leisten, ohne einen gewissen Abstand die Seiten der Kunden gleich auf die neueste Version upzudaten [schönes Wort]. Erfahrene Admins warten immer, bis sich eventuelle erste Fehler zeigen und diese ausgeräumt sind.

Das ist ein wenig so wie mit den Aktien, bei denen man die Füße still halten muss, wenn sie mal rauf und runter gehen.
Und WordPress hat das zudem schön eingerichtet mit den Sicherheitsupdates, die im Hintergrund automatisch laufen und auch etwas ältere Versionen versorgt. Zur Not greift man manuell ein und löscht, wie in diesem Fall, die benannte Datei aus dem Theme.

Inzwischen ist es so weit, dem WordPress Team kann man dabei vertrauen, gibt es nach sehr kurzer Zeit ein neues Update bei dem alle Fehler bereinigt sind und die Probleme nicht mehr auftauchen [zumindest bei mir nicht].
„Ruhig Blut bei Updates“ half auch hier, sich viel Arbeit und Nervengeld zu ersparen.

Veröffentlicht in CMS | Getaggt | Hinterlasse einen Kommentar

Tipps für sichere Usernamen in WordPress

Seit einiger Zeit werden WordPress-Seiten zum Teil sehr massiv mit Brute-Force Methoden angegriffen, um das Passwort „zu erraten“ für den Admin oder andere User.
Meistens laufen die Angriffe auf „admin“, weil das der erfolgversprechendste User in WordPress Installationen ist, denn erstens war „admin“ früher fest als Administrator-Login vorgeschrieben und zweitens handelt es sich dabei um einen User mit Administrator-Rechten (kann auch PHP-Dateien intern editieren, für Einbrecher also sehr interessant und bösen Code einzubauen) und drittens lassen auch viele den „admin“ als User stehen, obwohl WordPress seit einiger Zeit den Admin-Login bei der Installation frei ändern lässt.
Später kann man den Usernamen (Login-Name) nicht mehr ändern.

Das Problem mit dem Standard-Admin:

Es gibt immer wieder zu lesen, dass man doch bitte aus Sicherheitsgründen nicht mehr „admin“ oder „Admin“ also ersten Usernamen nehmen solle, sondern etwas anderes.
Für andere CMS mag das ja einen Sicherheitsgewinn ausmachen, aber nicht für WordPress, denn die Entwickler haben sich gedacht, man könne sich doch den Usernamen über das Web anzeigen lassen mit diesem Link: http://www.123-blog.de/?author=1

/?author=1 zeigt den URL-tauglichen Usernamen des Nutzers mit der ID=1 an, also immer der User, der bei der Installation als erstes eingetragen wird, nämlich der Administrator mit allen Rechten.
Man kann das Spielchen so fort führen indem man einfach alle Nummer durchprobiert und schaut, ob Antworten kommen, und tatsächlich fand ich in den Logfiles die Anfragen mit allen Nummern bis 99 durch die Angriffs-Programme (die Angreifer sind meistens automatische Programme).

Die Antwort vom WordPress-Programm sieht dann z.B. so aus: http://www.123-blog.de/author/admin
Juchhu„, sagt sich das Angriffsprogramm, „ich hab den Usernamen!“ und tatsächlich stimmt es in den meisten Fällen auch, weil der Standard-Username eben „admin“ lautet.

Es mag durchaus Sinn gehabt haben, warum man so einfach den Login-Namen herausfinden kann, denn als WordPress noch jung war, war von solchen Angriffen wie sie heute statt finden, kaum die Rede und WordPress wollte vielleicht eine einfach Möglichkeit bieten, wie man automatisch den Autor herausfinden und auf alle Beiträge dieses Autors verlinken kann.
Inzwischen aber haben sich die Möglichkeiten für die Angreifer erheblich verbessert, dank der schnellen Datenleitungen und Server können die Angreifer tatsächlich einfach alle möglichen und unmöglichen Passwörter durchtesten beim Loginversuch mit dem User „admin“.
Steter Tropfen höhlt den Stein und irgendwann passt vielleicht zufällig ein Passwort und schon ist eine weitere WordPress-Seite gehackt, ganz automatisch und ohne Mühe für den Angreifer.

Der oft gelesene Ratschlag, den „admin“ zu löschen und einen neuen User einzutragen oder bei der Installation einen anderen Namen zu wählen, nützt meistens nichts. Warum?
Weil WordPress automatisch den gewählten Usernamen nimmt und daraus einen URL-tauglichen Namen erzeugt und in die Datenbank speichert. Somit kann das Angriffs-Programm ganz einfach mit dem Author-Link (der mit dem Fragezeichen) den Usernamen wieder heraus finden. Damit ist nicht wirklich viel gewonnen und man wägt sich in trügerischer Sicherheit.

Aber es gibt Unterschiede, die man nutzen kann:

Da WordPress einen URL-tauglichen Namen generiert, dürfen darin keine Sonderzeichen und keine Umlaute vorkommen. So könnte man doch auf den Gedanken kommen, den Usernamen „ädmin“ statt „admin“ zu wählen, mit einem ä am Anfang. Aber WordPress lässt für die Wahl des Usernamen keine solche Sonderzeichen zu, wir ahnen warum (soll ja URL-tauglich werden und hat vielleicht noch historische Gründe und wegen lokaler Unterschiede in der Tastatur usw.) Es wäre zu schön gewesen, hätte WordPress aus dem „ädmin“ einfach ein „admin“ gemacht. Auch z.B. ein # im Namen wird nicht akzeptiert.

Es gibt aber noch mehr, was man ausnützen kann, denn Großbuchstaben werden klein gemacht und Leerzeichen werden mit einem Bindestrich versehen. An dieser Stelle sei vermerkt, dass ein Leerzeichen im Usernamen alleine keine besondere Sicherheit darstellt, weil es für Programmierer leicht ist, beim Antreffen eines Bindestriches auf ein Leerzeichen im Login-Namen zu schließen und das entsprechend zu programmieren.
Aber eine Kombination aus beidem könnte doch deutlich mehr Sicherheit bringen:

  • KlausMaus wird zu klausmaus
  • Klaus Maus wird zu klaus-maus
  • klauS MauS wird auch zu klaus-maus

Wir sehen hier, dass man mit der Kombination von Groß- und Kleinschreibung an verschiedenen Stellen (und vielleicht noch mit Leerzeichen) durchaus einiges zu Rätseln für das Angriffs-Programm aufgibt. Alleine das zu knacken könnte schon dauern, je nachdem wie verschachtelt man das schreibt: KlaUsmAuS-zUhauS und das Angreifer-Programm dürfte alle möglichen Kombinationen durchprobieren müssen, bis der richtige Login-Name mal getroffen wäre.

Und nun stelle man sich das noch in Kombination mit einem langen und sicheren Passwort vor, mit Sonderzeichen, Zahlen, Groß-Kleinschrift. Das dürfte eigentlich kaum noch zu knacken sein, es sind vermutlich zu viele Kombinationen.
Das muss man dann aber für alle User so durchführen, denn es werden auch die anderen User gefunden und darauf angegriffen.

Und dann bitte nicht für den „Angezeigten Namen“ (display name) den original Login-Namen stehen lassen!! Sonst war alles umsonst.

Es geht aber noch besser:

(auf eigenes Risiko* für Datenbankversierte User)

Wer meinen Link oben ausprobiert hat, wird sehen, dass tatsächlich „admin“ angezeigt wird.
Bin ich etwa so leichtsinnig, und habe als Usernamen nur admin oder Admin gewählt?
Nein, bin ich nicht, es ist ein Honeypot (Honigtopf), extra für die lieben, dummen Angriffsprogramme so stehen gelassen.
Einem so leckeren Honigtopf können diese Programme gar nicht widerstehen, sind sie doch vornehmlich auf „admin“ getrimmt.
Was habe ich gemacht?

In der Datenbank gibt es in der Tabelle wp_users (man sollte hier durchaus bei der Installation auch einen anderen Präfix wählen statt „wp“) zweierlei Spalten für Login-Name und eben diese URL-taugliche Version.
In der Spalte user_login steht der tatsächliche Login-Name (Username) und in der Spalte user_nicename steht eben dieser URL-taugliche Name. Den trägt WordPress automatisch ein und den kann man nicht vom Backend aus ändern.
An dieser Stelle noch die Anmerkung: user_nicename ist nicht der Nickname, auch wenn es sich ähnlich liest, es ist eher ein Alias-Name für technische Dinge wie eben die URL.
Da WordPress seit einiger Zeit es ermöglicht, einen Nicknamen einzutragen, könnte man das miteinander verwechseln.
Aber zum einen taucht der Nickname, den man selbst wählen kann, gar nicht in dieser Tabelle auf, sondern in der Tabelle wp_usermeta.  Und zum anderen kann man diesen Namen mit Sonderzeichen und Umlauten verwenden.
Merke: user_nicename ist nicht Nickname.

Nun, da WordPress mir nicht ermöglicht, den user_nicename zu ändern, mache ich es einfach über die Datenbank, aber anders herum.

  1. Ich installiere WordPress mit Usernamen „admin“.
  2. Nach der Installation gehe ich in die Datenbank, und ändere direkt in der Tabelle den Usernamen in user_login (nicht den user_nicename) von „admin“ auf irgendwas anderes (was ich garantiert nicht verrate), ohne Sonderzeichen oder Umlaute.
  3. fertig

Das war’s, mehr ist nicht.
Kann man auch jederzeit nachträglich machen.
Für die dummen Angriffsprogramme bleibt der angezeigt Autor weiterhin „admin“ (was ungemein verlockend ist).
Wordpress scheint trotzdem ganz gut zu funktionieren, obwohl diese beiden Namen ganz unterschiedlich sind.
Und ich logge mich dann unter dem neuen Namen ein statt mit admin, und es funktioniert prächtig,
* (hoffentlich ändert das WordPress nicht irgendwann mal, aus „Sicherheitsgründen“ womöglich, denn dann könnte es schwer werden, sich noch einzuloggen).

Tatsächlich laufen bei mir immer noch täglich sehr viele Angriffe auf den Namen „admin“, aber die Chancen sind gleich Null, weil es einen „admin“ als User eben darum nicht gibt.
So oft ich auch die Login-Fehlversuchs-Statistik ansehe, es lautet fast immer auf „admin“. Tja, mit Honig fängt man nicht nur Fliegen, sondern auch Angriffs-Programme.
Um die Angriffe nicht ins Uferlose treiben zu lassen, habe ich zusätzlich noch ein Plugin installiert, das fehlerhafte Loginversuche begrenzt und eine Zeit lang sperrt. Trotzdem kommen noch täglich 20 bis 100 Sperrungsmeldungen (die Loginversuche sind also viel mehr).

Hatte ich schon erwähnt, dass das Passwort natürlich trotzdem sicher sein sollte?

Um die lästigen Loginversuche abzuwenden, könnte ich auch einfach noch das Admin-Verzeichnis mit Usernamen und Passwort sichern, mittels .htpasswd zum Beispiel. Dann müsste ich mich zwar immer zweimal einloggen um ins Backend zu kommen aber dafür kämen die Angreifer erst gar nicht mehr zum Login-Bereich. Das sei jedem geraten, der seine Seite sicherer haben will.
Ich tue es nur nicht, weil ich auf dem Laufenden sein will, was sich da so tut.

Veröffentlicht in Allgemein, Wordpress anpassen | Getaggt | 3 Kommentare

Was tun gegen die vielen Angriffe auf WordPress-Seiten?

Die Angriffe auf meinen Blog hier reißen nicht ab. Inzwischen nicht mehr nur am Wochenende, sondern jeden Tag die gleiche Leier. Anderen geht es aber auch so ähnlich, wie hier zu lesen ist: http://www.tagseoblog.de/hacker-angriff-auf-tagseoblog-und-was-ich-dabei-gelernt-habe
Inzwischen leite ich alle Benachrichtigungen (per Email) von Angriffen direkt in meinen Junkmail-Ordner. Die Löscherei ging mir auf die Nerven, aber ganz auf die Info was gerade läuft, wollte ich auch nicht verzichten.

Sergej Müller hat inzwischen einen aktuellen Artikel verfasst, was man gegen Angriffe auf die XML-RPC Schnittstelle von WordPress tun kann: http://cup.wpcoder.de/wordpress-xmlrpc-schutz/

Viele wissen vermutlich gar nicht, dass es diese Schnittstelle gibt und noch weniger, wie man sie abschalten könnte. Die Anleitungen von Sergej sind denn auch nicht für Laien gedacht und nicht jeder kann oder darf .htaccess Dateien einbinden. Manche schließen den Rest der Welt vielleicht aus und wundern sich über zu wenig Besuch. Interessant wäre hier vielleicht ein Plugin, das Angriffe auf diese Schnittstelle blockieren könnte.

Hier hat sich auch jemand ganz aktuell Gedanken über die Sicherheit bei WordPress-Seiten gemacht: http://www.netz-gaenger.de/blog/wordpress-tutorials/wordpress-security-masnahmen-erweitern

Man kann mit dieser Anleitung sicher einiges für die Sicherheit seines Blogs tun aber der Autor selbst hat schon erkannt, dass es auch Nachteile gibt.
Nämlich die, dass man zum Arbeiten wieder einiges ausschalten muss.
Das hört sich im ersten Moment noch nicht so wild an, aber tatsächlich blockieren die Sicherheitseinstellungen die Arbeit mit einer Webseite. Wenn man nicht nur eine Seite hat, sondern viele, und alle sind richtig aufwändig abgesichert, dann wird man irgendwann die Seite nicht mehr anrühren, weder etwas schreiben noch daran was ändern, weil es schlicht zu umständlich und aufwändig wurde.

Ich spüre die Umstände schon bei Hostern, die Besitzrechte des wwwrun oder phprun nicht mit dem User des Accounts gleichgeschaltet haben und man bei jeder winzigen Änderung per FTP an Dateien die Besitzrechte umschalten darf und nicht vergessen, wieder zurück schalten, sonst geht vieles WordPress nicht mehr, wie Updates und so. Da man sich dazu bei diesen Hostern einloggen muss, um die Besitzrechte zu schalten und jedesmal Gedenkminuten warten muss bis alles auf dem Server umgesetzt wurde, überlegt man es sich schon zweimal, ob man „wirklich“ etwas verändern muss oder ob es noch warten kann, bis sich genug angesammelt hat.
Schlimmer noch bei abgesicherten Rechenzentren mit zeitlich limmitiertem Account, einzig VPS Zugang zur Datenbank und WebDAV zum Webspace. Da überlegt man es sich seeeehr lange, ob man etwas machen muss.

Die Spontanität geht verloren.
Ohne Zweifel, man kann manches an Sicherheit gewinnen, aber man portiert sich intuitiv wieder zurück in die Steinzeit des WEB, zu rein statischen Seiten die einmal im Jahr eine Änderung erfahren.
Wo liegt die goldene Mitte?
Und auf WordPress zu verzichten ist auch eher unwahrscheinlich.

Veröffentlicht in Allgemein, Wordpress anpassen | Getaggt , , | Hinterlasse einen Kommentar

Brute Force Hacking auf WordPress

Nun heute auch bei mir, bei meinem unbedeutenden kleinen Blog gab es heute den ersten von mir bemerkten Ausfall wegen zu vieler Zugriffe auf die Seite.
Wer hätte das gedacht?

Da nützt es wenig, wenn man den Blog eigentlich abgesichert hat und aber doch so viele Zugriffe statt fanden, dass er nicht erreichbar war. Obwohl, bei Apache-Servern braucht es da manchmal nicht besonders viele gleichzeitige Zugriffe. Vielleicht sollte ich angesichts der gehäuften Hacking Angriffe auf WordPress-Blogs in letzter Zeit, auf ligthtpd oder nginx umsetzen? Dann liefe vielleicht wenigstens der Blog noch, während sich die Angriffe abmühen, das Passwort heraus zu finden. Aber so wichtig ist mein Blog auch nicht, als dass es auffallen würde, wenn er mal für ein paar Stunden nicht erreichbar wäre.

Doch heute habe ich sie mal life erwischt beim Brute-Forcen.  Dank eines Plugins das häufigere ungültige Anmeldeversuche sperrt und protokolliert, bekam ich seit gestern Abend schon wieder häufiger Mail-Nachrichten über diese ungültigen Anmeldeversuche. Und als ich mal nachschauen wollte, ob der Blog noch läuft, konnte er tatsächlich nicht mehr erreicht werden weil er oder der Web-Server meines Hosters überlastet war. Es betraf aber nur die HTTP Web-Ausgabe, denn die Datenbank und der Webspace per FTP waren noch erreichbar.

Also machte ich einfach mal den Laden dicht, indem ich eine index.html hoch ludt und die Verzeichnisse des Blogs umbenannten und die User in der Datenbank verändert hatte.
Dann liefen zwar immer noch die Anfragen an wp-admin ein aber das Verzeichnis gab es dann nicht mehr, und 404 lässt sich vom Server schneller ausgeben als dass WordPress zuerst prüft, ob es den User gibt und ob das Passwort stimmt und ob es einer der vielen Hackingversuche wäre. Ausserdem hatte ich gerade nicht mehr Zeit, schließlich ist Wochenende (…und das wissen die Angreifer auch).
Trotzdem, so hatte ich für eine Zeit lang meine Ruhe und Angriffe liefen völlig nutzlos ins Nirvana.

Natürlich ist es von Vorteil, wenn man nicht mehr den Standardnamen „admin“ als Benutzer hat, aber sicher darf man sich dessen trotzdem nicht sein, denn in der Protokoll-Liste stehen noch einige andere Namen mit denen versucht wird, in WordPress einzudringen. Und man weiß ja, steter Tropfen höhlt den Stein und selbst wenn man einen Login-Blocker drin hat, so gibt es je IP immer einige Anmeldeversuche bis gesperrt wird. Man möchte ja selbst nicht für Stunden oder Tage ausgesperrt werden, nur weil man sich mal vertippt hat (und das geht schneller als man denkt).
Wie in manchen Berichten zu lesen war, hatten die Angreifer am letzten Wochenende bis zu 90.000 verschiedene IPs mit denen sie angreifen konnten. Multipliziert man dann die erlaubten Versuche damit, ergibt sich ein ordentliches Sümmchen an Usernamen und Passwörtern in kurzer Zeit, die die Hacker-Maschine (ja, Maschine, denn da hockt kein Hacker hintendran sondern da läuft eine Software) ausprobieren kann bevor sie alle gesperrt wurden. Es ist wie Lotto spielen, irgendwann könnte ein Treffer dabei sein, auch wenn es unwahrscheinlich ist.
Man probiert es eben mit Gewalt und Masse, darum Brute Force.

Solange man nicht wirklich gehackt wurde, ist es eher unterhaltsam anzusehen aber auf die Dauer kann das auch nerven. Denn was ist, wenn die Angriffe immer mehr werden? Es kämen ja durch Erfolge beim Hacken immer neue IPs dazu und es würde sich wie ein Schneeball-System entwickeln bis gar nichts mehr geht?
Mal sehen wie sich das weiter entwickelt.

Jedenfalls ist nichts mit Freude über die hohe Besucherzahl (eigentlich nur viele Zugriffe von wenigen Besuchern) und die Liste der vergeblichen Anmeldeversuche wird immer länger.Denn wirklich stoppen kann ich die Brute-Force Angriffe mit all den mir zur Verfügung stehenden Mitteln nicht. Das ist wie eine Lawine und die HTTP 500 und 503 Meldungen häufen sich.
Aber eine gewisse Sichtbarkeit muss mein Blog dennoch im Internet haben, sonst wäre da nicht so viele Angriffe drauf. Muss ich mich nun geehrt fühlen, angesichts der Aufmerksamkeit?
Schaun wer mal.

Hier noch ein paar Links, wen’s interessiert,  zur weiteren Information:
http://blog.sucuri.net/2013/04/the-wordpress-brute-force-attack-timeline.html

http://playground.ebiene.de/adminbereich-in-wordpress-schuetzen/

http://wordpress-buch.bueltge.de/wordpress-sicherer-machen/30/

http://t3n.de/news/massive-angriffswelle-457424/

Veröffentlicht in Allgemein | Getaggt , | Hinterlasse einen Kommentar

Contenido Update 4.8.17 erschienen

Nachdem von CONTENIDO neulich die Version 4.8.16 erschienen ist, jedoch mit kleineren Fehlern aber großer Wirkung („Whitescreen“, fataler Fehler) veröffentlicht wurde, erschien heute pünktlich* wie angekündigt* die Version 4.8.17.
*Das sollte hier mal lobend erwähnt werden.
Und wie versprochen wurde der Fehler behoben und als kleines Goodie noch der Autoloader für die Contenido Klassen eingebaut, das eigentlich erst für Version 4.9 geplant war.
Mit dem Update erübrigt sich auch die Reparatur der kleinen Fehler in Version 4.8.16.

Bei mir läuft das System seit dem Update einwandfrei (wie zuvor auch) und bei einem Update bietet es sich an, einmal mögliche Altlasten auf dem Server zu beseitigen. Das geht relativ einfach, indem vor dem Hochladen der neuen Dateien die alten Verzeichnisse umbenannt werden (z.B. /contenido in /contenido_alt), außer dem Verzeichnis /cms oder eventuell noch anderen Mandanten. Natürlich ist die Webseite dadurch nicht erreichbar und eine einfache index.html Datei die auf die Wartungsarbeiten hinweist, hilft da schon ab (es soll ja nicht lange dauern). Datenbank- und Webserver-Sicherung wurden bereits gemacht und so können jetzt die neuen Dateien und Verzeichnisse hoch geladen werden.

Etwas Acht sollte man bei der config.php im Verzeichnis /contenido/includes geben als auch auf die Dateien im Verzeichnis /cms, denn in diesem config.php stehen die Servereinstellungen und im Verzeichnis /cms stehen die individuellen Daten für die Webseite, wie CSS und Scripte, Templates und anderes. Man sollte schon wissen, welche der dortigen Dateien man überarbeitet hat, nicht dass sie überschrieben werden und nachher nichts mehr geht.
Bei der config.php ist die Umbenennung des /contenido Verzeichnisses von Vorteil, weil sich dort im /includes Pfad noch die originale config.php befindet, quasi als Sicherung.

Nach dem Hochladen muss nur noch die originale config.php in das neue /contenido/includes Verzeichnis kopiert werden und über /setup die Update-Installation gestartet werden.
Wenn alles einwandfrei läuft, können die alten Verzeichnisse die vorher umbenannt wurden, gelöscht werden. Dadurch hat man eventuelle übrig gebliebene Daten weg vom Server, die eventuell sogar eine Gefahr für die Sicherheit sein könnten.
Wer in diesen Systemverzeichnissen noch andere Installationen oder Dateien hat, muss diese natürlich wieder nachvollziehen, denn die sind in einer Standardinstallation natürlich nicht enthalten.

CONTENIDO Version 4.8.17 erschienen

Veröffentlicht in CMS | Getaggt | Hinterlasse einen Kommentar

Datensicherung per Mausklick, mal schnell gemacht?

Datensicherung ist kein Hexenwerk mehr, geht schnell und problemlos und oft per Mausklick.
Da würden viele automatisch ja sagen und im optimalen Fall stimmt das auch.
Wo liegt das Aber?

Weiter lesen

Veröffentlicht in Allgemein | Hinterlasse einen Kommentar

Venice Update beschert lokale Suchergebnisse

Das Venice-Update von Google führt dazu, dass die Suchergebnisse mit lokalem Bezug angezeigt werden.
Für Viele ist das sehr wünschenswert, denn mich ärgerte es damals schon, als bei Webdesign aus/in Konstanz (Ich war mal Konstanzer) viele Ergebnisse aus ganz anderen Gebieten wie Stuttgart angezeigt wurden, die anscheinend auch in Konstanz Webdesign machten, obwohl deren Büroadresse nirgends in der Stadt zu finden war. Ist ja auch klar, sie haben eben nur auf die Begriffe optimiert, weil sie den Konstanzer Markt auch abschöpfen wollten.
Weiter lesen

Veröffentlicht in Suchmaschinen und SEO | Getaggt , | Hinterlasse einen Kommentar

Passwortklau am Beispiel LinkedIn

Momentan regen sich alle wieder auf, weil irgendwo Passwortlisten aufgetaucht sind. In diesem Fall stammen sie von LinkedIn, so die Meldungen. Aber auch eHarmony und Last.fm sind betroffen, wird gemeldet.

Passwortklau klingt im ersten Moment so, als wären die eigenen Zugangsdaten für die Diebe offen sichtbar. Sind sie aber nicht, denn nicht die Passwörter wurden geklaut, sondern deren Passwort-Hashes.

Weiter lesen

Veröffentlicht in Allgemein, Webdesign | Getaggt | Hinterlasse einen Kommentar

Blogbeiträge und Prokrastination

Es stimmt, hier ist lange kein Beitrag erschienen. Aber das lag nicht daran, dass ich nicht wollte oder nicht wüsste, dass Blogs immer wieder mit Beiträgen gefüllt werden sollten, damit sie leben.
Ich würde die Ursache eher in dem ständigen Gefühl, andere und wichtigere Arbeiten noch nicht alle erledigt zu haben, suchen. Manche sagen auch Prokrastination dazu (Aufschiebe-Verhalten).

Weiter lesen

Veröffentlicht in Weblog | 1 Kommentar

WordPress Plugins mit Backdoors

Aktuell gibt es eine Meldung von WordPress, dass ihr WordPress Plugin-Verzeichnis unterwandert wurde (gehackt?) und die Plugins AddThis, WPtouch und W3 Total Cache mit  Backdoors ausgestattet wurden. Weiter lesen

Veröffentlicht in Allgemein, Wordpress anpassen | Getaggt | 1 Kommentar