SQLite mit passwort -303 unsupported feature

[QuickAndDirty]

Zitat:

Zitat von FreddyH (Beitrag 1530883)

Guten Morgen.

Ich habe leider das selbe Problem wir Ihr, nur habe ich noch eine Verständnisfrage:

Warum kann ich das Passwort beim App-Start löschen und
wenn ich das später machen möchte geht es nicht mehr.

Kann mir da jemand eine Antwort geben?

Du musst das machen wenn keine Connection auf der Datenbank aktiv ist.
Also vorzugsweise VOR allem anderen! PLUS, auf diese Weise kannst du
weiter auf die Standard Ausführung Datenbank bleiben. Aber dafür ist die DB dann nicht verschlüsselt...!

Und wenn du das gemacht hast solltest außerdem direkt danach also noch vor dem eigentlichen start der APPlogik die die DB benötigt
die Indices der SQLITE Datenbank validieren (SQLITE dbs können kaputt gehen).

TFDSQLiteValidate.CheckOnly kann das



Danach noch die SQLITE DB verkleinern und defragmentieren(als gelöscht markierte records auch tatsächlich löschen)

TFDSQLiteValidate.sweep kann das

Danach noch die Analyse für die Datenbank starten damit sie schneller wird

TFDSQLiteValidate.Analyze kann das

[FreddyH]

Dankeschön für deine ausführliche Beschreibung.

[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

[johndoe049]

Zitat:

Zitat von Mavarik (Beitrag 1531344)

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:

Zitat von johndoe049 (Beitrag 1531346)

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ß :gruebel:

[QuickAndDirty]

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

[johndoe049]

Zitat:

Zitat von Mavarik (Beitrag 1531349)

Zitat:

Zitat von johndoe049 (Beitrag 1531346)

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.

[johndoe049]

Zitat:

Zitat von himitsu (Beitrag 1531350)

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ß :gruebel:

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?