Samstag, 18. Dezember 2010

Worauf es bei Passwörtern im Web ankommt *Update*

Es kommt nicht auf die Länge an. Wenigstens nicht bei Passwörten im Web. Unter Entwicklern herrscht nicht selten die Meinung vor, starke Passwörter würden die Sicherheit erhöhen. Der Zwang zur Auswahl komplexer Passwörter ist eigentlich nur ein Delegieren der Sicherheitsanforderungen an den Benutzer. Weshalb das nicht funktioniert, ist mit einem Blick auf die möglichen Wege eines Passwortverlustes schnell erklärt.

Man-in-The-Middle (MiTM): Besonders populär ist die MiTM-Methode jüngst durch Firesheep geworden. Vor allem in fremden WLAN-Netzen besteht die Gefahr, dass unberechtigte mitlesen und Passwörter ausspähen. Hier würde eine verschlüsselte Verbindung erheblich mehr Nutzen, als ein Passwort, dessen Komplexität dem Mitsniffenden herzlich egal sein kann.

Phishing: Fällt der Benutzer auf eine gefälschte Seite herein, spielt die Passwortkomplexität keine Rolle mehr.

Brute Force: Soll ein Passwort durch reines Durchprobieren erraten werden, sind besonders schwache Passwörter wie 123456 oder der Benutzername als Passwort besonders gefährdet. Aber auch dies erfordert keine starken Passwörter. Eine Blacklist mit gängig schwachen Passwörtern und einer Prüfung auf den Benutzernamen vorwärts, wie rückwärts, verhindert die schlimmsten Passwortpatzer. Gepaart mit Wartezeiten zwischen den Logins und einer Begrenzung der insgesamt erlaubten Fehlschläge ist auch hier ein Erfolg unwahrscheinlich.

Educated guess: Gezieltes Raten durch Umfeldwissen lässt sich von allen Methoden am wenigstens vermeiden und kann tatsächlich zum Erfolg führen, zumal davon auszugehen ist, dass dem Ratenden der Benutzername bekannt ist. Hier wäre ein eingestreutes Sonderzeichen oder ein Ziffer tatsächlich hilfreich. Die Begrenzung der Loginversuche leistet aber ebenfalls gute Dienste, um ein zu häufiges Probieren zu unterbinden. Vor allem ist zu bemerken, dass Benutzer, die zu starken Passwörtern gezwungen werden, die Passwörter häufiger aufschreiben. Ich meine, hier ist abzuwägen, inwiefern das aufgeschriebene Passwort nicht ein höheres Risiko birgt, als ein aus dem Umfeld zu erratenes, schwaches. Vielmehr verführt das zufällig gefundene Passwort sogar zum Missbrauch. Der Zugang über das Umfeld des Benutzers ist nie auszuschließen. Schon gar nicht von Seiten der Webentwickler.

Rainbow-Tabellen: Ist die Datenbank der Webanwendung erst in fremden Händen, lassen sich mittels vorberechneter Hashes (Rainbow Tables) auch starke Passwörter knacken. Dagegen hilft der Einsatz von Salts, die wiederum auch schwache Passwörter schützen.

Natürlich sind starke Passwörter zu bevorzugen. An der Passwortsicherheit hängt aber mehr, als allein die Komplexität des Passworts. Vielmehr sind Softwareentwickler gefragt die Passwörter sicher abzulegen und die Loginprozedur so auszugestalten, dass automatisierte Angriffe an einer begrenzten Anzahl von Versuchen scheitern. Das muss nicht unbedingt mit einer Sperrung des Accounts enden. Eine zeitlich begrenzte Sperre hat bereits den gleichen Effekt. Letztendlich hat der Administrator den Transportweg mittels Https-Verbindungen abzusichern und der Benutzer ist gefragt, verantwortungsbewusst mit seinem Passwort umzugehen.

Update 18.12.10
Vor einigen Tagen sind dem US-Blogbetreibers Gawker u.a. die Benutzerdaten inkl. der DES-Verschlüsselten Passwörter abhanden gekommen. Die Hacker haben die Nutzerdaten veröffentlicht, was interessante Analysen zulässt. Die Passwörter wurden via DES-Hashes gespeichert. Soweit herauszulesen ist, wurden kein Salt verwendet, was eine einfache Dekodierung mittels Wörtbuch/Bruteforce ermöglicht. Unter den Daten waren auch die, des Gawker-Gründer Nick Denton, der das gleiche Passwort auch für seinen Google- und Twitteraccount verwendet hat.

Es lässt sich grundsätzlich nicht vermeiden, dass Benutzer ihre Passwörter mehrfach verwenden. Der Gawker-Fall zeigt aber deutlich, wo die eigentliche Gefahr liegt. Nämlich nicht etwa im schwachen Passwort, sondern darin, dass die Passwörter nicht gut genug gesichert wurden.

Einen nutzen können wir jedoch trotzdem daraus ziehen. Nämlich die Top250 ermittelten Passwörter für die Blacklist.

via heise, duosecurity

Mittwoch, 15. Dezember 2010

WindowBuilder und CodePro Profiler

Zwei Geschenke an die Community. Google übergibt WindowBuilder und CodePro Profiler an die Eclipse Foundation. Mit WindowBuilder lassen sich SWT- und Swingoberflächen zusammenklicken, CodePro ist ein Profiler. Beides lässt Eclipse bisher missen. Zwar gibt es einige GUI-Designer für Eclipse, aber spätestens bei Swing ist es mit überzeugenden Lösungen nicht weit her. Noch schlechter steht es um einen Profiler. Da gibt es eigentlich nur brauchbares bei den kommerziellen Tools. Wäre natürlich toll, wenn sich die Eclipse Foundation auch wirklich darum kümmern würde. Ich erinnere mich da an einige Plugins, die in den Aktualisierungen nicht mitgezogen wurden und irgendwann in der Versenkung verschwanden. Beide Tools halte ich für eine absolute Bereicherung, zumal die eigenen Bemühungen, bei der Entwicklung eines SWT/Swing-Designer (VEP), nie brauchbare Ergebnis zu Tage gefördert haben.

Insofern gute Nachrichten und ein dickes Danke an google. Die machen es einem manchmal wirklich schwer, sie nicht zu mögen.

Links:
CodePro: http://www.eclipse.org/proposals/tools.rat/
WindowBuilder: http://www.eclipse.org/proposals/tools.windowbuilder/ und http://code.google.com/intl/de-DE/javadevtools/download-wbpro.html

via it-republik.de

Paygames für Linux

Ich bin immer wieder erfreut, wenn auch kommerzielles für Linux entwickelt wird. Ein Spielebundle für Linux, Mac und Windows gibt es derzeit auf Basis einer freiwilligen Spende bei The Humble Indie Bundle. Ich bin zwar für Spiele nur bedingt zu haben, diese wollte ich aber gern ausprobieren. Von den fünf Spielen laufen immerhin vier auf Anhieb. Nur der Cortex Commander wollte, trotz 64bit Installer, auf meiner Maschine leider nicht. Die anderen vier Spiele habe ich angespielt und ich bin sehr angetan von der Ideenvielfalt.

Braid: Ein Jump and Run der besonderen Sorte. Weil Videos manchmal mehr als viele Worte sagen, hier der Trailer zum Game.




Machinarium: Definitiv ein Highlight, wenn man das Adventure-Genre mag.




Osmos: Ein Spiel, mit dem man Stunden verbringen kann, ohne es zu merken. atmosphärisch und suchterregend wären die beiden Attribute, die mir zuerst einfallen würden.




Refenge of the Titans: Passt am besten in die Kategorie Retrogames. Ebenfalls schön gestaltet, aber ehrlich gesagt nicht mein Fall.



via stadt-bremerhaven.de

*Update 22.12.10*
Echt fair ist übrigens, dass Humbler Bundle sich entschieden hat, einfach die Spiele vom letzten Bundle auch noch dazuzugeben. Außerdem bekommt man die noch auf seinen Steam-Account. Sowas habe ich aber sowieso nicht.

Freitag, 10. Dezember 2010

Swing Komponenten in XPS Drucken

Java und Drucken ist ja so eine Sache, mit der ich mich bereits viel herumgeärgert habe. In einem aktuellen Fall werden Swingkomponenten ausgedruckt. Das funktioniert soweit ganz ordentlich. Einzig, wenn man den Microsoft XPS-Drucker verwendet, erscheint ausschließlich die letzte Komponente im Ausdruck - der Rest fehlt. Zeichnet man ohne Swing-Komponenten auf dem Graphics-Object des XPS-Drucker, erscheint das Ergebnis wie erwartet. Woran es nun genau gelegen hat, vermag ich auch nicht zu sagen. Ich bin letztendlich darauf hängen geblieben, dass der Ausdruck auf dem XPS-Drucker korrekt herauskommt, wenn man nach dem paintAll der Swing-Komponenten ein drawLine auf das oberste Graphics-Object ausführt. Besonders hinterhältig ist immer die Aussage der Benutzer, dass ganze würde ja schließlich mit Word gut funktionieren. Das sind die Stellen, an denen sich die Maschinenferne von Java rächt. Man hat im Grunde kaum Manipulationsmöglichkeiten um so einem zickigen Druckertreiber beizukommen. In diesem Fall war es ja zum Glück recht unkompliziert.

Mittwoch, 8. Dezember 2010

Bibliotheken Guava und op4j

Guava: Die Google Collections Library ist veraltet, seit einiger Zeit benutzt man Guava. Das Guava-Projekt entwickelt die Google-Bibliotheken weiter. Die Bestandsfunktionalität der Google Collections bleibt erhalten, es sind aber neue Funktionalitäten hinzugekommen, Bugfixes eingearbeitet und Performanceverbesserungen durchgeführt worden. Die gesamte Bibliothek umfasst inzwischen weitaus mehr, als nur Collections. Was es da inzwischen alles gibt, muss ich bei nächster Gelegenheit mal evaluieren.

*Update 23.01.11*
Eine ganz ordentlichen Einblick in die Möglichkeiten von Guava gibt es bei Thomas Ferris Nicolaisen.

op4j: Eine Bibliothek die den Einsatz der Fluent-Schreibweise schmackhaft macht. Nach kurzer Eingewöhnung kann man damit semantisch sehr gut lesbaren Code erzeugen.

Sonntag, 5. Dezember 2010

10 typische Fehler in Enterprise-Java-Anwendungen

Eine Teil der beschriebenen Fehler lassen sich auch auf alle anderen Java-Anwendungen transportieren. Den Vortrag hält Eberhard Wolff auf der W-JAX 2009. Die Fehler, die er beschreibt, sind viel mehr Designschwächen, die man tatsächlich in sehr vielen Anwendungen wiederfindet. Alles in allem ein außerordentlich empfehlenswerter Vortrag!

Donnerstag, 2. Dezember 2010

Java ist auch eine Insel die 9te

Seit November ist es draußen. Das Buch, dass vermutlich jeder, der sich jemals mit Java befasst hat, zumindest dem Namen nach kennt. Von "Java ist auch eine Insel" gibt es die 9te, überarbeitete Fassung zum online- und offline lesen, sowie als Buch zum Kaufen.

http://openbook.galileocomputing.de/javainsel9/

Dienstag, 30. November 2010

Pixel aus BufferedImage auslesen

An die Pixel eines BufferedImage kann man ganz einfach gelangen. Den Sniplet brauchte ich vor Ewigkeiten mal und habe ihn gerade wiedergefunden. Super einfach eigentlich:

public static void main(String[] args) {
        try {
            final BufferedImage img =  ImageIO.read(new File("images/example.jpg"));
            final int w = img.getWidth();
            final int h = img.getHeight();
            final int pixels[] = new int[w * h];

            img.getRGB(0, 0, w, h, pixels, 0, w);
            
            for (int i = 0; i < pixels.length; i++) {
                System.out.println("R:" + ((pixels[i] >> 16) & 0xff) + " G:"
                        + ((pixels[i] >> 8) & 0xff) + " B:" + (pixels[i] & 0xff));
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

Schreibweise für String-Concatenation

Das man mal einen String zusammensetzen will, kommt ja häufig vor und ist einfach. Beispiel:
String s = "[Attribute: " + getQualifiedName() + "=\"" + value + "\"]"; 
Daran gibt es ansich auch nicht viel zu mäkeln, außer eben, dass diese Schreibweise, je nach Länge, schnell unübersichtlich aussieht. Viel netter ist es eigentlich, den StringBuilder mit seiner Kettenschreibweise zu verwenden.
String s = new StringBuilder()
            .append("[Attribute: ")
            .append(getQualifiedName())
            .append("=\"")
            .append(value)
            .append("\"")
            .append("]")
            .toString();
Wenn man nun ganz korrekt sein will, kann man außerdem abschätzen, wie groß der String werden könnte, und dem StringBuilder gleich die dazu passende Größe mitgeben, so dass er möglichst selten mitwachsen muss. Merklich performanter dürfte keine der beiden Lösungen sein, da der Hotspot-Compiler das String-Concatenieren ohnehin optimiert, wenn er es denn kann. Probleme hingegen gibt es da schnell mal in Schleifenkonstrukten. Ist die Logik zum String bauen umfangreicherer, empfiel sich ohnehin immer der StringBuilder bzw. der StringBuffer, wenn man das synchronisierte Derivat braucht, oder kein Java 1.5 zur Verfügung hat, was hoffentlich selten geworden ist.

Donnerstag, 25. November 2010

jsoup: Java HTML Parser

Das hier gehört in die Kategorie: Muss ich mir merken. Eine Java-API, die von sich behauptet, Wildbahn-HTML parsen zu können. Mit anderen Worten, dass Ding soll recht fehlertolerant sein.Zur Projektseite geht es hier: http://jsoup.org/

via Schockwellenreiter