SQLite mit passwort -303 unsupported feature

[QuickAndDirty]

Habe ein Projekt von Delphi XE11 nach XE 12 übernommen.
Nun folgende Laufzeitfehler.

Auf Android32 kann eine SQLite Connection nicht mehr mit dem einem gesetzten 'Password' parameter erstellt werden.
Es kommt die meldung -303 unsupported feature. "-303. Funktionalität wird nicht unterstützt"
Die Datenbank ist zudem zeitpunkt noch nicht erstellt!
Mit Leerstring als 'Password' und ohne 'Password' parameter geht es.

Außerdem funktioniert unter windows
dieser Code, compiliert mit Delphi XE 12, nicht auf einer mit mit Delphi XE 11 mit passwort erstellten SQLite datenbank .

Delphi-Quellcode:

    fFDSQLiteValidate := TFDSQLiteValidate.Create(nil);
    try
      fFDSQLiteValidate.Database := aDatabase;
      fFDSQLiteValidate.Password :=  FPassword;
      fFDSQLiteValidate.DriverLink := FPhysSQLiteDriverLink;
      fFDSQLiteValidate.MaxErrors := 10;
      fFDSQLiteValidate.Options := [voCheckIndexes];//[voCheckIndexes]= StandardCheck or [] = QuickCheck
      fFDSQLiteValidate.OnProgress := CheckOnlyProgressEvent;
      fFDSQLiteValidate.OnError := CheckOnlyErrorEvent;
      try
        Result := fFDSQLiteValidate.CheckOnly;
      Except
        On E:Exception do
        Begin
          Result := false;
          FLastCheckOnlyErrorMessage := e.Message;
          Tlog.d(FLastCheckOnlyErrorMessage);
        End;
      end;
    finally
      fFDSQLiteValidate.free;
    end;

Wenn fPassword gesetzt ist, kommt "-303 unsupported feature"
Wenn Fpassword leerstring ist , kommt "Error: file is not a database"

Ist das Phänomen bekannt und die Lösung auch?

[Uwe Raabe]

Versuch mal, irgendwo im Projekt die Unit FireDAC.Phys.SQLiteWrapper.FDEStat in die uses-Anweisung aufzunehmen.

[QuickAndDirty]

Interessant.
jetzt geht es.
Kann man die magische passwort unit auch 2 mal unterbringen, damit die units die SQLite Passwörter verwenden in jedemfall funktionieren ?

Was hat sich da von XE11 auf XE12 geändert, dass ich diese unit jetzt brauche?
Edit:
Ok, also es ist einfache eine import unit für eine DynLib .
Mit Kompiler schaltern für dynamisches laden oder statisches linken.
War das was hier
FireDAC.Phys.SQLiteWrapper.FDEStat
drin ist früher in
FireDAC.Phys.SQLiteWrapper enthalten und jetzt nicht mehr?

Edit2:
FireDAC.Phys.SQLiteWrapper.FDEStat
FireDAC.Phys.SQLiteWrapper.Stat
Was ist der Unterschied?
ich habe voher FireDAC.Phys.SQLiteWrapper.Stat benutzt. Muss ich diese unit jetzt ausbauen?

[Uwe Raabe]

Die Unit FireDAC.Phys.SQLiteWrapper.FDEStat muss verwendet werden um das alte Encryption-Verfahren zu verwenden. Sie muss nach FireDAC.Phys.SQLiteWrapper.Stat stehen, damit die Default-Engine auf FDE geändert wird.

Wenn du sichergehen willst, platziere einen

Delphi-Quellcode:

TPhysSWLiteDriverLink

auf ein Form und setze das

Delphi-Quellcode:

EngineLinkage

Property auf

Delphi-Quellcode:

slFDEStatic

. Damit kann dir die Default-Engine egal sein.

[QuickAndDirty]

Danke.
Ich bin leicht schockiert weil ich diesen schrecklichen blog post fand. (Ich hab nur Delphi kein C++)
https://blogs.embarcadero.com/new-fi...or-sqlite-see/

Also der eigentliche Grund für das Gehampel ist, dass wir bei dem alten binary 'libsqlite.a', 'sqlite3_x86.obj' und 'libcgsqlite3.dylib' bleiben können ?
Weil die neuen Versionen dieser Dateien keine Encryption mehr unterstützen und Encryption jetzt ein Premium-Feature ist was man über einen SEETreiber nachkaufen muss?

Also Enshittyfication wie bei games?

Früher hat Firedac immer eine Login Meldung gebracht oder eine andere nervige Warnung, wenn man eine Datenbank mit leerem oder Ohne Password versucht hat zu connecten... deswegen hat die Datenbank ein Passwort.
Muss ich jetzt meine SQLite Datenbank, um zukunftsicher zu sein, von einer DB mit Passwort in eine ohne Passwort umwandeln? Und wird dann wieder eine Meldung kommen wenn die DB kein Passwort hat?

Edit: Auf Android geht es ohne passwort aber wie bekommt man Daten von der alten verschlüsselten DB in die Neue?
TFDBatchMove ??

[QuickAndDirty]

Wenn ich beide Units verwende

Delphi-Quellcode:

uses
FireDac.Phys.SQLiteWrapper,
FireDAC.Phys.SQLiteWrapper.Stat, //diese
FireDAC.Phys.SQLiteWrapper.FDEStat; //und diese

bekomme ich beim linken für Android den fehler

Code:

[DCC Fehler] E2597 C:\Users\Public\Documents\Embarcadero\Studio\23.0\CatalogRepository\AndroidNDK-21-23.0.50491.5718\android-ndk-r21\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-ld.exe: error: c:\\program files (x86)\\embarcadero\\studio\\23.0\\lib\\Android\\Release/libsqlite_fde.a(sqlite3_fde.o): multiple definition of 'sqlite3_aggregate_context'
  C:\Users\Public\Documents\Embarcadero\Studio\23.0\CatalogRepository\AndroidNDK-21-23.0.50491.5718\android-ndk-r21\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-ld.exe: c:\\program files (x86)\\embarcadero\\studio\\23.0\\lib\\Android\\Release/libsqlite.a(sqlite3.o): previous definition here
  C:\Users\Public\Documents\Embarcadero\Studio\23.0\CatalogRepository\AndroidNDK-21-23.0.50491.5718\android-ndk-r21\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-ld.exe: error: c:\\program files (x86)\\embarcadero\\studio\\23.0\\lib\\Android\\Release/libsqlite_fde.a(sqlite3_fde.o): multiple definition of 'sqlite3_aggregate_count'

Also diesen fehler bekomme ich für so ziemlich jede Funktion in sqlite3_fde.o und sqlite3.o
Eine laaange list von Fehlern und dann den Linker Error

Code:

[DCC Fataler Fehler] F2588 Linker-Fehlercode: 1 ($00000001)

In windows geht es nur Android meckert.
Ich brauche beide , um Die Datebank zu konvertieren.
Muss ich den FDEStat import modifizieren?

[Uwe Raabe]

Zitat:

Zitat von QuickAndDirty (Beitrag 1529733)

Wenn ich beide Units verwende
...
bekomme ich beim linken für Android den fehler
...
In windows geht es nur Android meckert.

Das steht so auch in der Doku:

Zitat:

For Android, Linux, and iOS platforms, only one static linkage unit may be included in a project simultaneously. In other words, you can use either FireDAC.Phys.SQLiteWrapper.Stat or FireDAC.Phys.SQLiteWrapper.FDEStat, but you cannot use both in the same project. If you do, the linker will generate errors because of duplicate symbols.

[Sinspin]

Zitat:

Zitat von QuickAndDirty (Beitrag 1529668)

Also der eigentliche Grund für das Gehampel ist, dass wir bei dem alten binary 'libsqlite.a', 'sqlite3_x86.obj' und 'libcgsqlite3.dylib' bleiben können ?
Weil die neuen Versionen dieser Dateien keine Encryption mehr unterstützen und Encryption jetzt ein Premium-Feature ist was man über einen SEETreiber nachkaufen muss?

:evil:
Das erfordert ein bisschen Ausdauer, aber das ist offensichtlich eine gute Methode um Steinreich zu werden:
- Bring eine Software für Lau auf den Markt
- Warte bis die Software "überall" verwendet wird
- Entferne ein wesentliches Feature der Software und verkaufe es gegen Lizenzen die so abartig teuer sind dass dich jeder dafür hasst.

[mytbo]

Zitat:

Zitat von Sinspin (Beitrag 1529737)

Zitat:

Zitat von QuickAndDirty (Beitrag 1529668)

Also der eigentliche Grund für das Gehampel ist, dass wir bei dem alten binary 'libsqlite.a', 'sqlite3_x86.obj' und 'libcgsqlite3.dylib' bleiben können ?
Weil die neuen Versionen dieser Dateien keine Encryption mehr unterstützen und Encryption jetzt ein Premium-Feature ist was man über einen SEETreiber nachkaufen muss?

:evil:
Das erfordert ein bisschen Ausdauer, aber das ist offensichtlich eine gute Methode um Steinreich zu werden:
- Bring eine Software für Lau auf den Markt
- Warte bis die Software "überall" verwendet wird
- Entferne ein wesentliches Feature der Software und verkaufe es gegen Lizenzen die so abartig teuer sind dass dich jeder dafür hasst.

Nein, das ist nicht der Grund. Im Repro steht: "Simplify the code by removing the unsupported and undocumented...". Den offiziellen Weg mag nur nicht jeder gehen. mORMot geht ihn:

Code:

After a lot of painful debugging and adaptation in plain C, we just updated SQLite3 to latest 3.32.2 revision
- switched to VFS pattern for encryption
- sqlite3 cross-compilation is now done from Linux scripts

Den Bremsklotz für eine Umsetzung bei Embarcadero deutet vermutlich das Wort "painful" an.

Bis bald...
Thomas

[Sinspin]

Es geht nicht um Emba. Ich kann verstehen wenn man sich da lieber an Funktionen hält die zuverlässig funktionieren. Es fällt sonst auf Emba zurück wenn der Kram nicht ordentlich geht.

Sqllite.org : SEE (Sqllite Encryption Extension) :
Product To Purchase: SEE Source Code License Only ($2000 USD)
Das meine ich!

<OT>
Btw, ich bekomme keinen einzigen Blog Post von Emba auf. Ich sehe die Hauptseite.
Ein Cclick auf einen Post zeigt mir nur immer wieder die Hautpseite an, auch wenn sich die Adresszeile ändert als würde in einen Beitrag gewechselt. Browser : Chrome.latest.
<OT>

[QuickAndDirty]

Zitat:

Zitat von Uwe Raabe (Beitrag 1529735)

Zitat:

Zitat von QuickAndDirty (Beitrag 1529733)

Wenn ich beide Units verwende
...
bekomme ich beim linken für Android den fehler
...
In windows geht es nur Android meckert.

Das steht so auch in der Doku:

Zitat:

For Android, Linux, and iOS platforms, only one static linkage unit may be included in a project simultaneously. In other words, you can use either FireDAC.Phys.SQLiteWrapper.Stat or FireDAC.Phys.SQLiteWrapper.FDEStat, but you cannot use both in the same project. If you do, the linker will generate errors because of duplicate symbols.

Ja natürlich aber welches ist das doppelte symbol?
Ist es in den libraries? Also darf ich generell nicht libraries einbinden in denen sich die namen überschneiden?
Oder ist das "SYMBOL" der delphi Functions name in den import units?

Weil dann könnte ich den import modifizieren und einen modifizierten wrapper erstellen und es würde gehen oder?

[QuickAndDirty]

Zitat:

Zitat von Sinspin (Beitrag 1529750)

Es geht nicht um Emba. Ich kann verstehen wenn man sich da lieber an Funktionen hält die zuverlässig funktionieren. Es fällt sonst auf Emba zurück wenn der Kram nicht ordentlich geht.

Sqllite.org : SEE (Sqllite Encryption Extension) :
Product To Purchase: SEE Source Code License Only ($2000 USD)
Das meine ich!

Oder du verkaufst einen Oberklasse Wagen und dann müssen die Bonzen ein Abo abschleißen um sich den Popo wärmen zu lassen....hahahahaha
Oder du verkaufst ein Schiff von einem Luxusauto weit teurer als manchens Einfamilienhaus und dann muss der Käufer ein Abbo für vollständige Hinterradlenkung abschließen. :thumb:
Oder du Programmierst ein Spiel aber alle models sehen langweilig und seelenlos aus und die Kinder müssen teure Skins kaufen um auf dem Schulhof nicht als "Default" gemobbt zu werden.

SQLite fühlt sich so ein bisschen wie MYSQL an oder wie der Tag als oracle Sun gekauft hat und das freie Java auf einmal unfrei wurde und Elison von SAP und Google kohle eingefordert hat.

Ich will einfach auf einer Installierten app durch ein einziges Update die Datenbank der App von Verschlüsselt auf Unverschlüsselt umstellen.
Also muss ich beide binaries haben. Eine zum umstellen, die andere um mit dem umsonst model auf der DB zu arbeiten. Für die Zukunftsfähigkeit.

Es ist so traurig, dass genau das wieder nicht funzt wo die programme in Sandboxes eingesperrt sind.

Muss ich jetzt die DB hochladen auf einen unsere Windows Server die dann umwandelt und wieder zurück auf das smartphone sendet? Das kann es doch nicht sein.

[QuickAndDirty]

Zitat:

Zitat von petroben (Beitrag 1529765)

It seems like you're encountering issues related to SQLite database connections and password handling in Delphi XE12. The error "-303 unsupported feature" suggests that there might be an issue with the password parameter.
[….SPAMURL…..]
For Android32, it appears that setting a password results in an unsupported feature error. Try using an empty string or omitting the password parameter to see if that resolves the issue on Android.

For the Windows issue, where you're getting an error related to the password, it might be worth checking if there are changes in how password-protected SQLite databases are handled between Delphi XE11 and XE12. Make sure the password handling is consistent with the version of SQLite you are using.

I know. We figured this out. Now we look for away around it. There are allready workarounds, but they are not nice enough to suit my spoiled ego .

Zitat:

Zitat von petroben (Beitrag 1529765)

As for monads, they are a concept from functional programming. In short, monads are a design pattern used to handle computations with side effects in a pure functional way. However, it seems unrelated to the specific issues you're facing in your Delphi project. If you have any more details or specific questions about the Delphi issues, feel free to provide more information.

That Monad question is a meme in my signature. As everybody knows, in a Nutshell,a monad is a monoid in the category of endofunctors. Obviously!

[QuickAndDirty]

So hätte die Konveriterung von "SQLITE gut" nach "SQLITE schlecht aber umsonst" aussehen können.

Delphi-Quellcode:

procedure TDbHealth.ConvertOldDBToNewDB(aDestpassword:String; aDestDBFilename:String= '');
var  fFDSQLiteBackup:TFDSQLiteBackup;
begin
  TSync.DB_CS.Acquire;
  try
    FPhysSQLiteDriverLink.EngineLinkage := slFDEStatic;
    fFDSQLiteBackup := TFDSQLiteBackup.Create(nil);
    try
      fFDSQLiteBackup.Database :=  FDatabase;
      fFDSQLiteBackup.Password :=  FPassword;
      fFDSQLiteBackup.DriverLink := FPhysSQLiteDriverLink;
      fFDSQLiteBackup.DestDatabase := aDestDBFilename;
      fFDSQLiteBackup.DestPassword := aDestpassword;
      fFDSQLitebackup.WaitForLocks := true;
      fFDSQLiteBackup.DestMode := smCreate;// smCreate, smReadWrite, smReadOnly
      fFDSQLiteBackup.Backup;
    finally
      fFDSQLiteBackup.Free;
    end;
    FPhysSQLiteDriverLink.EngineLinkage := slDefault;
    tFile.Delete(FDatabase);
    FDatabase := aDestDBFilename;
    fPassword := aDestpassword;
  finally
    TSync.DB_CS.Release;
  end;
end;

Die Datenbank hätte danach einen Neuen Namen und ein neues passwort und die App könnte durchstarten und sich auf die Neue Passwortfreie unverschlüsselte SQLITE DB verbinden... und das funktioniert auch in Windows...

Ist die Frage ob man die Imports und Wrapper passend modifizieren kann, das der Linker die in Andoird und IOS mitnimmt.

[zeras]

Ich habe nun auch ein Windowsprogramm auf D12 umstellen wollen. Dann habe ich auch "-303xxx" bekommen. Daraufhin die o.g Unit eingebunden und schon lief das Progamm erst einmal. Dann wollte ich mir die Datenbank mit dem Programm "DB Browser for SQLite" anschauen. Da kam die Meldung, "Datenbankdatei konnte nicht geöffnet werden. Grund: file is not a database.
Zum Test habe ich dann das gleiche Programm unter D11 compiliert. Dann wieder versucht, die Daten mit dem DB Browser anzeigen zu lassen. Das ging dann auch nicht mehr.
Nun habe ich mir einmal eine ältere Datei angeschaut. Da konnte ich sehen, dass am Anfang der Datei "SQLite format 3" drinsteht bei den neu erzeugten Dateien kann ich keinen Text erkennen.
Was läuft da schief? Habe eigentlich am D11 nichts geändert und nun geht es da auch nicht mehr.

[QuickAndDirty]

Ich führe diesen Code noch vor dem Backup und Reorg der Sqlite Datenbank, beim start der App aus. Damit geht es.
Es befreit die Alte datenbank von dem Passwort und neue Datenbanken haben ja eh keins.

Delphi-Quellcode:

Function TDBHealth.CheckAndRemoveEncryption:Boolean;
Begin
  Result := False;
  TSync.DB_CS.Acquire;
  try
    var SQLiteSec := TFDSQLiteSecurity.Create(nil);
    try
      SQLiteSec.Database :=  FDatabase;
      SQLiteSec.Password :=  '';
      SQLiteSec.DriverLink := FPhysSQLiteDriverLink;
      var EncryptionStatus := SQliteSec.CheckEncryption;
      if EncryptionStatus = '<unencrypted>' then
      Begin
        Result := true;
        TLog.d('TDBHealth.CheckAndRemoveEncryption: DB is unencrypted');
      End
      else if EncryptionStatus = '<encrypted>' then
      Begin
        TLog.d('TDBHealth.CheckAndRemoveEncryption: Encrypted DB or corrupt file');
        TLog.d('TDBHealth.CheckAndRemoveEncryption: Check old DB-password start');
        SQLiteSec.Database := FDatabase;
        SQLiteSec.Password := TDBConstants.DBPASSWORD_OLD;
        EncryptionStatus := SQLiteSec.CheckEncryption;
        TLog.d('TDBHealth.CheckAndRemoveEncryption: Check old DB-password finish');
        if (EncryptionStatus <> '<unencrypted>') and
           (EncryptionStatus <> '<encrypted>') and
           (EncryptionStatus <> '') then
        Begin
          TLog.d('TDBHealth.CheckAndRemoveEncryption: DB is encrypted with old DB-password');
          TLog.d('TDBHealth.CheckAndRemoveEncryption: Decrypt DB start');
          try
            SQLiteSec.Database := FDatabase;
            SQLiteSec.Password := TDBConstants.DBPASSWORD_OLD;
            SQLiteSec.RemovePassword;
            Result := True;
          Except
            On E:Exception do
            Begin
              fCheckDBhealthError := 'Beim entschlüsseln der Datenbank ist folgender Fehler aufgetretetn:' +
                                     sLinebreak + e.message + slinebreak+
                                     'Die Datenbank ist vermutlich defekt.'  ;
             TLog.d('TDBHealth.CheckAndRemoveEncryption: Decrypt DB Error:' + e.message);
            End;
          end;
          TLog.d('TDBHealth.CheckAndRemoveEncryption: Decrypt DB finish');
        End
        else
        Begin
          //Fehler;
          fCheckDBhealthError := 'Beim Login in die SQLite Datenbank ist folgender Fehler aufgetretetn:' +
                                  sLinebreak + EncryptionStatus + slinebreak+
                                 'Die Datenbank ist vermutlich defekt.' ;
          TLog.d('TDBHealth.CheckAndRemoveEncryption: Error checking for encryption with old password returned:'+EncryptionStatus);
        End;
      End
      else if EncryptionStatus = '' then
      Begin
        //Fehler;// Sollte man es dann nochmal mit passwort versuchen?
        fCheckDBhealthError := 'Unknown error checking for unencrypted access. The DB is probably corrupt.';
        TLog.d('TDBHealth.CheckAndRemoveEncryption: Unknown error checking for unencrypted access. The DB is probably corrupt.');
      End;
    finally
      SQLiteSec.Free;
    end;
  finally
    TSync.DB_CS.Release;
  end;
End;

[zeras]

Hallo Andreas,

danke für die Funktion. Das klappt erst einmal in einem Beispielprojekt und wäre eine Möglichkeit, dies in mein Projekt einzubauen. Bei neuen Projekten lösche ich einfach das Passwort. Dann geht es unter Windows.

[FreddyH]

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?

[zeras]

Soweit wie ich das verstanden habe, kann das neue Delphi keine kostenlose Verschlüsselung mehr. Daher habe ich beim Anlegen einer Datenbank das Passwort ='' gesetzt. Damit funktioniert es bei mir.
Bei einer Datenbank mit Passwort habe ich die Funktion weiter oben genutzt. Damit konnte ich dann auch weiterarbeiten.

[FreddyH]

1000 Dank an Euch.
Ihr habt mir Weihnachten gerettet.

[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?

[Mavarik]

Zitat:

Zitat von QuickAndDirty (Beitrag 1531383)

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.

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1531424)

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.

Naja, theoretisch hast Du Recht. Aber wie viele können eine iOS App debuggen und finden im Wust der Aufrufe genau die Stelle, an der das nicht im Klartext gespeicherte Passwort Entschlüsselt wird, oder können einen Hook an der Stelle einbauen wo das Passwort an die DB übergeben wird?

Mavarik

[Uwe Raabe]

Es ist auf jeden Fall um Größenordnungen sicherer als eine unverschlüsselte Datenbank.