PureBoard

Halli Hallo,

ich möchte an dieser Stelle gerne eine Diskussion zum Thema Sicherheit mit FastCGI beginnen. Mit der nächsten LTS hält ja nun FastCGI endgültig festen Einzug in PureBasic. Gerade weil es für Windows, Linux und Mac lauffähig ist, halte ich im neuen Build genau diese Lib für die größte Neuerung (gerade auch für Linux-Server). Die Performance einer FastCGI-Anwendung im Vergleich zu einer PHP-Anwendung ist wirklich der Hammer. Theoretisch wäre mit PureBasic und z.B. Lua eine Alternative zu PHP möglich, wobei sich da über Sinn und Unsinn streiten lässt. Eine weitere Serverseitige Scriptsprache (aus Plaintext interpretiert) brauchen wir eigentlich meiner Meinung nach wirklich nicht.

Nun gibt es da allerdings das ein oder andere Problemchen. Denn so mächtig PB auch ist, fehlt es im Vergleich zu z.B. PHP noch an einigen Funktionen, die aber für Webanwendungen essentiell sind. Und genau hier würde ich gerne mit euch herumphilosophieren. Ich erwarte hier keine Codes. Mir geht es nur um Anregungen, Meinungen und Erkenntnisse und dessen Austausch.

Dann fange ich mal mit einer Beobachtung an.

Parameterüberladung: Die CGI-Lib von PB besitzt nur einen Weg, alle Parameter abzufragen. Dabei unterscheidet sie nicht zwischen GET- und POST-Daten. Dadurch lassen sich Parameter überladen. Besitzt ein POST-Formular zum Beispiel den Namen "game" (z.B. Suchbegriff für eine Spieledatenbank), kann der dort eingetragene Wert den Parameter "game" aus der URL überladen und somit unter Umständen zu unerwartetes Verhalten führen. Ich habe es also so gelöst, das ich mit den CGI-Variablen mir die gesamte URL samt GET-Parameter geholt und mit der HTTP-Funktion GetURLPart und dem URLDecoder die GET-Parameter herausgelöst habe. Wenn jemand etwas besseres hat, möge er und an diesen Gedanken teilhaben lassen

Keine Sessions: Aus PHP bekannt und man möchte es auch eigentlich nicht mehr missen. Die Sessions. Ein kleiner strukturierter Speicher in Textdateien, um Warenkörbe, Hasches und ID's für den Nutzer zu speichern. PHP legt für jeden Client eine neue Datei an und speichert dort die Werte. Ich hatte mir überlegt, das ganze vielleicht mit der Preferences-Bibliothek zu machen. Allerdings lässt sich das damit nur auf eine Dimension einschränken. In PHP geht das ganze über mehrere Dimensionen. Was wäre hier besser? JSON oder XML? Oder doch etwas anderes?

Passwort: Das mit Abstand wichtigste Thema. Seit längerem besitzt PHP dafür die password_hash Funktion. Hier haben wir nativ nur die Möglichkeit, nach altem Rezept zu arbeiten. Passwort einmal hashen und fertig. Allerdings reicht mir das nicht. Ich habe überlegt, neben einem guten Sha3 auch noch eine Prüfsumme zu erzeugen (senkt die Wahrscheinlichkeit, mit einem kollidierten Passwort einloggen zu können). Zudem soll ein Salt an oder vor das Passwort gehängt werden. Nun aber mal eine interessante Frage dazu. Die password_hash Funktion von PHP hängt den Salt Plain an den Hash und speichert den so in der Datenbank. Ist denn damit das Password wirklich so viel sicherer oder wäre es besser, den Salt jedesmal zu generieren? Und wie steht ihr zu iterative hashing?

Ich hoffe auf rege Beteiligung und freue mich auf interessante Beiträge zu dem Thema

PS: Ihr könnt auch eigene Dinge ansprechen. Also nicht nur meine Fragen beantworten und dann wars das. Ist ja nicht Sinn und Zweck der Sache

TroaX hat geschrieben:Passwort: Das mit Abstand wichtigste Thema. Seit längerem besitzt PHP dafür die password_hash Funktion. Hier haben wir nativ nur die Möglichkeit, nach altem Rezept zu arbeiten. Passwort einmal hashen und fertig. Allerdings reicht mir das nicht. Ich habe überlegt, neben einem guten Sha3 auch noch eine Prüfsumme zu erzeugen (senkt die Wahrscheinlichkeit, mit einem kollidierten Passwort einloggen zu können). Zudem soll ein Salt an oder vor das Passwort gehängt werden. Nun aber mal eine interessante Frage dazu. Die password_hash Funktion von PHP hängt den Salt Plain an den Hash und speichert den so in der Datenbank. Ist denn damit das Password wirklich so viel sicherer oder wäre es besser, den Salt jedesmal zu generieren? Und wie steht ihr zu iterative hashing?

Der Salt gehört immer im Klartext oder als Base64 oder Hex zum Passwort-Hash. Das was du meinst, wäre Pepper. Pepper wird nicht in der Datenbank gespeichert, sondern dein Passwortsystem enthält entweder einer Liste möglicher Pepper-Werte oder erzeugt sie deterministisch jedes mal neu. Wenn ein Passwort überprüft werden soll, wird dann das Salt und der erste Pepper-Wert dran gehängt, gehasht und getestet. Gibt es den Hash nicht, wird das selbe nochmal mit allen anderen Pepper-Werten aus der Liste ausprobiert. Klappt es auch beim letzten mal nicht, war das Passwort falsch, das getestet werden soll.
Und du wolltest wissen, warum Salt einen Vorteil bringt: Am besten kann man das mit den so genannten Rainbow-Tables veranschaulichen, die zum MD5-Reverse-Hashing benutzt werden. Da wird quasi eine riesige Terabytes große Datenbank angelegt, die MD5-Hashs auf andere MD5-Hashs abbildet. Man macht quasi einen MD5-Hash von einem MD5-Hash und speichert die in einer Kette. Wie es detailliert geht, kann Wiki erklären. Benutzt man jetzt aber Salts, passt diese komplette Rainbow-Table nicht mehr. Man müsste extra für diesen Salt eine neue anlegen und dann immer noch hoffen, dass man darin auch das zu suchende Passwort findet. War noch Pepper im Spiel, ist es fast unmöglich.

Danke für die Erklärung. Der Sinn hinter Salt/Pepper ist mir da ja bekannt. Allerdings ist für mich nun interessant, ob es sinnvoll ist, diese als Reintext oder schwach kodiert an den Hash dranzuhängen. Bei der PHP-Funktion wird es ja so in die Datenbank eingetragen: pwalshash.saltalsklartext

Damit habe ich ein wenig Bauchschmerzen. Außerdem wäre interessant zu wissen, ob es zur Kollisionswahrscheinlichkeit sinnvoll wäre, eine Prüfnummer des Passwortes zu ermitteln, um die Wahrscheinlichkeit einer passenden Kollision zu reduzieren.

Lass es genau so wie es ist. Ein Prüfnummer des Passworts anzuhängen würde das komplette Verfahren wieder ad absurdum führen, weil du damit ein neues Kriterium einbaust, anhand dessen man wieder cracken kann. Und ob der Salt nun im Klartext, als Base64 oder als Hex dran hängt, ändert genau gar nichts. Er darf einfach nur nicht verschlüsselt sein, die Kodierung ist egal. Um Kollisionen zu vermeiden nimmt man einfach lange Salts und einen guten Hash, also besser kein MD5 und SHA-1, sondern neuen heißen Scheiß.

Ein Prüfnummer des Passworts anzuhängen würde das komplette Verfahren wieder ad absurdum führen, weil du damit ein neues Kriterium einbaust, anhand dessen man wieder cracken kann.

Ich hatte das mir ja im Grunde so gedacht, das in der Datenbank das ganze so gespeichert wird: hash.salt.pn
Die große Stärke von Hash-Routinen ist ja zum einen, das man vom Hash nicht auf den Inhalt schließen kann (was im Grunde auch bei einer Prüfnummer der Fall ist) und die geringe Kollisionswahrscheinlichkeit. Es ist aber immernoch eine Wahrscheinlichkeit da. Es soll halt durch die Routinen die Zeit drastisch verlängert werden, bis man eine Kollision oder sogar das richtige Passwort findet. Wenn nun durch das cracken eine Kollision ausgemacht wurde (da ja im Klartext oder schwach kodiert der Salt dranhängt, ist das cracken zusammen mit dem Salt ja kein Problem), kann die Anwendung ja das kollidierte Passwort immernoch ablehnen, da die Prüfnummer nicht stimmt. Das würde also bedeuten, das die Prüfnummer gegen jede Kollision geprüft werden muss, um einen passenden String als Passwort zu finden. Würde das nicht das Verfahren deutlich verlängern?

Die Prüfnummer ist im Hash ja nicht drin, sondern wird jedesmal von der Eingabe des Passwortes ermittelt und dann verglichen. Die Nummer wird nur in der DB angehängt und soll die Gefahr minimieren, das eine Kollision auch auf das Passwort passt.

Aus diesem Grund hätte ich jetzt nicht angenommen, das es die Passwort-Routine unsicher machen würde. Entweder habe ich da also einen Denkfehler drin oder habe bei meiner Überlegung einen Parameter übersehen.

Wenn die Prüfnummerngenerierung schneller geht als der Hash, würde man ja andersrum dran gehen. Man sucht Kollisionen, die die korrekte Prüfnummer generieren, hängt den Salt an und führt dann den eigentlichen Hash aus. Das heißt, wenn die Prüfnummerngenerierung schnell geht, hast du es dem Angreifer nur einfacher gemacht.

Fazit: Nutze ein aktuelles Hashverfahren. Und zwar so, wie es gedacht ist und baue nichts drum herum, ohne vorher mal ein paar Artikel über korrektes Passwort-Hashing gelesen zu haben. Da hat letztens eine große Firma auch wieder Unsinn betrieben, weil es Passwörter auf zwei verschiedenen Weisen nebeneinander gehasht hat (ähnlich deinem Hash und der Prüfnummer) und deswegen von Angreifern auf die Datenbank viele Passwörter kompromittiert werden konnten.

Glaube mir einfach als bestandenen Kryptographie-Studenten.
Und schau auch mal hier und scrolle runter zu: The WRONG Way: Double Hashing & Wacky Hash Functions

Wenn die Prüfnummerngenerierung schneller geht als der Hash, würde man ja andersrum dran gehen. Man sucht Kollisionen, die die korrekte Prüfnummer generieren, hängt den Salt an und führt dann den eigentlichen Hash aus. Das heißt, wenn die Prüfnummerngenerierung schnell geht, hast du es dem Angreifer nur einfacher gemacht.

Ahhh genau da war der Denkfehler. Das stimmt natürlich. Daran habe ich nicht gedacht. Dann würde ich hier in PB den SHA3 512-Bit nutzen und den Salt in der Datenbank anhängen. Ich würde es auch gerne Iterieren. Also im Grunde beim Vorgang den Hash z.B. 1000 mal durchführen und jedesmal den Zähler noch dranhängen. So wird es auch schon sehr häufig empfohlen.

Anstatt das Rad neu zu erfinden, nutze lieber sowas hier: PBKDF2 For PHP

Jo ist auch eine Möglichkeit. Ich muss sowieso mal schauen, wie ich die Iteration mache. Selber implementieren muss ich das sowieso, da es soetwas in PB eh nicht gibt.

TroaX hat geschrieben:Selber implementieren muss ich das sowieso, da es soetwas in PB eh nicht gibt.

<Halb-Offtopic>
Könnte man nicht Funktionalitäten aus der PHP-Library nutzen? Hat nicht schon mal jemand einen Wrapper dafür geschrieben? ('php' ist aber auch echt ein schlechter Suchbegriff...)
</Halb-Offtopic>

Grüße ... Peter