SQL Server 2005: Wie sicher ist die SQL Server-Authentifizierung?

So sicher wie Sie es machen wollen ...

Sie können SSL ziemlich einfach konfigurieren, und wenn Sie kein vertrauenswürdiges Zertifikat haben, kann SQL Server, wenn Sie die Verschlüsselung erzwingen, ein eigenes selbstsigniertes Zertifikat für Ihre Verwendung erstellen / ausgeben ... aus dieser Zusammenfassung

  

Anmeldedaten (im Anmeldepaket), die   werden übertragen, wenn ein Client   Anwendung verbindet sich zu SQL Server sind   immer verschlüsselt. SQL Server wird verwenden   ein Zertifikat von einem vertrauenswürdigen   Zertifizierungsstelle, falls verfügbar.   Wenn ein vertrauenswürdiges Zertifikat nicht vorhanden ist   installiert, generiert SQL Server ein   selbstsigniertes Zertifikat, wenn die   Instanz wird gestartet, und verwenden Sie die   selbstsigniertes Zertifikat zum Verschlüsseln des   Referenzen. Dies ist selbst signiert   Zertifikat hilft die Sicherheit zu erhöhen   aber es bietet keinen Schutz   gegen Identität Spoofing durch die   Server. Wenn das selbstsignierte Zertifikat   verwendet wird, und der Wert der   ForceEncryption-Option ist auf Ja festgelegt   Alle Daten werden über ein Netzwerk übertragen   zwischen SQL Server und dem Client   Anwendung wird verschlüsselt mit   das selbstsignierte Zertifikat

Die Anmeldeinformationen werden im Klartext gesendet.

Sie können wahrscheinlich eine Reihe von Quellen dafür finden, aber hier ist einer :

"Sichern Sie den Kanal zwischen dem Webserver und dem Datenbankserver, da die Anmeldeinformationen unverschlüsselt übergeben werden. Verwenden Sie beispielsweise SSL oder IPSec."

Hier finden Sie einen Link zu einigen bewährten Sicherheitsmethoden für SQL 2005. Dieses Dokument gibt teilweise an:

  

Im Windows-Authentifizierungsmodus   bestimmter Windows-Benutzer und -Gruppe   Konten werden vertraut, um sich bei SQL anzumelden   Server. Windows-Anmeldeinformationen werden verwendet   in dem Prozess; das heißt, entweder NTLM   oder Kerberos-Anmeldeinformationen. Windows   Konten verwenden eine Reihe von verschlüsselten   Nachrichten zur Authentifizierung bei SQL   Server; Passwörter werden nicht übergeben   das Netzwerk während der Authentifizierung   verarbeiten. Wenn SQL-Logins verwendet werden, werden SQL-Login-Passwörter zur Authentifizierung über das Netzwerk weitergegeben. Dadurch sind SQL-Logins weniger sicher als Windows-Logins.

Diesen Thread zu lesen, hat mich noch mehr verwirrt, als ich war! Wie auch immer, ich habe einige Tests mit Wireshark gemacht, mit oder ohne verschlüsselte Verbindung. Ich konnte mein Passwort nie sehen (und meinen Benutzernamen denke ich). Was ohne Verschlüsselung sehr sichtbar war, sind die eigentlichen Abfragen.

Vielleicht ist es der Mangel an Wissen mit Wireshark, um die Anmeldedaten abzurufen, aber da ich alles andere sehen konnte, bin ich mir ziemlich sicher, dass ich an der richtigen Stelle gesucht habe und das Passwort IMMER verborgen war.

Abgesehen davon, dass Passwörter im Klartext gesendet werden, ist es auch möglich, den Hash des Passworts zu ersetzen.

Ob die Anmeldedaten verschlüsselt sind oder nicht, hängt von der Verschlüsselungsfähigkeit / Konfiguration des Clients und Servers ab.

Auf Protokollebene sind völlig unverschlüsselte SQL-Logins zulässig , obwohl meine Vermutung darauf zurückzuführen ist, dass diese selten sind, weil ich die modernste Datenbank vermute Treiber unterstützen sie nicht.

Details

Clients kommunizieren mit Microsoft SQL Server mithilfe des Tabellendatenstromprotokolls (TDS) .

Kurz nachdem ein Client eine TDS-Verbindung zum Server öffnet, informiert er den Server über seine Verschlüsselungsfunktion. Der Server vergleicht diese Ankündigung mit seiner eigenen Konfiguration / Fähigkeit, um den Verschlüsselungsstatus für die Verbindung zu bestimmen.

Kurz gesagt, der Verschlüsselungsstatus wird wie folgt festgelegt:

• Wenn der Client oder Server ankündigt, dass er die Verschlüsselung nicht unterstützt und die andere Seite keine Verschlüsselung benötigt, wird die gesamte Verbindung - einschließlich der Anmeldung - unverschlüsselt .
• Wenn sowohl der Client als auch der Server ankündigen, dass sie die Verschlüsselung unterstützen, sie aber nicht benötigen, wird nur das erste TDS-Paket der Login-Anfrage verschlüsselt . Der Rest der Verbindung, einschließlich zusätzlicher Anmeldeanforderungspakete, wird unverschlüsselt. Ein ordnungsgemäßer Datenbanktreiber stellt sicher, dass das SQL-Authentifizierungskennwort im ersten Anmeldepaket abgelegt wird, dies ist jedoch nicht auf Protokollebene erforderlich.
• Wenn entweder ein Client oder ein Server ankündigt, dass sie eine Verschlüsselung benötigen, wird die gesamte Verbindung verschlüsselt (mit Ausnahme einer kleinen Menge vorläufiger Daten), sofern die andere Seite die Verschlüsselung nicht unterstützt. In diesem Fall wird die Verbindung beendet.

Die einzige Möglichkeit sicherzustellen, dass Login-Anforderungen immer verschlüsselt sind, ist die Einstellung der Option "Verschlüsselung erforderlich" auf einem Client oder Server. Es gibt keine Möglichkeit, vollständig unverschlüsselte Verbindungen zu verbieten, ohne dass eine vollständige Verschlüsselung erforderlich ist.

Unabhängig davon, ob die Anmeldung oder Verbindung verschlüsselt ist oder nicht, das SQL-Authentifizierungskennwort ist immer verschleiert, aber die Verschlüsselung ist leicht umkehrbar.

Weiterführende Literatur:

• Technische Details zu Verbindungsverschlüsselungszuständen - MS-TDS 2.2.6.5 PRELOGIN (unter Überschrift Verschlüsselung )
• Passwortverschlüsselungsformel - MS-TDS 2.2.6.4 LOGIN7 (siehe letzten Absatz)
• Etwas detailliertere Artikel zum Thema - SQL Passwörter: verschlüsselt zwischen Client und Server? (Disclaimer: das ist ein Beitrag in meinem Blog)