Wichtig
Kleinigkeit
Fehlerbehebung
Wichtig
Sorry, das wird jetzt ein kleiner Roman, aber ich will einfach mal das nun gelernte irgendwo hinschreiben:
TLDR;
In Abstimmung mit BHU ist das aktuelle Fazit, auf die Verschlüsselung zu verzichten, die Passworte mit Salt+Hash zu speichern und einen opitonalen "pepper" in der Anwendungskonfiguration vorzusehen, mit dem man Passworthashes auf die jeweilige Instanz beschränken kann. Der Sicherheitsgewinn dieser Option ist fragwürdig, weshalb sie als default deaktiviert wäre. Pwd Hashes wären somit unter den Top-Logic Instanzen austauschbar, was Datenaustausch und Infrastrukturmaßnahmen erleichtern würde.
Die gesammelten Erkenntnisse auf dem Weg dahin:
Aktuell werden die Nutzerpassworte lokal administrierter Nutzer (hoffentlich) gehashed und diese Hashes dann mit einem auf dem Server dynamisch (beim ersten Serverstart) generierten Schlüssel symmetrisch verschlüsselt. Wird der Schlüssel beim nächsten Serverstart im Dateisystem gefunden und erfolgreich eingelesen, wird er weiter verwendet, sonst wird ein neuer erzeugt.
Soweit so gut - hierdurch werden Brutforce Angriffe oder die Verwendung von Rainbow Tables erschwert. Insbesondere ist so aber auch nicht möglich, auf Datenbankebene einfach den Hash eines bekannten Passworts von einer Top-Logic Instanz in eine andere zu kopieren, um das Passwort zu übertragen. Durch diese zusätzliche Verschlüsselung der Passworthashes mit einem serverlokal generierten Schlüssel lässt sich also ggf. ein zusätzlicher Sicherheitsgewinn argumentieren.
Allerdings ist das auch irgendwie lästig, weil man eben nicht einfach ein root-passwort ausliefern oder mal eben die Daten zwischen einzelnen Umgebungen hin und her kopieren kann. Daher wurde dieser Schlüssel als "keyPair_signature.key" regelmäßig mit ausgeliefert und deployed. Damit ist der vorab beschriebene Sicherheitsgewinn zunichte gemacht, weil nun doch wieder alle Instanzen denselben Schlüssel verwenden und die Hashes damit übertragbar werden.
Schlimmer noch: Man *muss* dieses Keyfile sogar mit ausliefern, weil ein dynamisch generiertes Key File auf dem Server in WEB-INF/database/keys liegen würde und damit mit jedem neuen Deployment gelöscht würde und neu generiert werden müsste: Die gespeicherten Passworthashes würden mit jedem Deployment ungültig.
Was dann auch immer wieder auftauchende Tickets über nicht funktionierende Root-Passworte erklären könnte, wenn z.B. PROD Daten nach QS kopiert wurden oder einfach neu deployed wurde.
Dummerweise ist dieser (ausgelieferte) Schlüssel in der genannten Datei als serialisiertes Java Objekt gespeichert. Im Falle von Prime / MPM funktioniert das spätestens mit Websphere Liberty nicht mehr, weil IBM JVM 8 ein mit Oracle/Sun serialisiertes Key File nicht einlesen kann.
Ein Problem entsteht nun also immer, wenn die Daten (einschließlich gespeicherter Passwort Hashes) von einer Umgebung auf eine andere übernommen werden sollen und der von uns ausgelieferte Schlüssel nicht funktioniert: Die neue Umgebung würde dann ihren eigenen (neuen) Schlüssel verwenden und könnte damit die bereits gespeicherten Passworthashes nicht entschlüsseln. Dafür müsste der Schlüssel der bisherigen Instanz in die neue Installation übernommen werden:
- Hierfür gibt es keinen standardisierten Weg. Dieser Schlüssel liegt auf dem Applikationsserver unter web-inf/database/keys und kann nicht einfach ausgelesen werden. Er müsste manuell in die neue Instanz kopiert werden. Das ist bei Kundeninstallationen schwer zu organisieren.
- Unglücklicherweise wurde dieser Schlüssel als serialisiertes Javaobjekt abgelegt, d.h. selbst wenn man die Datei in die neue Umgebung kopiert, ist nicht sichergestellt, dass sie mit der neuen JVM auch deserialisiert werden kann.
Konkret gibt es für den Umzug von Prime und MPM auf Websphere Liberty nur eine Strategie:
- Wir lieferen ein Key File (als serialsiertes Java Objekt) für die Zielumgebung IBM JVM 8 mit und liefern im Rahmen der Datenmigration einen dafür passenden Hash für das root Passwort. Damit kann man sich nach der Migration als root anmelden und muss dann die Passworte aller anderen Datenbankbenutzer zurücksetzen. Nachteil: Wenn wir das Key file mitliefern, wird auf allen Instanzen der gleiche Schlüssel verwendet, d.h. die Passworthashes wären zwischen den Instanzen austauschbar.
Das Key File für diese Zielumgebung muss (wie bisher auch schon) bei allen Folgelieferungen mitgeliefert werden.
Die Verwendung des bisherigen Keyfiles scheidet aus, weil IBM JVM 8 diese Datei nicht einlesen kann und die dynamische Erzeugung neuer Schlüssel in den Liberty Umgebungen scheidet aus, weil diese bei jedem Deployment gelöscht und neu generiert würden.
Zukünftige Lösungsmöglichkeiten für Top-Logic. Wie macht mans richtig?:
Passworthashes weiterhin verschlüsseln? Wenn man an der Verschlüsselung von Passworthashes festhalten will, sollte so ein Schlüssel mindestens in einer Form persistiert werden, die prinzipiell eine Übername in eine andere Umgebung erlaubt. Eine einfache Textdatei ist gut genug. Die könnte man in obigem Szenario in die neue Umgebung kopieren und die bereits gespeicherten Passworthashes wären weiterhin gültig. Aktuell ist es halt die serialisierung eines Java Objekts, das in der Zielumgebung (in Abhängigkeit von der verwendeten JVM) nicht deserialisiert werden kann.
Passworte "salten"? Und nicht verschlüsseln? Man kann aber auch auf die Verschlüsselung der Passworthashes verzichten. Stattdessen sollten Passworte (sowieso) mit einem Salt versehen gehashed werden und die hashes gemeinsam mit dem Salt in die Datenbank gespeichert werden.
Passworte zusätzlich "peppern"? Um die erfolgreiche Übertragung solcher Hashes auf andere Top-Logic Instanzen zu verhindern, könnte man die Passworte zusätzlich mit einem "pepper" versehen. So ein "pepper" wäre für jeweils eine Serverinstanz gültig und in irgeneiner Weise (am besten nicht in der selben Datenbank wie die Passwort hashes) persistiert. Die Anwendungskonfiguration wäre ein Kandidat. Dieser "pepper" geht dann in alle PWD hashes dieser Instanz mit ein. Hierdurch wird die Verwendung dieser Hashes auf einer anderen Instanz verhindert. Wodurch sich die gleichen Probleme wie vorab beschrieben, bei einem Umzug auf eine neue Umgebung mit Übernahme vorab gespeicherter Passworthashes ergeben. Es müsste nun sichergestellt werden können, dass die neue Umgebung den gleichen "pepper" benutzt wie die vorherige, damit die gepeicherten Hashes weiter verwendet werden können. Die Verwendung eines "pepper" könnte optional und per default einfach deaktiviert sein. Eigentlich ist der Gedanke ganz nett: So könnten Passworthashes zwar zwischen mehreren Prime Instanzen eines Kunden (die alle den gleichen Pepper verwenden) austauschbar sein, aber nicht mit anderen Top-Logic Apps wie z.B. MPM und auch nicht mit Instanzen anderer Kunden.
Umsetzung
Es wurde die Möglichkeit geschaffen, dass Passwort mit dem Argon2-Algorithmus (https://github.com/P-H-C/phc-winner-argon2) zu hashen. Dieser nutzt einen "salt" und es kann in der Anwendungskonfiguration ein "pepper" konfiguriert werden.
Test
TestArgon2Hashing