Passwörter rich­tig spei­chern – Vor­wort

In fast jedem IT Projekt kommt unweigerlich irgendwann der Punkt, an dem einige wichtige Entscheidung anstehen: Wie und wo verwalten wir unsere Benutzer? Wie und wo speichern wir die Daten, so dass sie möglichst sicher sind? Und was passiert, wenn unsere Daten verloren gehen? Einigen dieser Fragen wollen wir in diesem Artikel ein wenig auf den Grund gehen.

Zunächst stehen wir vor der grundsätzlichen Entscheidung, wie wir die Benutzerkonten in unserem Projekt nutzen wollen: Verwenden wir Federated Identity Management (FIdM) und hängen unsere Anwendung an ein externes System oder managen wir unsere Benutzer innerhalb unserer Anwendung selbst?

Bekannte FIdM Dienstanbieter sind u.a. Facebook, Twitter, Microsoft Account (ehemals Windows Live ID) und Amazon. Falls wir in unserer eigenen IT-Landschaft ein Active Directory (AD) betreiben, dann können wir dieses ebenfalls als FIM-Dienst (ADS) in unserer Anwendung nutzen.

Wenn wir unsere Anwendung nicht an das heimische AD hängen wollen bzw. können und übrige FIdM-Dienste für uns nicht in Frage kommen, bleibt nur der Weg die Benutzerkontenverwaltung selber zu implementieren.

Vertiefende Gedanken zum Thema: Federated Identity Management vs. Eigene Benutzerkontenverwaltung.

Abgrenzung

Für eine Benutzerkontenverwaltung gibt es zahllose Beispiele im Internet zu finden.

Diese Artikel-Reihe fokussiert sich auf einen – wenn nicht den wichtigsten – Aspekt einer Benutzerkontenverwaltung: „Sicheres“ Vorhalten von Passwörtern in einer Datenbank.

Die Reihe geht nicht auf Angriffsvektoren, wie Man-In-The-Middle-Attacken oder SSL-Forgery-Attacken ein, wo Daten beim Weg vom Browser zum Server abgegriffen werden. Es geht hier einzig um die Vorhaltung der Daten in einer Datenbank und was passiert, wenn Daten verloren gehen.

Diese Reihe erhebt keinen Anspruch auf Vollständigkeit.

Zielgruppe

Mit dieser Artikel-Reihe richten wir uns nicht an Kryptographie-Experten und/oder Mathematiker.

Vielmehr geht es um einen Überblick über das Thema und die Reihe richtet sich an interessierte aber IT-affine Personen, die wenige oder keine Vorkenntnisse in dem Bereich mitbringen.

Viele Aspekte werden vereinfacht und zusammengefasst/ gestrafft dargestellt. Es geht eher um die Breite, als um die Tiefe.

Ein Artikel ist definitiv nicht genug Raum, um alle Facetten in der angebrachten Tiefe ausreichend zu besprechen.

Lesart

Im Folgenden werden unterschiedliche Ansätze beschrieben, Passwörter in der Datenbank abzulegen und diese auf unterschiedliche Arten zu schützen.

Für jeden Ansatz wird die Methodik erläutert, deren Vor- und Nachteile abgewogen und ein Fazit gezogen. Abgerundet wird jeder Ansatz mit einem Beispiel/ Codeauszug.

Eine vollständige Anwendung mit allen Beispielen kann bei GitHub heruntergeladen werden.

Voraussetzungen für die Beispiele

  • C#-Kenntnisse
  • Microsoft.NET Framework 4
  • Mindestens SQL Server 2005
  • CryptSharp.net – Library
  • SHA3 – Library
Schnelleinstieg

Der Übersichtlichkeit halber ist der Artikel in mehrere Teile gegliedert:
Intro: Vorwort
Teil 1: Klartext
Teil 2: MD5 und SHA
Teil 3: Salt & Pepper
Teil 4: BCrypt
Teil 5: BCrypt & Pepper und Gesamt-Fazit

Downloads sind in diesem GitHub-Repository zu finden:
https://github.com/christianaschoff

Christian Aschoff

Christian Aschoff

Senior IT-Berater bei BROCKHAUS AG
Christian Aschoff ist bei der BROCKHAUS AG in der Individualentwicklung mit Microsoft-Technologien tätig. Darüber hinaus beschäftigt er sich mit übergreifenden Themen wie IT-Security, iOS-Entwicklung mit Mono und Unity 3D. Als jemand, dem Sicherheit am Herzen liegt, schreibt er für das blogHAUS hauptsächlich über Themen aus dem Bereich Security.
Christian Aschoff
<< Vorheriger Beitrag
Nächster Beitrag >>

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.