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.

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

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!