DevTrain Startseite SharePoint Camp ? In 5 Tagen zum SharePoint Profi!  
  
  
SUCHEN:  
ARTIKEL ONLINE: 525   

Kategorien
.NET
Datenbanken
Web
XML

Allgemein
Camp
Foren
Events
Persönliche Einstellungen
Registrieren
Prämien Shop
Kontakt
Impressum
Über DevTrain

Autoren


   Autor: Hannes Preishuber Artikel Drucken
        
Sichere Passwörter mit MD5

Die Idealvorstellung aller EDV User, Manager und Linuisten ist das sichere Internet. So wird argumentiert, dass der IIS sehr unsicher ist. Realisten werden wissen, das Sicherheit ein weit greifender und auslegbarer Begriff ist.
Betrachten wir den einfachen Vorgang der Benutzeranmeldung. Diese soll ja zunächst mal Sicherheit vorgaukeln. Der User ruft eine Website auf und wird auf eine Login seite umgeleitet, wenn er nicht authentifiziert ist. Der Benutzername und Passwort werden im Webbrowser erfasst und an den Webserver per HTTP Post übermittelt. Sicher? Sicher ist nur, dass man dann auch die Geheimzahl der Bankkarte auf die Rückseite schreiben kann.
Die Benutzerdaten werden im Klartext übermittelt und können an jedem Router mitgelesen werden. Abhilfe schafft hier z.B. das Protokoll zu wechseln und eine verschlüsselte Verbindung per HTTPS aufzubauen. Diese endet am Webserver, wenn die ASP.NET Seite laut OSI Modell als Applikation oberhalb des HTTPS Protokolls die Daten wieder entgegen nimmt.
Die Daten sind dann im Speicher des Webservers für kurze Zeit im Klartext verfügbar und theoretisch z.B. per Trojaner greifbar. Als nächstes wird Ihre mittlere Schicht direkt mit der Datenbank kommunizieren um zu prüfen ob die Credentials identisch sind. Dazu holt man sich per Select Statement die Benutzerdaten aus der Datenbank, die dort unverschlüsselt liegen und vergleicht sie mit dem eingegeben. Wenn Sie nun den SQL Profiler verwenden können, können Sie wunderbar sämtliche Kommunikation mit dem Webserver mitschneiden. Dabei ist zu beachten, dass auch der Connection String samt User und Password für den Zugriff auf die DB mit gesendet wird. Auch andere Tools wie der Netzwerk Monitor erlauben dem einfachen User eine umfassende Analyse der abgefragten Passwörter. Der SQL Server 2000 bietet Methoden auch diesen Datenverkehr zu verschlüsseln. Dazu gehören das deaktivieren des Named Pipes Protokolls und das erzwingen der Protokol verschlüsselung. 
Beim übermitteln des Connection Strings, kann auf Benutzernamen und Passwort verzichtet werden wenn stattdessen die integrierte Windows Authentifizierung verwendet wird.
"Data Source=SqlServer;Integrated Security=SSPI;Initial Catalog=pubs"
 
Darüber hinaus lässt sicher gesamte Netzverkehr mit IPSEc verschlüsseln.
Noch sicherer ist nur das Passwort gar nicht in der Datenbank abzulegen. Geht nicht? Geht nicht!  Dann wenigstens stark verschlüsselt. Bevor nun jeder an die Entwicklung eigener Algorithmen geht, lohnt ein Blick in die Klassenbibliothek des .NET Frameworks.
Der Namespace heißt Security für den Kryptografieprovider und Text für Encondings.
Imports System.Security.Cryptography
Imports System.Text
 
Es stehen einige Algorithmen wie SHA,DES oder MDA zur Verfügung. MD5 ist der neueste und sicherste Algorithmus der MD Familie und verwendet einen 128 Bit Hash Wert als Schlüssel. Hashfunktionen ordnen binäre Zeichenfolgen beliebiger Länge kleinen binären Zeichenfolgen fester Länge zu. Kryptographische Hashfunktionen sind dadurch gekennzeichnet, dass es rechnerisch unmöglich ist, zwei verschiedene Eingabewerte zu ermitteln, die denselben Hashwert ergeben. Daher sind die Hashs zweier Datenmengen identisch, wenn auch die entsprechenden Daten identisch sind. Kleine Änderungen an den Daten führen zu beträchtlichen unvorhersehbaren Änderungen des Hash. Die noch sicherere aber langsamere Methode wäre SHA1.
In der Forms Authentication von ASP.NET finden sowohl SHA1 als auch MD5 ihre Anwendung.
Die Cryptoserviceprovider sind nur eine Kapselung der Crypto API von Windows. In dieser könnte dank Standardisierung auch ein eventueller Angriffpunkt stecken. Lange Zeit ging das Gerücht um, das Microsoft dort Generalschlüssel hinterlegt hat um dem CIA Zugriff zu ermöglichen. Akte X lässt grüßen, wobei die Vermutung nicht von der Hand zu weisen ist. Alle Applikationen nutzen dieselbe API.
Es gestaltet sich recht einfach nach instanzieren des MD5 Cryptographie Providers ein Bytearray zu codieren. Dazu muss nur mehr der TextString über die UTF Encoder Funktion umgewandelt werden.
Um das Ergebnis zu visualisieren muss das erhaltene Bytearray wieder in irgendwas Lesbares zurück konvertiert werden.
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim bytes As Byte()
        Dim encoder As New UTF8Encoding()
        Dim md5Hasher As New MD5CryptoServiceProvider()
        bytes = md5Hasher.ComputeHash(encoder.GetBytes(TextBox1.Text))
        'Bytes in DB Feldtyp Binary
        Dim decoder As New ASCIIEncoding()
        Label1.Text = decoder.GetChars(bytes)
    End Sub

Man kann hier im Praxistest die Eigenheit von MD5 sehr gut erkennen, dass zwei sehr ähnliche Werte komplett verschieden in Form und Länge verschlüsselt werden.
In der Praxis wird man den verschlüsselten Wert in die Datenbank zu dem Benutzernamen speichern. Dazu verwendet man am besten als Feldtyp binary und legt das Bytearray direkt ab. Für die spätere Authentifizierung kann der Wert dann pur gelesen werden und mit dem eingegeben und verschlüsselten Passwort verglichen wird.
 
Überwachung
Trotz all dieses Aufwands ist die Sicherheit trügerisch. Der kleinste Fehler im Code oder ein offenes Passwort führen das ganze System adabsurdum. Deshalb ist eine wirkungsvolle Überwachung unumgänglich. In der Praxis sollten z.B. Passwort Fehleingaben Protokolliert werden. Auch Zugriffe zu besonders sensiblen Daten müssen aufgezeichnet und Änderungen komplett geloggt werden.
 
Nachteile
Sicherheit kostet Geld. Es lässt sich beinahe beliebig viel Zeit in Administration und Entwicklung stecken um die System abzusichern. Ein nicht zu unterschätzender Fakt ist, dass zunehmende Absicherung auch die Performance drastisch beeinflussen kann. Auch der Komfort für Entwickler und Benutzer kann darunter leiden. So kann in unserem Fall, das Passwort nicht einfach per eMail versendet werden. Wenn der Benutzer es vergessen hat, weis es niemand mehr.
Systeme sollen die Sicherheitsstufe haben die auch angebracht ist. Dazu gehört eine vernünftige Risiko Abschätzung. Dinge die Riskant und wahrscheinlich sind müssen unbedingt gesichert werden. Dazu gehört z.B. schon das abschließen des Server Schranks. Ganz billig und schnell.
 

 

DevTrain Camp - Schneller zum .NET 3.5 Developer
 
Verwandte Artikel      Verlinkte Dokumente
    Keine verknüpften Dokumente
    Keine Links vorhanden

  Erfasst am: 07.11.2002
  Gültig bis: 07.12.2002
39 Ratings
Bewertung: 88,7%
schlecht    sehr gut  

 
© Copyright 2007 ppedv AG