IPA Encrypt Decrypt

• Recherche

Aktuelle Ausgangslage:
Über das Framework QFQ stellen wir den Usern ein Template namens Form-Editor zur Verfügung mit welchem der Frontend Entwickler eigene Formulare modular mit einzelnen Form-Elementen zusammenbauen können. Das Formular steht immer in Verbindung zur ausgewählten Tabelle und die einzelnen Form-Elemente zu den Tabellenspalten.

Allgemeine Beschreibung des Features:
Aktuell werden alle im Formular eingegebenen Informationen des Benutzers unverschlüsselt in die Datenbank hinterlegt. Nun gibt es manche Form-Element Felder, die man gerne verschlüsselt auf der Datenbank haben möchte. Dabei würde man für den Frontend Entwickler im Form Editor bei der Übersicht aller FEs eine weitere Spalte (Encrypted) angeben mit einem Häkchen falls für das FE die Verschlüsselung aktiv ist. Die Verschlüsselung kann im Edit des FE, Tab 'Basic' über eine Checkbox aktiviert werden. Das Aktivieren der Checkbox öffnet ein weiteres Textfeld unter der Checkbox zur optionalen Eingabe eines eigenen Salt-Wertes (Falls leer, wird ein Default von QFQ ausgewählt).

Das Feature in der obigen Aussage beschränkt sich auf die Frontend Entwickler und hat nichts mit dem Benutzer des Tools zu tun.

Funktionalität
Es muss ein Passwort bestimmt werden, welches für die Verschlüsselung des Inhalts verwendet wird. Damit wird zuerst der Inhalt verschlüsselt. Die dafür benutzte Methode, der angegebene Salt (evt. auch die Gruppe der Person) und der verschlüsselte Inhalt wird als Tabelleninhalt abgelegt. Inhalt könnte so aussehen: sha256:mySalt:(gruppe):encryptedText
Die Daten können nur noch mit dem dafür verwendeten Passwort entschlüsselt werden.

Arten der Passworthinterlegungen:

1. Systemweites Passwort
Das Passwort wird im Typo3 Backend in der QFQ Config abgelegt und gilt für das gesamte Tool als Verschlüsselung.
Sollte auch das Ändern dieses Passwortes möglich sein, dann darf das zu ersetzende Passwort erst überschrieben werden wen die zuvor verschlüsselten Daten alle entschlüsselt und mit dem neuen verschlüsselt werden. Alle bereits verschlüsselten Daten müssen einem Refactor unterzogen werden.
Diese Daten müssten spezifisch markiert werden?

2. Mehrere Systemweite Passwörter (Gruppen)
Es können z.b. 10 verschiedene Passwörter im Typo3 Backend in der QFQ Config abgelegt werden. Für jede bestimmte Gruppe kann ein eigenes Passwort benutzt werden. Für die Möglichkeit zur Änderung des Passwortes gelten hier die gleichen Regeln wie bei Punkt 1.

3. Clientseitiges Verschlüsseln und Entschlüsseln
Bei dieser Lösung geht es darum mithilfe einer JS Library die Daten direkt vor dem Abschicken zum Server im Client zu verschlüsseln und zu entschlüsseln. QFQ bekommt daher nur verschlüsselte Daten, die es in der Datenbank ablegen kann. Die Verwaltung des Passwortes ist hier der Knackpunkt.
Wo wird das Passwort im Frontend bestimmt? Im Setting Bereich des Tools unter Sparte Admin?
In welchem Speicher hinterlegen wir das Passwort? Nur im Browser oder nur in der Session der QFQ? Wie sollen die Daten dann für eine beliebige SELECT Abfrage erreicht werden? Vorbeugen nur möglich, wenn PW separiert in der DB auch hinterlegt wird?

Auswahl der Verschlüsselung

SHA:
Ist keine Verschlüsselung und wird fürs Hashing gebraucht und kann nur zur Verschlüsselung verwendet werden. One Way Sicherheit. Entschlüsseln nicht mehr möglich. Eignet sich nicht für unser Vorhaben in der DB.

AES:
Kann für die Verschlüsselung der Daten verwendet werden. Es stehen 128, 192 und 256Bit zur Vefügung und ist die gängigste Methode. Entschlüsseln ist ebenfalls möglich. In erster Linie handelt es sich hier um eine symmetrische Verschlüsselung. Eignet sich in unserem Fall sehr gut für die Verschlüsselung der Daten, da Entschlüsselung gut geht.

RSA:
Ebenfalls möglich zur Verwendung als Verschlüsselung der Daten. Das asymmetrische Verfahren ermöglicht eine komplexere Verschlüsselung durch die Handhabung des Private und Public Keys. Kann auch gut für das QFQ Framework verwendet werden.

https://www.php.net/manual/de/function.openssl-public-encrypt.php

Zugriff - Forms
Verschlüsselte Inhalte, die über das Formular geladen werden, sollten im QFQ auf das Passwort zugreifen können, um die Inhalte zuerst zu entschlüsseln und anschliessend anzeigen zu lassen.
Falls mit dem Passwort Inhalte in der Tabelle abgelegt wurden, würde ein späterer Passwortwechsel dazu führen, dass die vorhin abgelegten Inhalte nicht mehr entschlüsselt werden. Gefahr für Datenverlust, falls Passwort verloren.
Problem:
Es ist sehr wichtig zu wissen was man verschlüsseln möchte. Man sollte die Entscheidung zur Verschlüsselung einzelner FEs dem Frontend Entwicklerteam überlassen und nicht dem Benutzer oder den einzelnen Teammitgliedern. Es kann sein, dass gewisse Informationen für die Filterung von Daten in der DB gebraucht werden aber jedoch vom Benutzer nicht lesbar gemacht wurden und nur dieser das benötigte Passwort besitzt. Wir sind bei den Querys auf die Lesbarkeit der Daten angewiesen, um komplexe Abfragen zu ermöglichen. Das Verschlüsseln der Daten mit einem User spezifischem Passwort kann die Datenbank Funktionalität unberechenbar machen. Die Query Problematik betrifft alle Tabelleninhalte, die nicht für Passwörter benutzt werden.
Lösung:
Das Passwort jeden Benutzers (nur eingeloggte User zählen) müsste an einer zentralen Stelle auf dem Server (Key-Management) mit dem zugehörigen Username abgelegt werden. Beim Laden des einzelnen Tabelleninhaltes muss überprüft werden zu welcher Gruppe gehört der Benutzer, der gerade die Daten lädt.
Ist es jemand aus der Gruppe mit der entsprechenden Berechtigung (Administration) dann wird überprüft von welchem User (Kann Username via Form-Log erfahren werden?) der Inhalt eingetragen wurde und anschliessend das zum Username gehörige Passwort vom Key-Management abgeholt werden. Danach kann mit dem Passwort der Inhalt entschlüsselt werden.

Zugriff - Report
Die Anzeige der verschlüsselten Daten via Report muss immer möglich sein. Hier muss der Zugriff auf das richtige Passwort immer gewährleistet sein. Auf der Typo3 config hinterlegten Passwörter kann ohne Problem zugegriffen werden. Für die Entschlüsselung der Tabelleninhalte braucht es eine eigene Notation:
SELECT p.myInfo AS _s_myInfo => {{s_myInfo:E}}
Problem1:
Falls ein Systemweites Passwort genutzt wird, darf dieser nicht mehr gewechselt werden da ansonsten zuvor verschlüsselte Daten nicht mehr entschlüsselt werden.
Problem2:
Direkter Aufruf der entschlüsselten Daten via Report ist somit nicht mehr möglich. Folgender Syntax führt zur Ausgabe des verschlüsselten Inhalts.
SELECT p.myInfo FROM Person AS p