Im ersten Teil haben wir uns mit dem Thema certificate based authentication beschäftigt und warum Smart Cards als Zertifikatsträger ein Muss sind. Nun gehen wir über zu OTP.
Die notwendige Authentication – OTP
Da nun die Smart Cards nicht so einfach in ein Tablet, ein Smart Phone oder sonstige Geräte passen, die kontrollierte Ausgabe schwierig werden kann oder die Middle-Ware Schwierigkeiten macht, braucht man Alternativen. Die Kopplung via Bluetooth wäre auch security-technisch sicher machbar, aber die Einschränkungen bei der Nutzung der kryptografischen Operationen, zumindest bei mobilen Plattformen, bleibt beschränkt. And the winner is OTP – One-Time-Password.
Wie schon beim letzten Mal angedeutet, sind Hardware-Token sicherer als Software-Token oder sonstige Varianten wie OTP via SMS, E-mail, Anzeigemuster auf der Login Page. Aber definitiv besser als eine statische Information, die n-Mal über Monate verwendet wird. Da bei OTP auch das Haben und das Sein gilt, um eine 2-Faktor-AuthN abzubilden, sind alle anderen Verfahren bei mir eher dynamische Kennworte und keine klassischen 2FA-Lösungen. Auch hier wirkt die Usability konträr zur Sicherheit. Also muss das Verfahren dem IT-Admin vorgegeben sein, sonst gewinnen in der Diskussion 1 Admin – n User meist die User. Einsicht in notwendige Sicherheitsmassnahmen sind beim Benutzer nicht allgemein zu erwarten. Die Legislative (CISO-Management) definiert den notwendigen Standard und die Exekutive (IT-Admins) führt aus. So kann der Passcode = PIN+Tokencode durchaus eine sichere Anmeldung sein.
Der PIN (Personal Identification Number) ist ein aus dem Kartengeschäft eingeprägter Begriff. Im Zusammenhang mit OTPs oder Smart Cards sind das alphanumerische Zeichenketten.
Key Generation
OTPs reichen von TAN-Listen zu keygenerator-basierten Systemen. Wir unterscheiden im zweiten Falle ereignisbasierte (event-based), zeitgesteuerte (time-based) und Challenge/Response-basierte OTP-Verfahren. Das Frage-Antwort-Spiel ist beim Banking noch recht beliebt. In unserer IT-Welt ist das nur in versteckter Form, zum Beispiel bei den bildbasierten Verfahren im Hintergrund aktiv.
Solche Token werden meist basierend auf einem Seed generiert. Der Samen muss also mal gestreut / verteilt worden sein. Bei einem Keypad mit C/R-Verfahren (X9.9-Token), einem Token auch in Kombination mit der genauen Uhrzeit (klassischer RSA – mit zeit- oder eventbased Token) oder einer «Liste» (TAN) wird der Token-Code per Hash-Verfahren (HMAC) berechnet (Haben). Im Normalfall im Zusammenspiel mit dem PIN (Wissen), ergibt das eine sichere Authentisierung. Bei RSA wurde ab 2003 AES eingesetzt und vielleicht werden es in Zukunft eher stream cipher sein. Zur Verifizierung muss der Seed oder der Shared Secret auf der Gegenseite zur Verifizierung bekannt sein, was einen prinzipiellen Unterschied zum private Key darstellt. Wie man dann 2011 bei RSA gesehen hat, nicht nur bei Usern und Authentication-Server. Das kann man gern bei Bruce Schneier nachlesen.
Lassen Sie uns die Algorithmen im nächsten Beitrag vertiefen.
Wie bringen wir es an die Frau oder den Mann?
Das Verteilen der Token, Shipping der Hardware-Token, Enrolment-Prozesse – heute meist via E-Mail und QR-Code oder andere out-of-band Verfahren ist eine echte Challenge und muss deshalb sorgfältig für die User vorbereitet werden. Aber eher eine organisatorische und eine des Lesens. Hier ist man aber flexibler als mit Smart Cards.
Wofür kann man das nutzen?
OTPs sind für das Authentisieren (AuthN) gemacht. Remote Access, VPN und Anmeldungen an einem Webportal. Für die Authorisierung einzelner Transaktionen eher mühsam.
Für eine Anmeldung an einem Desktop mit einem OTP ist es meist das Freischalten von gespeicherten Informationen UserID und Password und bringt auch im Vergleich zu einer zertifikatsbasierten Anmeldung keine Verbesserung für das Kerberos-Protokoll. Für weitere Verfahren wie E-mail, Document-Signing oder Verschlüsselung bringt das eben auch nix. Oft werden diese Token auch geteilt, was die Kosten reduziert, aber Security …? Das ist mit Smartcards nicht zu machen.
Es bleibt also die Identifikation eines Benutzers. Der Benutzer authentisiert sich an einem System oder das System authentifiziert den Benutzer. Darauf basierend geht es dann beim AAA mit Authorization (AuthZ) und Accounting weiter.
Was ist nun wie sicher?
Also meine Wahl wäre ein Hardware-Token, wenn es um die Sicherheit geht. Wenn man diese Token öffnet, haben sie vielerlei Möglichkeiten den Schutz für den Seed oder das Shared Secret zu gewährleisten, wie das halt auch bei Smart Card Chips der Fall ist.
Bei Software-Token, der gute Kompromiss, muss sichergestellt werden, dass die Applikationen nicht angreifbar sind. Also Updates einspielen und dafür sorgen, dass Malware keinen Zugriff darauf hat – Anti-Malware Software auf den Phones. Und Screenshots sind dann schon eventuell Credential Thefts und deshalb ist die Funktion teilweise abgeschaltet. Die Trennung von Access-Device und Authentication-Device (auf dem der Tokencode erzeugt wird), ist bei Hardware-Token ganz klar gegeben, aber bei Software ist das den meisten Benutzern zu mühsam. Compliance-Checks können das Problem einschränken, aber schränken wieder die Flexibilität der Benutzer sein. Es macht aber Sinn, wenn man mal 3 Sekunden darüber nachdenkt.
OTP-Varianten, die im Nachrichten-Ordner landen, der eventuell mit anderen geteilt wird, also Sync oder Backup mit den grossen Anbietern, sind dann sehr fraglich. Wie kontrolliert man die Konfiguration von WhatsApp der Benutzer, so dass die App keinen Zugriff auf die Nachrichten hat und diese zu Facebook „synced“. Diese AuthN-Informationen helfen sicher auch nicht, die richtige Werbung zu platzieren.
SMS ist sehr einfach im Deployment und im Handling für den User, aber schon so oft ausgenutzt. Ob nun der GSM Traffic „umgeleitet“ wird, per Man-in-the-Browser abgegriffen wird oder per Nachrichtenspeicher die Informationen abgegriffen werden, ist eigentlich egal. Die Kosten für solche Angriffe sind kleiner als man denkt, aber SMS hält sich tapfer.
OTP muss auch konsequent genutzt werden
Eine starke Authentisierung nur zu fordern, wenn man bestimmte Bedingungen hat, halte ich für schwierig. Das ist ein Zugeständnis an die Usability. Wenn die Verfahren mal verwendet werden oder mal nicht, ist das für die Benutzer oft nicht transparent und eventuell ist dann auch der Token nicht zur Hand, wobei der doch an der Frau oder dem Mann sein sollte.
Zwei spannende Artikel von heise in diesem Zusammenhang:
www.heise.de/security/meldung/Googles-Zwei-Faktor-Authentifizierung-ausgetrickst-1811237.html
… denn ein vollkommener Widerspruch bleibt gleich geheimnisvoll für Kluge wie für Toren.
Wenn ein Dienstanbieter die Authentisierung kontrolliert, die mit dem Handy des gleichen Herstellers verknüpft ist und die Daten, wenn auch nur als Backup, mit diesem synchronisiert werden, öffnet das nicht Tür und Tor für den selben?
Bildli oder anderes (Bildbasierte Verfahren)
- GrIDsure: ein einzufälliges Feld von Zeichen, bei dem das Wissen des Musters wichtig ist (siehe Beispiel).
- Photos, auf denen charakteristische Linien gezogen werden.
- SecureSign – colored QR code
Challenge-Response-Verfahren sind meist recht mühsam und umständlich für den Benutzer. Gebunden an ein separates Device sind Sie dann aber recht sicher und bieten vor allem eine Entkopplung von AuthN-Device und Access-Device. X9.9 – Challenge response algorithm (proprietary event based) oder OCRA – rfc6287.
Beispiel GrIDsure (Quelle: Gemalto, https://safenet.gemalto.com/multi-factor-authentication/authenticators/grid-authentication, abgerufen am 19.06.2019)
Last but not least …
TAN-Listen etwas altmodisch, aber beim richtigen Austausch der TANs recht sicher. Es kommt wohl darauf an, diese richtig aufzubewahren. Für die tägliche Arbeit in Unternehmen oder Organisationen wohl wenig geeignet.
Der beste Kompromiss ist für mich der SoftToken mit PushOTP. Aber leider muss man sich fragen, in wie weit sich der Cloud-Act dann auf die Kommunikation auswirkt. Die Kommunikationskette sollte man dafür genau betrachten. Security bleibt somit das Abwägen im Spannungsfeld zwischen Zumutbarem, Machbarem, Notwendigem und den Kosten.
2FA – Hurra – Was ist dann MFA?
Multi-Faktor-Authentication. Für mich soll hier ein Mehr gegenüber 2FA – 2 Faktor AuthN suggeriert werden. Vielleicht ist es eine 2FA-Lösung mit verschiedenen Varianten, was aber schon seit vielen Jahren quasi Standard ist. Letztendlich bleibt es hier bei HABEN und WISSEN. Eine wirkliche Erweiterung wäre 3FA, also eine Kombination von Haben-Wissen und Sein, diese werden aber an den Authentisierungssystemen durch Kombination erreicht. Der Fingerprint auf dem Smartphone ersetzt meist den PIN.
Weitere Infos zu Smart Cards unter www.avantec.ch/themen/smart-cards/
Was ist die beste Authentication? Part 1: www.tec-bite.ch/was-ist-die-beste-authentication-part-1/
Der Beitrag Was ist die beste Authentication? Part 2 erschien zuerst auf Tec-Bite.