Ist Firebird sicher genug für eine Passwort-Datenbank?

[Perlsau]

Hallo Entwickler-Profis,

derzeit arbeite ich an der Umsetzung einer kleinen Passwort-Datenbank für mehrere Benutzer. Zum Einsatz kommt die Firebird embedded Version 2.1. Nun meine Frage:

Ist die Datenbank gegenüber Hackerangriffen ausreichend geschützt, so daß auch ein Hacker, der in Abwesenheit des Benutzers die Datenbank zu knacken versucht, daran mit hoher Wahrscheinlichkeit scheitern wird?

Oder wäre es besser, die Daten in der Datenbank vor dem Einspeichern zu verschlüsseln und sie beim Lesen vor dem Anzeigen wieder zu entschlüsseln? Verfügt Firebird über De- und Encodierungsmethoden?

[Thomas Steinmaurer]

Firebird unterstützt keine Verschlüsselung, d.h. das wirst du in deiner Anwendung regeln müssen.

[Perlsau]

Datenklau

Firebird unterstützt keine Verschlüsselung, d.h. das wirst du in deiner Anwendung regeln müssen.

Hab es eben auch herausgefunden, dennoch danke für deinen Hinweis.

[Markus Kinzler]

das ist aber ein Feature von Vulcan, welches auch in firebird 3 einfliessen soll/wird.

[Perlsau]

das ist aber ein Feature von Vulcan, welches auch in firebird 3 einfliessen soll/wird.

Moin Markus,

keine Ahnung was Vulcan ist. Sobald Firebird 3 rauskommt, werde ich wohl updaten. Bin echt schon gespannt ...

Meine ursprüngliche Frage lautete: kann man ohne weiteres eine passwortgeschützte Firebird-Datenbank knacken? Gerade für eine Passwort-Datenbank wäre das fatal ... Meine Vorab-Version (Freeware, da Clientsoftware noch ohne Passwortschutz) kann man sich dort herunterladen.

[Markus Kinzler]

Vulcan ist der alternative Kern, der der ursprüngliche Interbase-Entwicker Jim Starkeyt. Dieser wurde an die FireBird Foundation übergeben und wird nun stückweise in FireBird integriert ( beginnend ab 2.1)
https://www.ibphoenix.com/resources/documents/attic

[Perlsau]

Vulcan ist der alternative Kern, der der ursprüngliche Interbase-Entwicker Jim Starkeyt. Dieser wurde an die FireBird Foundation übergeben und wird nun stückweise in FireBird integriert ( beginnend ab 2.1)
https://www.ibphoenix.com/resources/documents/attic

Okay, das ist jetzt wohl nicht so mein Ding, viel zu viele englische Fachausdrücke. Viel wichtiger aber ist mir die Frage, wieviele Möglichkeiten der Zugangsdaten-Gestaltung gibt es bei einer Datenbank, die einen Usernamen mit höchstens 31 Zeichen und ein Passwort mich höchstens 8 Zeichen erfordert. Allein schon die Möglichkeiten des Usernamens sind astronomisch: 30 mal die Operation 223 * 223 ausführen, wobei ich davon ausgehe daß alle Zeichen ab CHR(33) bis CHR(255) erlaubt sind.

Anzahl Möglichkeiten bei:

08 Zeichen: 000.000.000.006.115.597.639.891.380.481
09 Zeichen: 000.000.001.363.778.273.695.777.847.263
10 Zeichen: 000.000.304.122.555.034.158.459.939.649
11 Zeichen: 000.067.819.329.772.617.336.566.541.727
12 Zeichen: 015.123.710.539.293.666.054.338.805.121
...
20 Zeichen: 9,2490528480504741224589199751839e+46
...
31 Zeichen: 6,272645651863006903409722664616e+72

multipliziert man das mit der Zahl der Möglichkeiten, ein Passwort zu generieren, erhält man diese unglaubliche und unvorstellbare Zahl:
3,8360976944408334868233406617038e+91

Ich glaube fast, daß das ausreicht, um eine Firebird-Datenbank vor einem Brute-Force-Angriff zu schützen.

Was meint ihr?

[Markus Kinzler]

Notfalls musst du halt zusätzlich die daten darin programmseitig verschlüsseln

[Perlsau]

Wäre nicht wirklich ein Problem.

Notfalls musst du halt zusätzlich die daten darin programmseitig verschlüsseln

Das hab ich schon einmal gemacht, und zwar bei einer kleinen Adressverwaltung auf Access-Basis: weil man Access angeblich so leicht knacken kann, hat der Kunde gewünscht, seine Daten verschlüsselt abzuspeichern. Ich hab dann für jede Spalte einen anderen Schlüssel genommen und denke, das war dann wohl sicher ausreichend. Ver- und entschlüsselt hab ich mit dem Cipher aus den Jedi-Komponenten. Die Schlüssel waren im Programm wahllos an verschiedenen Stellen verteilt und wurden erst durch die Anwendung korrekt zusammengesetzt. Zudem hab ich noch zwei weitere Techniken reversibler "Unkenntlichmachung" angewandt.

Bei Access wird nur ein Passwort verwendet, das aber auch ellenlang sein kann. Die Kombination Username/Passwort bei Firebird scheint mir nach den oben angestellten Überlegungen und meinen gestrigen vergeblichen Versuchen, eine meiner eigenen Datenbanken, für die ich die Zugangsdaten nicht auswendig weiß und erst nachschauen müßte, via "brute force" zu knacken, nun doch sicher genug. Auch konnte ich zum Thema "Daten-Verschlüsselung +Firebird" nichts im Netz finden und gehe daher davon aus, daß das keiner macht. Natürlich kann man auch mit einer Passwortliste arbeiten und herauszufinden suchen, ob der Anwender naheliegende Usernamen und Passwörter verwendet. Ich verwende daher immer Zufalls-Kombinationen, die keinerlei Sinn ergeben: Username 31 Zeichen lang, Passwort 8 Zeichen, sieht dann vielleicht so aus:
ntkghqwe1bghaß009jnnsz8za7tr5xz / u1n89d8h
Da kommt keiner drauf ...

[Torsten Grundke]

Hallo,


Benutzername + Passwort bietet Dir bei Firebird keine Sicherheit!!!

Sobald man physikalischen Zugriff auf die Datenbankdatei hat ist die Kombination Benutzername + Passwort kein ernsthaftes Hindernis mehr.

Die Benutzernamen und Passwörter werden in einer Sicherheitsdatenbank abgelegt und die ist völlig unabhängig von Deiner Datenbank.

Mit dem Benutzernamen "SYSDBA" hat man sowieso Zugriff auf Deine Datenbank, d.h. man benötigt nur das Passwort vom SYSDBA.

Wenn man es nicht kennt tauscht man entweder die Sicherheitsdatenbank aus oder man kopiert die Datenbankdatei auf einen Rechner mit installiertem Firebird und bekanntem Passwort vom Benutzer SYSDBA.


D.h. die Daten müssen bereits verschlüsselt in der DB gespeichert werden.

Beim Einsatz des "Embeded-Servers" und Benutzung des Benutzers "SYSDBA" spielt das Passwort überhaupt keine Rolle (bei lokaler Datenbank).



Tschau

Torsten