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