SQL-Profiler

[M Merlin]

Hallo zusammen,
gibt es eine Möglichkeit, das man eine Anweisung vorweg eingibt, damit ich den Originaltext der zweiten Anweisung nicht im SQL-Profiler erkennen kann? Ähnlich, wenn ich mich einlogge – Passwort....

[Andreas Kosch]

Hallo,
wenn die SQLs nicht im Profiler zu sehen sein sollen, müssen diese in eine Stored Procedure in der Datenbank abgelegt werden. Der Profiler listet dann nur den Aufruf der SP auf. Wenn der Kunde auch die SQLs in der SP nicht sehen soll, kann diese über die Option <b>WITH ENCRYPTION</b> verschlüsselt werden:

CREATE PROCEDURE spMeineGeheimenSQLAnweisungen
WITH ENCRYPTION
AS
..

[M Merlin]

Ich muss doch noch mal nachfragen ob es eine Möglichkeit über .Net gibt....

Der Hintergrund:
Es sind User und Kennworte in einer Tabelle im SQL-Server abgelegt. Die Passworte sind zwar Binär abgelet, werden aber mit dem "Convert(varbinary,PassW)" gelesen bzw. geschrieben. Man kann also mit dem Profiler die übergebenen User und Passwörter sehen. Dies möcht ich verhindern....

Ich würde mir das also so vorstellen. Ein SQL-Kommando über .Net an den SQL Server schicken, sodass die nächste Anweisung irgenwie Verschlüsselt oder nicht in "KLarschrift" zu sehen ist. Oder ein SQL-Befehl, direkt vor dem Passwort, sodass dieses Wort nicht zu sehen ist....

Gibt es so eine Möglichkeit?
Aber wie gesagt, es soll aus einem Frotend über .Net abgesetzt werden...

[Andreas Kosch]

Hallo,

&gt;..mit dem Profiler die übergebenen User und Passwörter sehen.

Der Fehler besteht bereits darin, dass in der Datenbank das Passwort als Klartext gespeichert wird. Die Probleme verschwinden, wenn statt dessen der <b>Hashwert</b> des Passworts in der Datenbank gespeichert wird. Ein Hashwert ist eine Art "digitaler Fingerabdruck", benötigt <b>keinen</b> Schlüssel (somit entfällt das Problem, wie der Schlüssel sicher genug auf beiden Seiten versteckt werden kann) und ist <b>unumkehrbar</b> (d.h. im Gegensatz zum Verschlüsseln kann aus einem einmal berechneten Hashwert der Klartext <b>nicht</b> wiederhergestellt werden). Somit kann ein Dritter (der sich in den Besitz des Hashwertes des Passwortes bringt) damit nicht Sinnvolles anfangen. Um einen legitimen Benutzer zu erkennen, muss der Client das vom Benutzer eingetippte Passwort nochmals in den Hashwert umrechnen und dann über die SELECT-Abfrage der Datenbank den Hashwert mit dem in der Datenbank gespeicherten Wert vergleichen. Stimmen beide überein, hat der Benutzer das richtige Passwort eingetippt.
Im .NET Framework sind die Klassen aus dem Namespace <i>System.Security.Cryptography</i> auch für die Ermittlung des Hashwertes zuständig. Die Methode <b>ComputeHash</b> wird dort von verschiedenen Klassen angeboten (SHA1CryptoServiceProvider, MD5CryptoServiceProvider usw).

Wenn der SQL Server 2005 verwendet wird, kann dank SQLCLR (der .NET-Integration in den SQL Server) eine benutzerdefinierte Erweiterung in den SQL Server integriert werden. In diesem Fall könnte der Client die verschlüsselten Daten direkt eine eine in SQLCLR geschriebene Stored Procedure (die als Assembly-DLL in die Datenbank integriert wird) übergeben

[M Merlin]

Danke nochmals für deine sehr ausführlichen Erklärungen..