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.