Umbauarbeiten

Wie ihr sicherlich gemerkt habt, habe ich lange Zeit nichts mehr in meinem Blog veröffentlicht. Das liegt zum Einen am Sommer und entsprechenden Urlaubszeiten, aber auch daran, dass ich schon seit längerem meine Webseiten im Hintergrund umbaue und neu sortiere. Dabei sammele ich vieles, was mich bei meinen Hobbies und der Arbeit tagtäglich begleitet in einem Wiki und überlege gerade, den Teil zum Thema Softwareentwicklung auszulagern. Letzteres hat den Grund, dass ich mit der Softwareentwicklung mein Hobby zum Beruf gemacht habe und mir die Vermischung mit den anderen Themen in diesem Blog schon lange nicht mehr gepasst hat.
In nächster Zeit plane ich deshalb die Beiträge, die sich mit Softwareentwicklung beschäftigen, aus diesem Blog in ein weiteres Blog zu migrieren. Eine Überarbeitung der Kategorien in diesem Blog ist eigentlich auch schon längst mal überfällig. Die Verlinkung zwischen den Blogs muss dann noch vernünftig integriert werden und schlussendlich sollen noch einige bisher private Projekte auf Github landen. Das passiert logischerweise in meiner Freizeit – kann sich also auch noch ein wenig hinziehen. Mal schauen, wie lange es dauert :-).

Unabhängige Zufallszahlen / Random Klasse im .NET Framework

Heute hat mir ein Kollege erzählt, dass die Random Klasse im .NET Framework keine vernünftigen Zufallszahlen erzeugen würde und dass zwei Instanzen der Random Klasse jeweils die gleichen Zufallszahlen erzeugen. Das entsprechende Beispiel hat er mir schnell anhand eines kleinen NUnit-Tests gezeigt, der in etwa so aussah:

Lässt man das Programm laufen und vergleicht die beiden erzeugten Listen stellt man fest, dass beide Listen die gleichen Zufallszahlen enthalten, was meinen Kollegen etwas überrascht hat. Der Grund ist dafür aber eigentlich recht einfach und auch in der Hilfe zum .NET Framework dokumentiert. Die Initialisierung des Pseudozufallszahlengenerator wird anhand der Systemzeit durchgeführt und da die Random Klasse nur einen recht einfachen Zufallszahlengenerator beinhaltet, liefern beide Klassen jetzt die gleichen Werte zurück.
Das Problem kann man auf unterschiedlichen Wegen lösen. Zum Einen kann man einfach nur ein Objekt verwenden, das die Pseudozufallszahlen zurückliefert. Benötigt man trotzdem zwei unterschiedliche Instanzen der Klasse Random könnte man mittels System.Environment.TickCount die Klassen unterschiedlich instantiieren, bspw. so:

Eine letzte Möglichkeit ist es, einen Zufallszahlengenerator zu verwenden, der kryptographisch sichere Zufallszahlen erzeugt. So einen Zufallszahlengenerator bietet das .NET Framework unter System.Security.Cryptography.RandomNumberGenerator. Das Programm wird dadurch allerdings etwas aufwendiger, da ein solcher Zufallszahlengenerator immer in ein Byte-Array schreibt und man das Array dann erst in den benötigten Variablentyp umwandeln muss. Das Programm von oben würde unter Verwendung eines solchen Zufallszahlengenerator dann so aussehen:

Klingt doch eigentlich logisch, oder? Jedenfalls sollte man bei der Verwendung der Klasse Random etwas aufpassen und daran denken, dass bei Initialisierung mit gleichen Werten auch die gleichen Zufallszahlen zurückgegeben werden und sogar vorhersagbare Zufallszahlen zurückgeliefert werden (was in den meisten Fällen aber kein Problem sein sollte).

WordPress mit Zwei-Faktor-Authentifizierung absichern

Nach langer Zeit endlich mal einen neuen Beitrag von mir… In den letzten Tagen habe ich mich einmal ein wenig damit beschäftigt, meine diversen Zugänge etwas besser abzusichern und natürlich musste dann auch bei WordPress etwas passieren. Durch Zufall bin ich über die Zwei-Faktor-Authentifizierung gestolpert. Das Verfahren war mir bereits durch die RSA SecurID bekannt, aber dass man es auch in WordPress einsetzen kann, war mir neu.
Die Idee dahinter ist, dass man zusätzlich zu seinem Benutzernamen und Login noch einen Code eingeben muss, der über einen anderen Kanal (z.B. eine Smartphone App, einen USB Key, …) generiert wird und nur für einen kurzen Zeitraum gültig ist (TOTP – Time Based One Time Password). Auf diese Weise verhindert man, dass jemand, der sowohl Benutzername, Passwort und Code kennt, sich später mit diesen Daten neu einloggen kann, da der Code bereits ungültig geworden ist.

FreeOTPDie Installation in WordPress ist sehr einfach. Installiert in eurem Blog einfach das „Google Authenticator“ Plugin. Wer jetzt schon wieder einen Schreck wegen Google bekommt: Keine Panik! Das System setzt die RFC6238 um und das Plugin baut keinerlei Verbindung zu Google auf, zumindest habe ich im Quellcode keinerlei Hinweis darauf gefunden. Bevor ihr jetzt in den Benutzereinstellungen der einzelnen Benutzer das Plugin aktviert, solltet ihr euch noch einen Codegenerator herunter laden. Erste Wahl – zumindest für Android Nutzer – wäre vermutlich der „Google Authenticator“, allerdings wurde der Quellcode seit einigen Version nicht mehr herausgegeben. Ich verwende deshalb „FreeOTP„. FreeOTP basiert auf der letzten Version des Google Authenticator Quellcodes und wird von Red Hat gepflegt. Man kann es auch im bekannten F-Droid Store bekommen, in dem nur Programme angeboten werden, die im Quellcode verfügbar sind und von den Buildservern des Projektes gebaut wurden.

Ok, das war es eigentlich auch schon, denn jetzt braucht man nur noch im Benutzerprofil unter „Google Authenticator Einstellungen“ das Login aktivieren, eine vernünftige Beschreibung eingeben und den QR-Code mit der App einscannen. Wenn ihr das gemacht habt, sollte FreeOTP direkt damit beginnen, Einmalpasswörter zu generieren und eurem ersten Login steht nichts mehr im Wege.

GoogleAuthenticator-Plugin

Tipp: Solltet ihr euch mal aus eurem Weblog ausgesperrt haben, dann löscht einfach im Plugin Verzeichnis das Google Authenticator Plugin und schon könnt ihr euch wieder ganz normal an eurem Weblog anmelden.

P.S.: Es gibt noch jede Menge andere Dienste, die den Zugang über Zwei-Faktor-Authentifizierung unterstützen. Bspw. kann man bei Github, App.net, aber auch bei Dropbox, Facebook und den Google Diensten diese Zugangsart aktivieren.