Interessantes Jobangebot – Die upside relationship marketing GmbH sucht einen guten PHP-Entwickler für ein interessantes Software-Projekt. Gesucht wird ausschließlich zur Festanstellung mit Tätigkeit vor Ort in Düsseldorf. Wer Interesse hat, findet hier mehr Informationen.

Bei meinen Zeichensatz-Spielereien in der letzten Zeit bin ich auf eine interessante Möglichkeit gestoßen, den Zeichensatz den der Browser für das Senden von Formulardaten verwendet zu erkennen. Es gibt, ähnlich den Magic-Methoden bei PHP, die Möglichkeit ein speziell benanntes Formularfeld zu erstellen, in das der Browser bei Submit automatisch den verwendeten Zeichensatz einfügt.

Als ich das gelesen hatte, konnte ich mir dies nur schwer vorstellen, zumal ich ja nicht erst seit gestern Formulare für das Netz erstelle. Doch es funktioniert tatsächlich. Allerdings konnte ich dies nur mit Firefox in Version 3.5 und dem Internet Explorer in Version 7 testen (Wenn jemand dies auch mit anderen Browser schon getestet hat, möge er oder sie das Ergebnis docheinfach per Kommentar mit uns teilen).

Einfach folgendes Feld in das Formular einbinden:

Und schon sollte man das Ergebnis im entgegennehmenden Skript sehen können (Achtung! Der Internet Explorer gibt den Zeichensatz lowercase und der Firefox uppercase an).

Euer
Benjamin Carl

Immer mal wieder stolpert man über das Thema: “UTF-8 mit PHP” – und es ist wirklich alles andere als angenehm. Die Unterstüztung für Multibyte-Zeichensätze in PHP ist ziemlich dürftig und da bis zum erscheinen von PHP 6 und der anschließenden Migrationsphase auch noch einige Tage vergehen werden, kommt man momentan noch nicht drum herum an vielen Stellen selbst aktiv zu werden und zu validieren, konvertieren usw…

Auf der Suche nach passenden Informationen wird es ja teilweise fast schon kriminell – Was man auf den Ergebnisseiten so lesen kann und wie die Informationen, wohl durch Unwissenheit bzw. “Dem gefährlichen Halbwissen” geschuldet, wild durcheinander gewürfelt werden – oh je!

Ich habe die besten  und aufschlußreichsten drei Ergebnisse ermittelt und möchte diese nun mit euch teilen:

1. Character Sets / Character Encoding Issues at phpwact.org
2. Handling UTF-8 with PHP at phpwact.org
3. UTF-8: The Secret of Character Encoding

Viel Spaß! Und Kommentare sind immer willkommen!

Euer
Benjamin Carl

… nicht! Es gibt den ganzen Tag genügend Anlaß zum Nachdenken ;)

Hier mal was amüsantes – oder erschreckendes? Ich bin mir gerade selbst nicht sicher…

Soeben hatte ich eine Idee für einen dynamisch aus den vorliegenden Logindaten erzeugten Salt – quasi Pepper zum Salt.

Für diejenigen unter euch, die nicht wissen, was Salt in Verbindung mit der Speicherung von Passwörtern bedeutet, hier ein kurzer Auszug aus der Wikipedia:

Salt (engl. „Salz“) bezeichnet in der Kryptographie eine zufällig gewählte Bitfolge, die an einen gegebenen Klartext vor der Verwendung als Eingabe einer Hashfunktion angehängt wird, um die Entropie der Eingabe zu erhöhen. Die Verwendung eines Salts erhöht den Aufwand von Wörterbuch-und Brute-Force-Angriffen oder Angriffen unter Verwendung einer Rainbow Table auf die Chiffre deutlich…

Da bei einer Loginsession (in 99% aller Fälle) genau zwei Konstanten zur Verfügung stehen – zum Einen der “Benutzername” und zum Anderen das “Passwort” – läßt sich doch genau mit diesen ein solches, von mir “Salt’n'Pepper” getauftes, Verfahren realisieren.

Ganz neu scheint diese Idee oder der Gedanke jedenfalls nicht zu sein (siehe hier).

Ich bin mir nur noch nicht sicher, ob es sich bei dieser Idee wirklich um eine sinnvolle handelt, oder ob der Ansatz eher zu “security through obscurity” bzw.  “security by obscurity” zählt. Was aber auch laut Wikipedia nicht grundsätzlich negativ wäre:

Als Ergänzung bestehender Sicherheitskonzepte kann sich Verschleierung jedoch als wirkungsvoll z. B. gegenüber automatisierten Angriffen erweisen.

In den mir bekannten Systemen wird entweder ein komplett anderes Hashing-Verfahren wie z.B. phpass eingesetzt (wie z. B. bei Wordpress), oder es wird ein simples Md5-Hashing in Kombination mit einer Unbekannten als Salt für den Hash verwendet. Die Salt-Funktion wird dabei, um eine weitere Trennung der sicherheitsrelevanten Funktionen zu erreichen, oftmals in der Datenbank, als “stored-procedure” hinterlegt.

Auf jeden Fall erhöht man die Anzahl der zur Berechnung des ursprünglichen Passwortes notwendigen (unbekannten) Informationen und erhöht dadurch ja schon die bedingte Entropie des erzeugten Hash.

So in etwa könnte das Ganze formuliert werden:

hP = hash( p + hB + s )

Dabei entspricht “hP” dem Ziel-Hash, “p” dem Passwort, “hB” dem Hash des Benutzernamens und “s” der statischen Salt-Value.

Wichtig! “hB” wird hier lediglich als Hash des Benutzernamens dargestellt, was natürlich nur beispielhaft gemeint ist. Hier liegt es an der Kreativität des Entwicklers, den Hash statt mit einem simplen MD5 ggf. mit einem kombinierten Verfahren zu erzeugen.

Ich würde mich diesmal sehr über Feedback oder Kritik in Form von Kommentaren freuen, das Thema ist sicherlich nicht nur für mich interessant.

Euer Benjamin Carl

Tag 8 – Tipp 8 – Modularisiere deinen Code

Nicht jedem Entwickler scheint klar zu sein, dass man die Lösung  die man mit seinem Code abbilden möchte nicht nur in private und public Methoden unterscheidet, sondern eine Lösung in mehrere Methoden aufteilen sollte, wenn eine Methode/Funktion z.B. die Länge eines Screens erreicht hat, und man scrollen muß um die gesamte Methode zu betrachten.

Hört sich simpel an, wird allerdings noch lange nicht von jedem beachtet!

Tag 7 – Tipp 7 – Vermeide das Erraten der Business-Logik

Was macht der Entwickler wenn er an einem Punkt keine konkrete Anweisung zur Umsetzung der Business-Logik hat?

Richtig – In der Regel rät er, um den Code komplettieren zu können. Diese proaktive Handeln ist sicherlich gut gemeint, nur bewirkt es in der Regel genau das Gegenteil. Mir sind Fälle bekannt, in denen ein derartiges Handeln eines Entwicklers einen Auftraggeber fast zur Geschäftsaufgabe gezwungen hat.

Halte dir deshalb immer folgendes vor Augen:

• Rate oder Vermute die Business-Logik nicht – auch wenn es gut gemeint ist!
• Halte die Stellen an denen nicht geklärt ist, wie sich eine Applikation verhalten soll offen und warte auf Klärung durch den entsprechenden Ansprechpartner!
• Achte auf Unstimmigkeiten in der Business-Logik und bespreche diese mit dem Kunden/Auftraggeber

Wenn man sich grob an diesen Punkten orientiert ist man auf einem guten Weg, nur genau die Logik zu implementieren, die der Kunde auch benötigt und erwartet.

Dies bedeutet natürlich nicht, dass keine Beratung stattfinden darf! Nur muss diese mit dem richtigen Ansrechpartner, aber vor allem vor der Umsetzung erfolgen.

Tag 6 – Tipp 6 – Nutze ein System oder eine simple Liste zum Nachhalten von Änderungen

Nicht jedem Programmierer steht für jedes seiner Projekte ein Code-Repository (wie z.B. SVN oder CVS) zur Verfügung. Um so wichtiger ist es, das Änderungen die am Code von einer Version (und dabei ist es egal ob es eine Major-, Minor-, oder Release-Änderung ist) zur nächsten getätigt werden, “irgendwo” festgehalten werden. Wer nicht die Möglichkeit hat, dafür auf ein Bugtrackingsystem wie z.B. Mantis zurückgreifen zu können, der kann auch einfach eine simple Textdatei dafür nutzen.

Besonders wichtig ist dabei (unter anderem) folgendes:

• Änderungen am Quelltext sollten schriftlich aber vor allen einheitlich erfasst werden
• Vermerke Datum und eine Kurznotiz zur Änderung (ggf. auch die Datei in der die Änderung erfolgte)

Das System mit den Textdateien, hat früher (vor dem ersten Repository-System) auch ganz passabel funktioniert und trug den Namen CHANGELOG, so wie diese Datei, die den meisten (größeren) Projekten im Root-Verzeichnis immer noch beiliegt.

Grundsätzlich wäre auch zu sagen, je mehr Disziplin eingebracht wird und je detailreicher die Einträge, um so hilfreicher ist das System.

Tag 5 – Tipp 5 – Achte auf eine saubere und konsistente Zeileneinrückung

Eine saubere und vor allem konsistente Einrückung deiner Quelltexte sollte auch für dich an oberster Stelle stehen. Nur wenige andere Faktoren haben so einen großen Einfluß auf die Lesbarkeit von Quelltexten.

Du wirst es dir selbst spätestens bei der nächsten Fehlersuche danken. Du solltest dich mit deinem Team über einen einheitlichen Standard einig werden und diesen z.B. mit dem PHP-Codesniffer vor dem Übernehmen der Änderungen in das Repository prüfen. Ein Code-Beautifier könnte dir als Werkzeug ebenfalls behilflich sein – mit diesem (so wie ihn z.B. Eclipse besitzt) kannst du deinen Code automatisiert formatieren.

Tag 4 – Tipp 4 – Nutze die Vorteile des Unit-Testing

Sicher ist es das Ziel, den Code den Anforderungen entsprechend fertiggestellt zu haben und bereit für die Integration zu sein. Aber den Schritt des Unit-Testing auszulassen kann dich schneller einholen, als dir lieb ist! Durch Unit-Testing stellst du sicher, das (alle) einzelne(n) Teile der gesamten Applikation einwandfrei arbeiten und vermeidest den sogenannten “Blindflug”, wenn es zur Integration kommt und die Applikation sich nicht mehr so verhält, wie auf dem Entwicklungssystem.

Dann kann man je nach Projektumfang schon mal längere Zeit suchen, debuggen, Logfiles studieren oder aber auch einfach ins Schwitzen kommen.

Schreibe deinen Code immer so, daß sich einzelne Teile (je kleiner die Teile umso genauer!) testen lassen und automatisiere diese Tests bestenfalls komplett. Mehr Informationen zu automatisiertem Unit-Testing mit phpUnderControl und PHPUnit findest du entweder hier in meinem Blog oder auf den Projektseiten von phpUnderControl oder PHPUnit.