Best Practice Authentication? Wieso Username + Passwort nicht genügen

Eine Website, die man in diesem Kontext kennen sollte, ist haveibeenpwned.com.

Eine Best Practice für Authentication, wie’s der Titel dieses Artikels suggeriert, gibt es aber leider nicht. Natürlich könnte man aus technischer Sicht alle erdenklichen, neuen, fancy Technologien anwenden und einen Einbruch faktisch verunmöglichen, nur sehen sich die IT-Verantwortlichen dann vielleicht bald von einem aufgebrachten Mob von brennenden Fackeln und Mistgabeln schwingenden Mitarbeitern umgeben, die das gar nicht so toll finden. Im Betrieb gibt es daher meistens einen Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit, leider des Öfteren mit Tendenz in Richtung weniger Sicherheit.

Die Kernaussage, was eine Best Practice angeht, bleibt jedoch ungeachtet der finalen Umsetzung gleich: Username und Passwort alleine sollten, wenn immer möglich, vermieden werden.

Regelmässigen Lesern unseres Blogs dürfte schon der ein oder andere Artikel zum Thema Authentication aufgefallen sein. Mein Kollege mephisto hat dazu schon einiges geschrieben.

Ich will daher an dieser Stelle nicht nochmal im Detail auf die verschiedenen Varianten der Authentifizierung eingehen. Wer sich im Detail für die entsprechenden Methoden interessiert, der findet jeweils einen weiterführenden Link. Ich möchte hier einfach ganz kurz zusammenfassen, welche sicheren Alternativen es zu Username + Passwort gibt, bevor wir dann einen Schritt weitergehen und uns die Context und Risk based Authentication anschauen:

• Zertifikate auf Smart Cards
  

  Anstelle vom Windows Passwort braucht der User einen PIN Code, um das Zertifikat auf der Smart Card für die Nutzung zu entsperren. Selbst wenn einem Hacker dieser PIN Code in die Finger gelangen sollte, nützt ihm dieser alleine nicht viel, da man für einen Login immer noch die Smart Card braucht und die ist hoffentlich nicht ständig im Computer eingesteckt.
  Details zur Authentication mit Smart Cards gibt’s im Artikel von mephisto: www.tec-bite.ch/was-ist-die-beste-authentication-part-1/.

• OTP
  

  OTP’s, also One Time Passwords, können, wie es der Name schon sagt, nur einmal verwendet werden. Am meisten verbreitet sind solche Lösungen mittlerweile in Form von Smartphone Apps, wie z.B. Google Authenticator, Microsoft Authenticator oder MobilePASS+ von Thales. Anstelle des Passworts gibt der Anwender den Passcode aus der App in der Login Maske ein oder quittiert eine Push Notification in der App. Optimalerweise wird der OTP Token innerhalb der App noch von einem eigenen, also geräteunabhängigen, PIN Code geschützt. Alternativ zur App gibt es auch Hardware Tokens. SMS Token fallen ebenfalls in diese Kategorie, gelten aber nicht mehr als sichere Methode.
  Details zu OPT gibt es hier: www.tec-bite.ch/was-ist-die-beste-authentication-part2/.

• Passwordless
  

  Bei einer passwordless Authentication wird jegliche Authentifizierung durch Passwörter oder PIN Codes gegenüber einem Identity Provider eliminiert. Im Endeffekt handelt es sich dabei um eine Public/Private Key basierte Authentifizierung. Der Private Key bleibt dabei immer beim Anwender, nur der öffentliche Schlüssel wird mit Service Providern getauscht. Den privaten Schlüssel kann ich nun natürlich nach wie vor mit einem PIN schützen, jedoch brauche ich keinen PIN mehr, um mich bei einem Identity Provider anzumelden.
  Für Interessierte, hier weitere Infos dazu: www.tec-bite.ch/passwordless-authentication-or-normal-it-madness/.

• Biometrie
  

  Die biometrische Authentifizierung nutzt den menschlichen Körper für die Anmeldung. Ziemlich prominent vertreten dabei ist Microsoft mit Windows Hello for Business. Auch bei Smartphones wird Gesichtserkennung, Iris Scan oder Fingerprint zur Entsperrung des Geräts verwendet.
  mephisto hat auch dieses Thema im Detail angeschaut: www.tec-bite.ch/was-ist-die-beste-authentication-part-3-biometrische-verfahren/.

Hat man die Passwörter erst einmal eliminiert, ist man schon ein grosses Stück weiter. Man kann nun den Zugang noch weiter eingrenzen und so die Angriffsfläche noch weiter verringern. Dazu bieten sich Ansätze wie Context Based Authentication und Risk Based Authentication.

Ein mögliches Beispiel eines solchen Szenarios wäre:

• Login von innerhalb des internen LANs (10.10.0.0/16) einmal täglich über CBA, zwischen 07:00 und 18:00.
• Login von ausserhalb des internen LANs aber innerhalb des Schweizer IP Bereichs ebenfalls einmal täglich, aber über OTP, aber ausschliesslich zwischen 07:00 und 18:00.
• Login von ausserhalb des internen LANs und zusätzlich ausserhalb des Schweizer IP Bereichs jeweils bei jedem Zugang zu einer entsprechenden App über OTP und nur zwischen 07:00 und 18:00.

Diese Szenarios werden dann auf die gewünschten SAML Apps angewendet. Bei einer erfolgreichen Anmeldung kann dann die Authentifizierung zwischen den einzelnen Apps mittels SSO übernommen werden, sofern entsprechend konfiguriert.

Eine Aufzeichnung eines unserer Webinare zu diesem Thema findet man auf YouTube.

Risk Based Authentication (RBA)

Auch bei der risikobasierten Authentifizierung wird der Kontext einer jeden Authentifizierung analysiert. Bei Verdacht auf erhöhtes Risiko oder ungewöhnliches Verhalten wird dann entsprechend reagiert. Man spricht hierbei auch von adaptiver Authentifizierung, weil bei einem Verdacht auf ungewöhnliche Aktivität eine Two-Factor-Authentication (2FA) forciert wird, wo im Normalfall Username und Passwort genügen würden. Wo eine kontextbasierte Authentifizierung vor allem bei externen Services (z.B. für Cloud Dienste) über SAML verwendet wird, so bietet eine Risk Based Authentication Lösung eine gute Möglichkeit, die interne Infrastruktur besser abzusichern. Man denke beispielsweise an all die unpersönlichen Accounts, die für alle möglichen internen Services genutzt werden. Solche Service Accounts werden erstellt und dann oft über Jahre genutzt, ohne dass jemals wieder das Passwort geändert wird. Obwohl diese Accounts (hoffentlich) nur auf den vorgesehenen Systemen erweiterte Berechtigungen besitzen, sind es nach wie vor Domain Accounts, die einem Hacker besser nicht in die Hände fallen sollten. Mit einer RBA-Lösung können diese Accounts auf die für den jeweiligen Service benötigten Systeme beschränkt werden. Eine Verwendung des Accounts auf einem anderen System würde von der Lösung erkannt und unterbunden werden. Ein weiterer praktischer Anwendungsfall wäre die Absicherung von Legacy Applikationen. Applikationen die aus technischen Gründen nicht direkt mit 2FA abgesichert werden können, sondern auf Username und Passwort basieren, können durch eine RBA-Lösung in einem zweiten Schritt mit einer 2FA geschützt werden. Dies geschieht dadurch, dass der Authentication Request zwischen Applikation und Domain Controller abgefangen und eine Authentifizierung über OTP forciert wird.

Komplett auf die Verwendung von Passwörtern zu verzichten ist sehr schwierig. Auch wenn man bei einer Anmeldung eine Two-Factor-Authentication einsetzt, so haben die Active Directory Accounts nach wie vor Passwörter. Setzt man beispielsweise auf Smart Cards, sollte man also die zertifikatsbasierte Anmeldung forcieren, so dass Username + Passwort an Windows Systemen nicht mehr genutzt werden kann. Vielleicht gibt es aber noch interne Systeme, die auf herkömmliche Credentials angewiesen sind, was dann?

Im Endeffekt ist es ein Kompromiss zwischen Machbarkeit und Sicherheit. Smart Cards sind eine gute Sache, können aber nicht in jedem Unternehmen eingesetzt werden. Passwordless Authentication wäre toll, aber vielleicht wollen die Benutzer ihre privaten Smartphones nicht für Business Apps nutzen?

Eine Best Practice gibt es also nicht. Jedoch empfohlene Ansätze, die je nach Infrastruktur und Use Case zu Rate gezogen werden können.