Nullterminierten String aus MSSQL nvarchar auslesen

[norwegen60]

Hallo zusammen,

ich möchte verschlüsselte Passwörter in MsSQL in einem nvarchar-Feld abspeichern. Die Verschlüsselung (RC4) kann auch das Zeichen #0 erzeugen. Es ist kein Problem, wenn ich den Wert z.B. per

Code:

qu.fieldbyname('pwd').AsString := sPwd;

in der DB abspeichere. Wenn ich per SQL Server Management Studio den Wert ansehe, ist er komplett abgespeichert.

Sobald ich ihn aber per

Code:

sPwd:=qu.fieldbyname('pwd').AsString;

auslese, ist alles nach #0 abgeschnitten. Ich weiß, dass es geht, wenn ich in MsSQL text statt nvarchar nehme, aber geht es nicht auch mit nvarchar? Ich verwende TAdoQuery

Vielen Dank
Gerd

[sx2008]

Du solltest die Passwörter mit Base16 kodieren.
Base16 ist nichts anderes als eine Hexumwandlung.
siehe z.B. CodeLibrary hier.
Base64 ist platzsparender, aber da Passwörter so kurz sind spielt das keine Rolle.

PS:
Bei Delphi2010 muss man achtgeben, dass die Hexumwandlung auch wirklich
funktionert - evtl. muss Datentyp string durch AnsiString ersetzt werden.

[Bernhard Geyer]

Zitat:

Zitat von norwegen60 (Beitrag 1052281)

...
Die Verschlüsselung (RC4) kann auch das Zeichen #0 erzeugen. ... Wenn ich per SQL Server Management Studio den Wert ansehe, ist er komplett abgespeichert.

Zufall das dies Klappt. Da auch der MS SQL Server viel C/C++-Code beinhaltet könnte sich das mit jedem Hotfix ändern.

Ein #0 ist nunmal für ein Zeichnkette der Kennzeichner für ein Ende der Zeichenkette (Jedenfalls wenns C/C++ betrifft). Und mir ist keine String-Datentyp bekannt in der das #0 einen gültigen Zeichenwert definiert.

Zitat:

Zitat von sx2008 (Beitrag 1052282)

Bei Delphi2010 muss man achtgeben, dass die Hexumwandlung auch wirklich
funktionert - evtl. muss Datentyp string durch AnsiString ersetzt werden.

Da sollte man dann die Funktion anpassen. Auf DB-Seite wird mit nvarchar schon Wide/UTF16-String verwendet. D2010 hat auch als Standard-Stringtyp einen Wide/UTF16-String. Deshalb soltle die Hexwandlung ebenfalls damit zurecht kommen!

[norwegen60]

Hallo zusammen,

danke für die Feedbacks.

Zitat:

Ein #0 ist nunmal für ein Zeichnkette der Kennzeichner für ein Ende der Zeichenkette (Jedenfalls wenns C/C++ betrifft). Und mir ist keine String-Datentyp bekannt in der das #0 einen gültigen Zeichenwert definiert.

Ich weiß. Von daher hat es mich etwas gewundert, dass ein String den Wert überhaupt richtig an die DB übergeben kann.

Zufall scheint es nicht zu sein, denn ich habe es mehrmals ausprobiert und das Schreiben in die DB (auch unterschiedlicher Werte) hat immer geklappt. Nur beim Lesen wurden sie konsequent abgeschnitten. Als ich es dann mit text in der DB probiert habe, hat auch das sicher geklappt. Dafür aber andere Dinge nicht, die ich sonst noch benötige

Falls keine anderen Lösungen kommen probiere ich es mal mit Base16

Grüße
Gerd

[Bernhard Geyer]

Zitat:

Zitat von norwegen60 (Beitrag 1052422)

Zufall scheint es nicht zu sein, denn ich habe es mehrmals ausprobiert ...

Und du hast jedesmal unterschiedliche MSSQL-Versionen mit unterschliedlichen Patch-Leveln probiert (Da auch der MS SQL Server viel C/C++-Code beinhaltet könnte sich das mit jedem Hotfix ändern.)?

[norwegen60]

Hallo Bernhard,

da hast du natürlich recht. Das habe ich nicht. Aber ich habe eine andere Idee. Da nur bei ca jeder 5. Generierung ein String mit #0 erzeugt wird, rufe ich die Funktion so lange auf, bis im String kein #0 mehr enthalten ist. Ich verwende den Code aus http://www.delphipraxis.net/26732-rc...uesselung.html wo noch eine zusätzlicher Zufallsstring hinzuaddiert wird wodurch sich der verschlüsselte String immer wieder ändert. Einzige Unsicherheit ist, dass es Passwort/Schlüsselkombinationen gibt, wo #0 öfter vorkommt.

Gerd