Pseudo Kennwörter haben schon bei
Access oder
Paradox zu Pseudosicherheit geführt. Wenn das grundlegende Konzept dahinter nicht sinnvoll ist, fühlt man sich zwar sicher, ist es aber nicht.
FB3 wird laut Releasenotes eine Database encryption haben und auch veränderte Sicherheitsmechanismen, die ich aber auch noch nicht alle durchgetestet habe. Wenn es aber jemand drauf anlegt, wird der vermutlich auch dazu eine Backdoor finden, siehe OpenSSL und andere Tools, deren zentrale Funktion Verschlüsselung ist und die trotzdem gehackt wurden.
Wenn dein Kunde Probleme damit hat, sollte der die
DB auf vom Betriebsystem verschlüsselte Partitionen packen, dann kann man die auch nicht so einfach klauen. Windows bietet dafür bei pro oder enterprise version eingebaute Tools, Linux sowieso.
Schau dir zum Beispiel unseren Menüpunkt Tools-Database Inside an. Damit lesen wir den Inhalt der
DB aus, auch wenn große Teile der
DB korrupt sind. Warum sollten wir ein Kennwort, das irgendwo im Header steht, überhaupt berücksichtigen, wenn der Rest weiter unverschlüsselt ist. Database inside nutzt keien einzige Bibliothek von Firebird. Ohne gesamte Datenbankverschlüsselung ist es ein einfaches, ggf auch eine Firebird Server Variante zu erstellen, die eventuelle neue Mechanismen einfach ignoriert.
Lass dich nicht davon blenden, eine unverschlüsselte Interbase Datenbank mit embedded Security ist eine Lachnummer und wiegt dich in einer Pseudosicherheit, die nicht existiert. Und ob die eingebaute Verschlüsselung irgendwas taugt weiß ich nicht, ich kenne keinen einzigen Kunden, der das einsetzt, weil diejenigen, die das getestet haben, mit dem Performanceverlusten nicht klar kamen und das gleich wieder deaktiviert haben.
Wenn du damit ggf was vor deinen Kunden verbergen willst, ist das eh ein sehr schwieriges Feld und abhängig davon, was deine Kunden können und warum die keine root/admin zugriff haben sollen.