SQLite mit passwort -303 unsupported feature

[johndoe049]

Zitat von Mavarik:

Es gibt gerade 3 Threads mit dem gleichen Thema.

SEE…

Aber keiner will $2000 zahlen.

Ich kenne mich zwar damit nicht aus, aber ist das wirklich Rocketsience oder warum gibt es dafür noch keinen Freeware/Open Source Ersatz?

Mavarik

SQLite hat eine transparente Echtzeitverschlüsselung. D.h. die Engine übernimmt die komplette Verschlüsselung und das Zugriffsmanagement. Zwar keine Raketenwissenschaft, jedoch schwer einzubauen, wenn der Hersteller von SQLite den Zugriffspunkt/Einsprungpunkt für ein externes Verschlüsselungsmodul aus dem Open Source entfernt und kostenpflichtig macht. Da muss man selbst nach dem Einsprungpunkt für das Speichern/Lesen suchen und dann einbauen. Da ist es einfacher, einzelne Felder mit wichtigen Daten Satzweise zu verschlüsseln.

SQLite mit Verschlüsselung als Open Source gibt es bei Zetetic.net. Man muss es nur selbst kompilieren.

[Mavarik]

Zitat von johndoe049:

Da ist es einfacher, einzelne Felder mit wichtigen Daten Satzweise zu verschlüsseln.

Klar, das Problem ist nur, dass man dann für diese Felder keinen Select ausführen kann.

Mavarik

[himitsu]

Nja, entweder den entsprechenden TField-Nachfahren ableiten und dort die Ent-/Verschlüsselung einbauen,
oder beim SQLite eine/zwei User-Functions registrieren, welche sich dann, wie eine StoredProc, im SELECT zur Entschlüsselung, bzw. im INSERT/UPDATE für die Verschlüsselung nutzen ließe.

https://www.sqlite.org/appfunc.html
Ob da jetzt FireDAC was hat, oder man sich direkt an die DBEngine wenden muß

[QuickAndDirty]

Für mich ist das nur ein State und Einstellungspeicher für eine APP. man darf das Smartphone halt nicht verlieren.

[johndoe049]

Zitat von himitsu:

Nja, entweder den entsprechenden TField-Nachfahren ableiten und dort die Ent-/Verschlüsselung einbauen,
oder beim SQLite eine/zwei User-Functions registrieren, welche sich dann, wie eine StoredProc, im SELECT zur Entschlüsselung, bzw. im INSERT/UPDATE für die Verschlüsselung nutzen ließe.

https://www.sqlite.org/appfunc.html
Ob da jetzt FireDAC was hat, oder man sich direkt an die DBEngine wenden muß

Soweit ich das verstanden habe muss das direkt in der DBEngine sein.

Firedac hat die Verschlüsselung als Hook mit an die DBEngine übergeben bzw. sich transparent eingehängt. Nur fehlt in den neuen Versionen der entsprechende Hook, wo Firedac sich einhängen kann.

Wenn Verschlüsselte Werte übergeben werden, wird es mit Select, usw. wieder interessant.

[QuickAndDirty]

Wenn das Passwort der Datenbank sowieso im selben Gerät wie die Datenbank gespeichert ist, dann verlangsamt die Verschlüsselung einfach nur alles ohne wirklich etwas zu bringen.
Geben eure User das Datenbankpasswort immer selber ein, bei jedem Start der App?

[Mavarik]

Zitat von QuickAndDirty:

Wenn das Passwort der Datenbank sowieso im selben Gerät wie die Datenbank gespeichert ist, dann verlangsamt die Verschlüsselung einfach nur alles ohne wirklich etwas zu bringen.
Geben eure User das Datenbankpasswort immer selber ein, bei jedem Start der App?

Naja…
Es geht ja darum die Daten zu schützen. Ob das Passwort in der App gespeichert ist spielt dabei keine Rolle. Mit der Verschlüsselung wird gewährleistet, dass der Zugriff nur über die App erfolgen kann und nicht die Daten einfach so kopiert werden können.

[himitsu]

Aber theoretisch bestünde die Möglichkeit das nötige Passwort/Schlüssel aus dem Programm auszulesen, da er unverschlüsselt oder zumindestens entschlüsselbar darin rumliegt.

[johndoe049]

Zitat von Mavarik:

Zitat von johndoe049:

Da ist es einfacher, einzelne Felder mit wichtigen Daten Satzweise zu verschlüsseln.

Klar, das Problem ist nur, dass man dann für diese Felder keinen Select ausführen kann.

Mavarik

Richtig.

Die Firma Passwork "umgeht" das Problem damit, dass Hashs für alle möglichen Zeichenfolgen mit xxx Zeichen abgespeichert werden. Funktioniert mäßig. Manchmal findet man einen Eintrag nur, wenn man den kompletten Suchbegriff und nicht nur einen Teil kennt.

Transparente Verschlüsselung ist daher besser.