Sicherheit / Security

Der Artikel soll dem Leser das Sicherheitsbewusstsein in Umgang mit Passwörtern und deren Nutzung in verschiedenen Anwendungsbereichen stärken. Die nachfolgenden Erläuterungen und Informationen liefern einige Beispiele und Anregen. Dies soll nicht die professionelle Hilfe von Sicherheitsexperten ersetzen. Der Autor hat versucht seine Kenntnisse weiter zu vermitteln und übernimmt daher keine Gewähr für den nachfolgenden Inhalt.

Vermeidung / Blockierung von Brute-Force Attacken (Blocking Brute-Force Attacks)

Ein Angreifer kann über Bruce Force Angriffen versuchen für einen Benutzernamen das Passwort auszuspionieren.

 

Was ist überhaupt Brute-Force?

Der Brute-Force-Algorithmus versucht systematisch alle möglichen Schlüssel / Kombinationen zu überprüfen, bis die richtige Kombination gefunden ist. Damit wird letztendlich versucht das (geheime) Passwort bzw. den Hash zu ermitteln.

 

Passwortlänge / Kombinationen und Dauer

Abhängig von der Passwortlänge und dessen Komplexität gibt es auch entsprechende Anzahl an möglichen Kombinationen.

Die Anzahl der Kombinationen errechnet sich gemäß folgender Formel.

Kombinationen = [Zu prüfende Zeichen] ^ [Zeichenlänge des Passwortes]

 

Ein paar persönliche einfache Versuchsreihen zur Ermittlung der Dauer von verschiedenen Passwortlängen.

5 Zeichen für [Zeichenlänge des Passwortes] = ca. 33 s

6 Zeichen für [Zeichenlänge des Passwortes] = ca. 40 min

Siehe Links.

 

Um die Geschwindigkeit von Angriffen zu erhöhen, werden oft auch Wörterbücher (dictionary words) und modifizierte Wörterbücher eingesetzt. Der Grund liegt darin, dass viele Benutzer anstatt von komplexen „Zufallspasswörter“ bekannte Begriffe als Passwort verwenden.

 

Einige Algorithmen fangen bei den zu prüfenden Zeichen mit einem „a“ an. Bei einem Versuch mit einem Passwort welches mit einem „a“ beginnt, war die Dauer für das ermitteln des Passwortes geringer.

 

Woran erkenne ich Angriffe?

  • Anmeldeversuche mit folgendem Aufruf. http://user:password@www.beispiel.de
  • Erhöhte Logins von der selben IP-Adresse
  • Logins mit verschiedenen Benutzernamen von der selben IP-Adresse
  • Fehlerhafte Logins von alphanumerischer Änderung des Benutzernamens oder des Passwortes
  • Erhöhte Last und Bandbreite bei Login Versuchen

 

Für Bruce-Force Angriffe werden oft verfügbare Tools eingesetzt. Das Erkennen von solchen Angriffen ist oft leicht möglich, das Verhindern ist jedoch entsprechend komplex.

 

Mögliche Lösungsansätze zur Vermeidung von Angriffen.

 

Ansatz Beschreibung
Sperrung IP-Adresse Nach einem Angriffsversuch wird die IP-Adresse des Angreifers gesperrt.

  • Angriffe kommen oft von mehreren IP-Adressen.
  • Bei Proxy Servern werden dann auch alle anderen Zugriffe gesperrt
Sperrung Account Nach einer festgelegten Anzahl an Zugriffsversuchen wird der Account gesperrt.

  • Ein Angreifer kann über Denial of service (DoS) Angriffe die Accounts mehrere Benutzer sperren
  • Nach erneuter Freischaltung (automatisiert oder durch Administrator) wird durch erneute Angriffe die Sperrung sofort wieder erneut durchgeführt.
  • Admin Accounts sind oft von dieser Policy ausgenommen und sind somit das primäre Ziel eines Angriffs.
Pausen zwischen Fehlversuchen Nach einer Fehleingabe sollte entweder per (sicherer) Zufallszahl, oder per logarithmischer Erhöhung die Pausenzeit erhöht werden.
Hinweismeldung bei fehlerhafter Anmeldung Bei Fehlversuchen sollte immer eine andere Meldung nach „außen“ gegeben werden. Damit soll den Angriffstools das Verhalten bei fehlerhafter Anmeldung erschwert werden.

Eventuell können auch Grafiken mit dynamischen Meldungstext und dyn. Positionierung zum Einsatz kommen.

Wichtig: Die Meldung darf keine Details (wie bspw. „Benutzernamen nicht bekannt“) liefern.

è Das Verhalten der Prüfroutine darf nicht vorhersehbar sein!

Zusätzliche Möglichkeiten der Passwortabsicherung
  • Weiterhin könnte bei mehreren Fehlversuchen eine Sicherheitsabfrage zum Einsatz kommen. (Hier bitte keine Fragen wie bspw. „Wie heißt ihr erstes Haustier“ verwenden! Hier haben die Tiere oft die üblichen Standard-Namen und somit ist das auch wieder vorhersehbar.
  • Einsatz von Captchas (siehe Paralleler Blog Artikel)
  • Wenn möglich, nur eine bestimmte IP-Adresse zulassen.
Logging Alle Angriffsversuche sind vollumfänglich mit Zeitpunkt, IP-Adress etc. zu loggen. Hier sind auch zwingend die entsprechenden Monitorings/Überwachungen einzurichten.
Passwortspeicherung Im Backend niemals Passwörter direkt speichern, sondern nur entsprechende Hashes. Diese sind dann entsprechend gegen die gehashten Anmeldedaten zu validieren.

Auch darauf achten, dass Passwörter nicht direkt in Konfig-Dateien lesbar abgespeichert werden.

Passwort Policy

(Anlage / Änderung)

  • Wie oben beschrieben, erhöht sich die Anzahl der Kombinationen exponentiell zu der Passwortlänge.
    èMindestlänge des Passwortes >= 10 Zeichen
  • Passwort sollte aus Groß-, Kleinbuchstaben, Zahlen und Sonderzeichen bestehen.
  • Keine Wörterbucheinträge
  • Passwort ungleich bzw. darf Benutzername enthalten
  • Passwörter regelmäßig ändern
Passwort Prüfroutine
  • Prüfung der Policy Regeln
    RegEx.IsMatch(„[a-z]“) + RegEx.IsMatch(„[A-Z]“) usw.
  • Passwort (Hash) Historie (max. die letzten n-Hashes) speichern und bereits verwendete Passwörter dürfen nicht erneut gespeichert werden.
  • Prüfung des „Alters“ des Passwortes
  • Nach Anlage /Änderung alles Session Daten etc. löschen und Neuanmeldung erzwingen.
  • Bestätigung bei Anlage /Änderung eines Passwortes über 2. Kanal wie bspw. per Email.
    Keine Passwörter per Email versenden!
Sicherheit im Backend

(Server)

  • Härten der Server
  • Alles auf das notwendigste beschränken
  • Möglicher Lösungsansatz  bei .NET über die „IHttpModule“
  • Immer alles Loggen
  • Login nur über SSL und sichere Protokolle http(s)
  • Alle Eingaben validieren und absichern gegen SQL Injection, Cross-Site scripting
  • Zum Verhindern das ein Angreifer den Session Token übernimmt (Man in the middle), könnten bei Erstanmeldung die Metadaten des Requests ausgelesen und als Session gespeichert werden und mit jeden Zugriff gegen diese Binding-Daten geprüft werden.
URL Aufruf Niemals wichtige Daten direkt als URL Parameter übergeben. (Egal ob per GET oder POST Methode)

Bsp.

schlecht: http://www.beispiel.de/index.aspx?userid=4711

besser:
http://www.beispiel.de/index.aspx?data=Sjz7Rjhuf

(alle Parameter zusammenfassen und verschlüsseln)

Benutzername Der Benutzername sollte wenn möglich nicht auf den Benutzer schließen. Bspw. keine Email-Adresse wie hans.huber@beispiel.de

 

Bitte immer daran denken, dass auch Angreifer die Verfahren kennen!

Der Angriff soll erschwert werden und somit die Möglichkeit liefern, einen Angreifer zu identifizieren.

Links:

Posted in Allgemein.