Vorbetrachtungen

Der SQL Server hat zwei verschiedene Authentifizierungsmodi: "Windows Authentifizierung" und "gemischter Modus" (Windows- und SQL Server-Authentifizierung). Welchen Modus Sie verwenden wollen, können Sie bei der Installation festlegen bzw. später im Betrieb jederzeit ändern.

Bei der Verwendung des gemischten Modus, können Sie sich entscheiden, welches der beiden Authentifizierungsverfahren Sie verwenden möchten. Leider entscheiden sich jedoch viele Kunden für die SQL Server-Authentifizierung. Dieses Verfahren verwendet die im SQL Server integrierte Benutzerverwaltung, d. h. alle SQL Server-Benutzer müssen im SQL Server angelegt und verwaltet werden.

Windows-Authentifizierung

Bei der Windows-Authentifizierung verwendet der SQL Server die Benutzerverwaltung von Windows (entweder lokal am Computer oder aus der Domäne). Die Passwortsicherheit bei der Windows-Authentifizierung ist im Domänenumfeld gewährleistet, da das Passwort durch Advanced Encryption Standard (AES) geschützt wird. Dieses Verfahren wird derzeit als so sicher eingestuft, z. B. ist es in den USA für staatliche Dokumente mit höchster Geheimhaltungsstufe zugelassen.
In Windows werden folgende Verfahren zum Schutz von Passwörtern eingesetzt:

¹Ein längeres Passwort als die Schlüssellänge bietet keinen zusätzlichen Schutz. (56bit=7 Zeichen, 128bit=16 Zeichen, 256bit=32 Zeichen).
²Dieses Verfahren ist auch in späteren Windows-Versionen verfügbar, jedoch standardmäßig deaktiviert.
³Nur bei Computern verfügbar, die mit einer Windows-Domäne verbunden sind.

Zusätzlich verfügt das Active Directory noch über weitere Sicherheitssysteme (wie z. B. das Sperren von Konten nach mehrmaliger Falscheingabe des Passworts). Durch die Verwendung entsprechend komplexer Passwortregeln, wird eine Reproduktion des Passwortes weiter erschwert bzw. mit heutigen Mitteln nahezu unmöglich gemacht. Das soll natürlich nicht heißen, dass ein solches Passwort nicht zu reproduzieren wäre – auch dafür gibt es Tools.

Meldet sich ein Benutzer auf einen Windows-Computer an, so werden seine Credentials (auch Domänen-Credential) lokal in drei verschiedenen Formen zwischengespeichert (als LM (LanMan) hash, NT hash und cached-credentials hash). Diese Credentials lassen sich auslesen und analysieren (siehe Artikel: Protecting Privileged Domain Accounts: LM Hashes — The Good, the Bad, and the Ugly). Dieses Verfahren wird auch als Pass-the-Hash Attacke bezeichnet und Microsoft hat dieser Angriffsmethode ein umfassendes White Paper mit entsprechenden Vorschlägen zur Vermeidung gewidmet.

Ein großer Vorteil der Windows-Authentifizierung im SQL Server besteht darin, dass die Anwender mit ihren eigenen Windows-Benutzerkonten arbeiten können und zwischen einer Client-Anwendung und dem Server kein Austausch der Credentials erforderlich ist.

Das Standardvorgehen für eine Anwendung ist Benutzergruppen (Security Group) im Active Directory anzulegen und diesen Gruppen entsprechende Berechtigungen für die jeweilige Aufgabe in der SQL Server-Datenbank zuzuweisen. Anschließend müssen nur noch die jeweiligen Benutzer in die Gruppe aufgenommen werden. Dadurch ist es nicht notwendig, jeden einzelnen Anwender Ihres Unternehmens im SQL Server zu berechtigen.

Betrachten wir dies am Beispiel der AdventureWorks-Datenbank. Gehen wir davon aus, dass es eine Gruppe von Benutzern gibt, die volles Administrationsrecht für die Datenbank benötigen (z. B. Anlegen und Löschen von Datenbankobjekten). Dafür legen Sie eine Gruppe “dbAdventureWorks_Admin” an. Eine zweite Gruppe soll das Recht bekommen Daten in der Datenbank zu ändern: Gruppe “dbAdventureWorks_Writer”. Eine dritte Gruppe soll nur Auswertungen in der Datenbank durchführen dürfen: Gruppe “dbAdventureWorks_Reader”. Danach können Sie den Gruppen die entsprechenden Benutzer aus dem Active Directory zuweisen, die die jeweiligen Aufgaben übernehmen sollen. Im nächsten Schritt müssen Sie die Benutzergruppen im SQL Server eintragen und können jeder Benutzergruppe die erforderlichen Berechtigungen zuweisen. In dem Beispiel würde das folgendermaßen aussehen:

   1: USE [master]

   2: GO

   3: CREATE LOGIN [W2K12R2dbAdventureWorks_Admin]  FROM WINDOWS WITH DEFAULT_DATABASE=[AdventureWorks]

   4: CREATE LOGIN [W2K12R2dbAdventureWorks_Writer] FROM WINDOWS WITH DEFAULT_DATABASE=[AdventureWorks]

   5: CREATE LOGIN [W2K12R2dbAdventureWorks_Reader] FROM WINDOWS WITH DEFAULT_DATABASE=[AdventureWorks]

   6: GO

   7: USE [AdventureWorks]

   8: GO

   9: CREATE USER [W2K12R2dbAdventureWorks_Admin] FOR LOGIN [W2K12R2dbAdventureWorks_Admin]

  10: CREATE USER [W2K12R2dbAdventureWorks_Writer] FOR LOGIN [W2K12R2dbAdventureWorks_Writer]

  11: CREATE USER [W2K12R2dbAdventureWorks_Reader] FOR LOGIN [W2K12R2dbAdventureWorks_Reader]

  12: GO

  13: ALTER ROLE [db_securityadmin] ADD MEMBER [W2K12R2dbAdventureWorks_Admin]

  14: ALTER ROLE [db_datawriter]    ADD MEMBER [W2K12R2dbAdventureWorks_Writer]

  15: ALTER ROLE [db_datareader]    ADD MEMBER [W2K12R2dbAdventureWorks_Reader]

  16: GO

SQL Server-Authentifizierung

Bei der Verwendung der SQL Server-Authentifizierung, werden Anmeldeinformationen in SQL Server erstellt, die nicht auf Windows-Benutzerkonten basieren. Sowohl der Benutzername als auch das Kennwort werden im SQL Server (master-Datenbank) gespeichert. Benutzer, die mit SQL Server-Authentifizierung eine Verbindung herstellen wollen, müssen ihre Anmeldeinformationen (Anmeldename und Kennwort) verwenden.

Die Gründe die ich bei Kunden höre, warum sie die SQL Server-Authentifizierung verwenden sind sehr vielseitig und einige möchte ich hier nennen und versuchen Gegenargumente anzubringen:

• “Der Benutzer und das Passwort sind in der Datenbankanwendung hinterlegt.”
  
  Anmerkung: Leider sind auch heute noch viele Anwendungen auf dem Markt, bei denen der Benutzername und das Passwort fest in der Anwendung hinterlegt sind. Das stellt in sich schon ein Sicherheitsrisiko dar, denn wenn Passwörter in der Anwendung im Klartext abgelegt werden, sind diese mit sehr einfachen Mitteln wieder auszulesen.
• “Wird von der SQL Server-Authentifizierung auf Windows-Authentifizierung umgestellt, so kann bei einem Domänenbenutzerkonten als Dienstkonto innerhalb der Anwendung das Passwort ablaufen, das Konto gesperrt sein usw.”
  
  Anmerkung: Wenn es sich um einen Serverdienst handelt, kann man Managed Service Accounts verwenden. Dieser Benutzertyp wurde mit Windows Server 2008 eingeführt und bietet neben den genannten Anforderungen noch viele weitere Vorteile. Des Weiteren gibt es auch für “normale” Domänenbenutzerkonten eine Reihe von Möglichkeiten dieses vor ablaufenden Passwörtern, Kontensperren u. ä. zu schützen.
• “SQL Server-Konten sind einfacher zu administrieren, da dies auch durch jemanden erfolgen kann, der keine Berechtigungen im Active Directory hat.”
  
  Anmerkung: Im Active Directory kann man Berechtigungen delegieren. So ist es z. B. möglich Benutzerkonten/Benutzergruppen in eine eigene Organizational Unit (OU) abzulegen und diese OU einem Benutzer zur Verwaltung zuzuweisen.
• “Windows-Administratoren sollen keinen Zugriff auf die Daten im SQL Server bekommen.”
  
  Anmerkung: Wenn Sie Ihren Windows-Administratoren nicht vertrauen, sollten Sie diese ersetzen. Ein Windows-Administrator hat immer Zugriff auf die Daten in Datenbanken auf SQL Server auch wenn die Daten in der Datenbank verschlüsselt mit Transparent Data Encryption (TDE) verschlüsselt sind. TDE hat jedoch nichts mit der Authentifizierungsmethode zu tun.

Bei SQL Server 2008 R2 und früheren Versionen liegt das Passwort bei Benutzerkonten mit SQL Server-Authentifizierung im Klartext im Arbeitsspeicher und lässt sich von dort mit einfachen Mitteln auslesen (http://midnightdba.itbookworm.com/VidPages/RecoverSQLPasswords/RecoverSQLPasswords.wmv).

Tatsächliche Gründe für die Verwendung der SQL Server-Authentifizierung sind nur dann gegeben, wenn eine Authentifizierung über die Windows Authentifizierung nicht bzw. nur eingeschränkt möglich ist, wie z. B.

• in Umgebungen mit gemischten Betriebssystemen (wie z. B. UNIX/LINUX, mobile Geräte mit iOS/Android) zu unterstützen, in denen nicht alle Benutzer von einer Windows-Domäne authentifiziert werden.
• bei Verbindungen von unbekannten oder nicht vertrauenswürdigen Domänen.
• in einem SQL Azure-Umfeld.
• bei der Verwendung von Contained Databases, die zwischen verschiedenen Domänen austauschbar sein sollen.

Die SQL Server-Authentifizierung verwendet Secure Hash Algorithmen (SHA) zum Schutz der Passwörter in der Benutzerverwaltung von SQL Server. Abhängig von der Version werden unterschiedliche Prüfsummenverfahren verwendet:

• SQL Server 2005, 2008, 2008 R2: SHA-1
• SQL Server 2012: SHA-2 (SHA-512)

SQL Server 2000 hat eine ganze Reihe von Möglichkeiten Passwörter auszuspähen (hier einige wenige: MS02-035, SQL Server Information Disclosure Non Vulnerability).

Eines der größten Sicherheitsprobleme bestand in den Versionen vor SQL Server 2005 beispielsweise darin, dass nach der Installation der “System Administrator” (sa) nicht mit einem Passwort geschützt war. Viele Kunden haben vergessen das Passwort zu setzen und so war es jedem Angreifer einfach möglich, eine SQL Server-Instanz zu übernehmen.

Aus den genannten Gründen sollten Kunden dringend auf eine neuere und somit sichere SQL Server-Version migrieren.

SQL Azure arbeitet ausschließlich mit SQL Server-Authentifizierung. Windows-Authentifizierung wird nicht unterstützt. Die Verbindung zu einer SQL Azure-Datenbank erfolgt per SSL. Jedoch muss die Verbindungszeichenfolge innerhalb der Anwendung das Passwort enthalten. Dies stellt wiederum ein Sicherheitsrisiko dar, denn Programme lassen sich analysieren und Passwörter daraus extrahieren. Eine mögliche Lösung ist der Schutz der Verbindungszeichenfolge durch ein Zertifikat.

Die Schlüsselgenerierung mit SHA basieren auf einem mathematischen Verfahren zur Berechnung eines kryptografischen Hashwertes. Besonderheiten eines kryptografischen Hashes auf Basis von SHA sind die Kollisionsfreiheit (es gibt keine zwei Zeichenketten mit demselben Hashwert) und die Unumkehrbarkeit (es gibt kein Verfahren, mit dem man aus einem Hashwert das Passwort bestimmen kann).

Ist man im Besitz des Hashwertes kann man aus diesem mit Hilfe der Brute-Force-Methode das Passwort wieder generieren, indem man aus einem beliebigen Zeichensatz alle möglichen Kombinationen für das Passwort generiert und daraus wird pro Passwort ein Hashwert berechnet. Diesen Hashwert vergleicht man dann mit dem Ausgangs-Hashwert. Die Brute-Force-Methode ist das aufwendigste Verfahren, da man alle möglichen Zeichenkombinationen ausprobiert. Andere Methoden wie z. B.

• Dictionary Methode: Verwendung einer Liste von möglichen Worten
• Rainbow Table-Methode: Verwenden von bereits vorberechneten Hashwerten

arbeiten mit vorgegebenen Listen von Passwörtern oder Hashwerten zur Beschleunigung der Berechnung. Die verschiedenen Methoden sind auch miteinander kombinierbar.

Allgemein gilt jedoch: Je länger die Zeichenkette für das Passwort ist, desto aufwendiger ist es mit der Brute-Force-Methode dieses zu reproduzieren. Somit ist es nur eine Frage der Rechenleistung und der Zeit, bis ein Passwort reproduziert werden kann. Die Empfehlung von Microsoft "Sie sollten möglichst lange und komplexe Kennwörter verwenden." hat somit seine Berechtigung und Sie sollten sich deshalb auch an die Empfehlungen von Microsoft bei der Generierung von Passwörtern für den SQL Server halten. Eine einfache Möglichkeit dies sicherzustellen, ist sind die Passwort-Policies zu aktivieren und das Passwort regelmäßig zu ändern.

Passwort-Hashwerte

Wenn ein Benutzer im SQL Server sein Passwort ändert, wird das Passwort nicht im Klartext im SQL Server gespeichert, sondern es wird nur ein berechneter Hashwert des Passworts abgelegt. Das Passwort existiert nicht mehr im Klartext. Wird ein Benutzer bei der Anmeldung am SQL Server aufgefordert, sein Passwort einzugeben, so wird dieses im Hintergrund automatisch in einen Hashwert umgewandelt und mit dem im System hinterlegte Hashwert verglichen. Stimmen beide Hashwerte überein, so geht das System davon aus, dass es sich um das richtige Passwort handelt und melden den Benutzer am System an.

Zur Vorbereitung dieses Tests habe ich neun Benutzer mit verschiedenen Passwörtern auf einem Testsystem angelegt. Da ich Passwörter mit verschiedenen Längen und Komplexität anlegen wollte, habe ich für die Benutzer die Passwort-Policy deaktiviert. Zum Erzeugen der SQL Server-Benutzerkonten habe ich folgendes TSQL-Statement verwendet:

   1: CREATE LOGIN [U1] WITH PASSWORD=N'x', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF,CHECK_POLICY=OFF 

Um ein realistisches Szenario zu verwenden, kann jedes einzelne Zeichen des Passworts aus 95 verschiedenen Zeichen bestehen:

• Zahlen: 0123456789
• Buchstaben: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
• Sonderzeichen: !"#$%&'()*+,-/:;<=>?@[]^_`{|}~

Rein mathematisch ergeben sich nun folgende mögliche Zeichenkombinationen:

Zum Auslesen des Hashwertes für das Passwort stellt Ihnen SQL Server die Sicht sys.sql_logins zur Verfügung. Zum Anzeigen der Passwort-Hashwerte sind Control Server-Berechtigungen im SQL Server erforderlich. Sollten Sie nicht über die entsprechenden Berechtigungen verfügen, so wird der Passwort-Hash als NULL angezeigt.

   1: SELECT [NAME], [PasswordHash]

   2: FROM [SYS].[SQL_LOGINS]

Das Ergebnis der Abfrage sieht folgendermaßen aus:

Eine Methode zum Überprüfen eines Passworts mit einem Hashwert stellt die Funktion PWDCOMPARE zur Verfügung.

   1: SELECT name FROM sys.sql_logins 

   2: WHERE PWDCOMPARE('x', password_hash) = 1 ;

Wenn Sie jede mögliche Passwortkombination auf diesem Weg überprüfen wollen, ist dies natürlich sehr aufwendig und belastet den SQL Server.

Einfacher ist es auf einem beliebigen Computer die Hashwerte zu den Passwörtern abzulegen und diese mit einem Programm in die Originalpasswörter zurück zu verwandeln.

Passwortanalyse

Zur Berechnung der Hashwerte zur Reproduktion eines Passworts habe ich das Tool HashCat verwendet. Hierzu gibt es mehrere verschiedene Versionen/Editionen:

Das Handbuch zu dem Tool findet Sie unter http://hashcat.net/files/hashcat_user_manual.pdf.

Wer mit dem Kommandozeilen-Tool nicht zurechtkommt, für den steht auch eine Oberfläche zur Verfügung. Diese habe ich jedoch in dem Test nicht verwendet.

Die Tests habe ich auf meinem Notebook mit folgender Konfiguration durchgeführt:

• Processor: Intel Core i7-2760QM (2.40GHz, 4 Kerne)
• RAM: 32GB
• Graphics: NVIDIA Quadro 3000M 2GB (240 CUDA-Kerne) an PCIe X16 Gen. 2
• Betriebssystem: Windows 8
• Grafikkartentreiber: 320.86

Ich habe alle drei Tools ausprobiert und festgestellt, dass auf meinem System das “hashcat plus” die besten Ergebnisse geliefert hat. Ich habe das Programm anschließend mit verschiedenen Parametern getestet und bin in der optimalen Variante zu folgenden Ergebnissen gekommen:

Aufgrund der voraussichtlichen Dauer für die Generierung von Passwörtern mit einer Länge größer als 6 Zeichen habe ich den Test an dieser Stelle beendet.

Bei den geschätzten Zeiten für die Berechnung der Hash-Werte durch die Anwendung kann man auch hier wieder ein mathematisches Modell zugrunde legen. Meine Grafikkarte ist bei der Verwendung von 160 CUDA-Kernen in der Lage 22,5 Millionen Hashwerte pro Sekunde zu berechnen (140.000 Hashwerte pro Kern). Wenn Sie nun wissen, wie viele mögliche Kombinationen der Zeichen innerhalb des Passworts möglich sind (siehe erste Tabelle in diesem Blog), können Sie berechnen, wie lange es maximal dauert, bis ein Passwort einer bestimmten Länge analysiert ist. Wie Sie an meinem Test sehen können, wird das Passwort meistens bereits vor der geschätzten Zeit ausgegeben.

Neben dem Hashcat-Tool gibt es noch eine Reihe weiterer Tools. Diese habe ich jedoch nicht in diesem Test betrachtet.

Fazit

Persönliche Anmerkung: Warum Microsoft sich entschlossen hat im SQL Server 2012 ein Sicherheitsmechanismus aus dem Jahr 2002 zu integrieren, kann ich nicht nachvollziehen. Zwischenzeitlich gibt es bessere Verfahren z. B. bcrypt, bei denen der Berechnungsaufwand des Hashwertes wesentlich höher ist.