Zwei-Faktor-Authentifizierung

Lisa:

Hallo und herzlich willkommen zu einer neuen Episode vom INNOQ Security Podcast. Heute möchten Christoph: und ich über Zwei-Faktor-Authentifizierung sprechen, und zwar mit HOTP, TOTP und WebAuthn. Hallo Christoph:!

Christoph:

Hallo Lisa.

Lisa:

Was ist denn überhaupt Zwei-Faktor-Authentifizierung?

Christoph:

Zwei-Faktor-Authentifizierung. Dann reden wir vielleicht erst mal darüber: Was ist denn eine Ein-Faktor-Authentifizierung? Das ist das, was wir schon mal in einer anderen Folge von diesem Podcast besprochen haben. Natürlich am weitesten verbreitet mit dem Passwort. Das heißt, ich identifiziere mich mit einem Faktor. Und es gibt mehrere Möglichkeiten, mehrere Faktoren, mit denen man sich authentifizieren kann. Das ist zum einen das Wissen, darunter fällt das Passwort. Ich weiß irgendwas. Oder das kann auch Besitz sein. Zum Beispiel, wenn wir jetzt in die analoge Welt gehen, ein Schlüssel. Ein Schlüssel zu meiner Haustür. Da bin ich im Besitz davon. Im Fall der IT haben wir auch irgendwelche Schlüssel, Hardware-Token zum Beispiel, oder unser Handy ist typischerweise auch, was unter Besitz fällt. Und dann gibt es noch den Faktor „Sein Verhalten“. Andere nennen das biometrische Faktoren. Das ist auch ein bisschen strittig, ob das jetzt etwas Unterschiedliches ist. Also „das Sein“, also biometrische Faktoren, sind mein Fingerabdruck oder meine Iris, die man scannen kann. Oder es gibt diese Handwehen Scan-Methoden. Das Verhalten ist so was wie, man könnte Analysen über mein Tippverhalten machen, die sind sehr individuell oder wenn man mich mit einer Kamera aufnimmt, über meinen Gang. Wie gesagt, das ist nicht ganz klar, ob das als verschiedene Faktoren gezählt wird oder nicht. Die eine Definition macht das, die andere nicht. Aber für uns heute ist das glaube ich mal dasselbe.

Und was heißt jetzt Zwei-Faktor-Authentifizierung? Ich kann mich mit einem Faktor authentifizieren. Typischerweise Passwort. Aber um erhöhte Sicherheit zu erreichen, wollen wir uns mit mehreren Faktoren authentifizieren. Das ist eigentlich das Stichwort Multi-Faktor-Authentifizierung. Aber mehrere heißt zu 90%, es sind nur zwei Faktoren. Und der eine Faktor ist fast immer das Passwort, also Wissen. Und der andere Faktor ist dann etwas anderes. Zum Beispiel der Besitz von Dingen. Und die Verfahren, die du schon angesprochen hast – HOTP, TOTP, WebAuthn – sind so welche. Die schauen wir uns dann heute mal an.

Lisa:

Kombiniert man immer zwei verschiedene Faktoren dabei oder würde man auch mal zweimal Wissen oder zweimal Besitz als Faktoren zählen?

Christoph:

Nach der reinen Lehre versucht man zwei verschiedene Faktoren zu kombinieren. Da sind die Definitionen auch sehr haarspalterisch. Bei dem Verfahren, das wir gleich hören werden – HOTP, TOTP – da braucht man ein Geheimnis, das zwischen dem, der sich authentifizieren will und dem, der authentifiziert, geteilt wird. Und darauf resultierend berechnet man irgendwas. Durch Einmal-Passwörter, da gehen wir gleich im Detail darauf ein. Manche sagen: Das ist auch nur Wissen. Ich weiß mein Passwort als Geheimnis und ich weiß dieses Geheimnis, um diese Einmal-Passwörter zu erzeugen. Andererseits sagt eine andere Definition: Da ich ein Programm dafür brauche, um das zu machen, das kann man nicht so im Kopf rechnen, bin ich im Besitz des Programms, was mit diesem Geheimnis konfiguriert ist und dementsprechend fällt das unter Besitz. Und es gibt auch Grenzfälle, beim Online-Banking zum Beispiel, da ist der zweite Faktor solche Listen, die auch schon wieder strittig sind. TANs sind Geheimnisse. Aber ich besitze vielleicht diese Liste, damals, heute besitze ich die App dazu. Wenn ich die aber auf demselben Gerät habe, habe ich dann auch noch verschiedene Faktoren? Das ist auch ein bisschen strittig. Also wenn ich die Banking App aufrufe, dann mein Passwort eingebe und dann auf demselben Gerät wie meinem Mobiltelefon dann auch noch die Bestätigung dafür eingebe, also eine TAN generiere. Oder bei meiner Bank ist das so, die haben eine spezielle App. Da wird wirklich der Besitz verifiziert. Also ich melde da ein ganz bestimmtes Mobiltelefon an, wo die App drauf ist und dann muss ich da nur noch auf „Bestätigen“ drücken und dann ist halt, je nachdem wie ich das anwende. Aber reine Lehre sagt eigentlich zwei verschiedene. In der Praxis ist das wieder alles sehr grau, da vermischt sich das.

Lisa:

Noch einmal ganz kurz zu diesen verschiedenen Arten von den zwei Faktoren. Gibt es da schon irgendwelche Sicherheitsunterschiede? Zwischen Besitz und Wissen, dass Besitz sicherer ist als Wissen? Oder kann man das gar nicht so pauschal sagen?

Christoph:

Das kann man nicht pauschal sagen. Das kommt auch so ein bisschen auf das Bedrohungsszenario an. Meine biometrischen Merkmale kann man mir leicht entwenden. Man könnte mich mit Gewalt zwingen, meinen Fingerabdruck zu geben oder einen Iris Scan zu machen. Da muss man mich nur davor halten. Bei Wissen ist das schon schwieriger. Aus dem Gehirn was extrahieren, kann man nicht. Man kann sich natürlich vorstellen, Leute können gefoltert werden und geben das dann trotzdem preis. Aber das ist schon ein Unterschied. Und Besitz kann man mir aber auch wegnehmen. Mein Handy könnte man mir am Flughafen, an der Kontrolle abnehmen. Und das kommt dann wie gesagt ganz darauf an, in welchem Bedrohungsszenario ich den eingebe. Das kann ich nicht pauschal sagen. Über Passwörter haben wir schon gesprochen. Wissen kann man mir nicht aus dem Gehirn entziehen. Aber Passwörter haben natürlich ganz viele andere Schwierigkeiten dabei. Und das ändert sich auch. Ein Faktor, den wir noch nicht genannt haben oder ein Verfahren sind auch SMS, was sehr verbreitet war, gerade auch bei Banken, dass man eine SMS als zweiten Faktor zugeschickt bekommen hat. Man loggt sich ein und kriegt noch eine SMS und muss dann noch eingeben, was in der SMS da als Code drinsteht. SMS kann man aber relativ leicht abfangen und kann sie auch umleiten. Man kann so SIM-Card Swapping machen, um an die mobile Nummer einer anderen Person zu kommen. Es ändert sich auch so ein bisschen. Von daher, da würde ich jetzt nicht pauschal was zu sagen, dass eins besser als das andere ist. Aber meistens wird man eine Form von Wissen oder Besitz haben und vielleicht sogar Biometrie. Man hat ein Passwort und ich besitze das Handy, wo ich mein zweites One-Time Password kriege, aber das Handy muss ich auch noch entsperren mit Biometrie. Da könnte man auch sagen, man braucht drei Faktoren. Damit ist man wahrscheinlich schon ganz sicher. Aber wie gesagt, pauschal würde ich das nicht bewerten wollen, dass eins besser als das andere ist. Es ist wahrscheinlich alles gut.

Lisa:

Ich fand es charmant, wie du gesagt hast, es wäre leicht, an deinen Fingerabdruck zu kommen, aber man kann einfach den Finger draufdrücken. Werde ich beim nächsten Event ausprobieren.

Christoph: Nicht nur das. Finger ist sogar wirklich leicht. Das wurde schon bewiesen, da gab es vom Schäuble, als er noch Innenminister war, dass man das aus dem Foto rekonstruiert hat auf mehrere Meter, so einen Fingerabdruck. Von daher ist es schon wirklich leicht. Beim Auge wird es wahrscheinlich schon ein bisschen schwieriger, da muss man wirklich meinen Kopf wahrscheinlich irgendwo mit Gewalt vorhalten. So gesehen ist das manchmal schon sogar relativ einfach, das zu fälschen. Aber ich benutze zum Glück keinen Fingerabdruck-Scanner. Das heißt, wenn du den beim nächsten Event dann abnimmst, dann bin ich immer noch ein bisschen safe. Und vielleicht sollten wir auch über eins reden. Bei Biometrie. Von der Sicherheit ist natürlich ein Problem dabei, dass wir das nicht so viel austauschen können. Fingerabdrücke haben wir zehn. Und wenn die alle verbraucht sind, weil die irgendwie geleaked sind, dann haben wir keinen mehr, den wir noch einsetzen können. Und Iris-Scanner haben wir nur zwei, die maximal möglich sind. Das ist ein spezielles Problem der Biometrie, den man sich vielleicht auch noch vor Augen führen muss. Aber wie gesagt, kommt auch oft auf den Use Case an.

Lisa:

Okay, jetzt haben wir glaube ich genug über diese anfänglichen Dinge gesprochen. Wir wollten eigentlich auf die speziellen Verfahren eingehen. Du hattest als erstes Verfahren HOTP genannt. Was versteckt sich denn dahinter?

Christoph:

Ja, das ist das HMAC-based One-Time Password. HMAC ist hash-based message authentification code. Und wie funktioniert das? Als zweiten Faktor bzw. was bekomme ich da raus? Ich bekomme da ein One-Time Password raus, also ein Passwort, welches ich nur einmalig benutzen kann. Und dieses Passwort ist in der Regel eine Zahl mit sechs Ziffern. Es kann unterschiedlich sein, man kann das auch höher machen, auf sechs bis acht. Aber in der Regel sind es sechs Ziffern, die man da hat. Wie funktioniert das jetzt? Wenn ich das bei irgendeinem Webdienst, ich bin dann schon über mein Passwort angemeldet und möchte meine Sicherheit jetzt verbessern. Dann mache ich mir jetzt einen zweiten Faktor, nämlich HOTP. Dann klicke ich bei dem Anbieter, richte das mal mit ein. Und dann kriege ich verschiedene Informationen. Und bei HOTP ist es relativ einfach. Ich kriege ein Secret, ein Geheimnis und einen Counter, also einen Zähler. Und wie funktioniert das? Wenn ich das jetzt eingerichtet habe. Wie man das machen kann, da gehen wir gleich noch mal darauf ein. Das geht nämlich relativ leicht mit Barcodes. Und diese Barcodes kann man auch für das TOTP-Verfahren nutzen. Deshalb besprechen wir die gleich erst. Und wenn ich das eingerichtet habe, dann wird aus dem Geheimnis plus dem Zähler einfach der HMAC gebildet mit SHA-1. Und dann kriege ich 160-bit raus und die sind ein bisschen lang, um die als Passwort zu nutzen. Deshalb werden aus diesen 160-bit nochmal diese sechs Ziffern extrahiert. Dafür gibt es einen Algorithmus. Da nimmt man von bestimmten Byte den Wert als Offset, springt rein, nimmt dann ein paar Bytes und macht noch eine Rundungsfunktion darauf und dann kriegt man sechs Ziffern raus, damit man nicht ein 160-bit, als einen langen ASCII oder Base64 String eingeben muss. Ich meine diese sechs Ziffern. Also das heißt, HMAC über Geheimnis und Counter, dann so eine Truncate Funktion, die sechs Ziffern liefert und dann geht das. Und damit das One-Time Password nur einmalig ist, heißt das, wenn ich das jetzt einmal errechnet habe, wird dieser Zähler hochgezählt. Und das heißt, von HMAC ist durch die verschiedenen Eingabe-Parameter, weil der Zähler immer wieder einen anderen Wert hat, immer weiter hoch gezählt wird. Da kommt immer wieder ein neues Passwort raus und das kann man dann eingeben. Das ist eigentlich schon alles. Da ist gar nicht viel Magic dabei, das kann man auch in 20 Zeilen mit einer irgendwie Python, Ruby oder sonst was runter programmieren. Das ist relativ einfach zu machen.

Lisa:

Ja, das hört sich eigentlich nicht nur einfach an, sondern auch verständlich und eigentlich auf den ersten Blick erstmal sicher. Gibt es irgendwelche Probleme damit?

Christoph:

Ja, zwei Probleme. Einmal ist es bei der Sicherheit natürlich die Frage ein gesharetes Geheimnis kann natürlich auch verloren gehen. Ich habe das und der Server hat das, der das überprüft. Und wenn wir uns vorstellen, wir nehmen einen zweiten Faktor, um Verbesserungen zu machen, wenn mal die Passwörter geleakt sind. Dann müssen wir auch sicher sein, dass nur die Passwörter geleakt sind und nicht auch diese ganzen Geheimnisse, die der Server irgendwo hat. Das ist bei so einem geshareten Geheimnis natürlich ein Problem. Die sollten möglichst wo ganz anders gespeichert werden als die Passwörter. Und das andere größere Problem dabei, was jetzt nicht die Security betrifft, ist bei der Usability, ist der Fall, wenn diese Counter nicht synchron sind, dann produzieren die verschiedene Passwörter. Das kann ganz leicht passieren. Ich klicke mal, kriege irgendein Passwort, gebe das ein, dazwischen bricht die Netzwerkverbindung ab, der Server erreicht das nicht und dann muss ich nochmal klicken, weil ich die App schon wieder ausgemacht habe. Und dann ist der Counter von meinem einen weiter als der auf dem Server, weil der geht weiter, wenn er ein Neues berechnet. Und es kann auch der umgekehrte Fall sein. Der Server hat mich authentifiziert, aber bevor ich eine Antwort kriege, also mein Browser, die neue Seite mit Authentifizierung und verwendet einen Cookie dafür, der meinen authentifizieren Status ausweist, da geht auch irgendwas verloren auf der Netzwerk Strecke, dann ist der Server Counter vielleicht eins weiter. Oder wenn man die in der Datenbank speichert und der Server stürzt mal ab. Die können aus dem Takt geraten und dann kriege ich immer unterschiedliche raus und dann ist das Problem, wie ich die dann synchronisieren kann. Und da ist das Problem, da gibt es nur einen Vorschlag, aber kein spezifisches standardisiertes Protokoll. Der Vorschlag in der NFC heißt: Ich rechne immer mehrere im Voraus auf dem Server und lasse mehrere gültig sein. Ich berechne mal zwei, drei und sage, die sind jetzt gültig dabei, um dann vielleicht wieder irgendwie in den Takt zu kommen. Das ist natürlich doof, wenn ich mehrere gültige habe und das wird mal abgefangen. Also er sollte nur einmal gültig sein und dann verbraucht. Das weiß ich nicht, dann müsste man sich darauf einigen, wie viele das sind. Das ist nicht gut, ehrlich gesagt. Und die andere Möglichkeit ist natürlich, dass man irgendwie versucht, das manuell wieder zu machen oder neu einrichtet. Man könnte ja sagen: Okay, meine App richte ich neu ein, ein neues Geheimnis, neuer Counter. Und dann geht es wieder. Aber das ist relativ unkomfortabel. Und das hatten wir schon mal bei den Passwörtern und auch bei den Passwort Managern in der letzten Folge, gute UX ist sehr wichtig dafür, dass das Endnutzer annehmen und nicht nur die Techies wie wir, sondern auch so in die breite Masse kommen. Und wir wollen alle mehr Sicherheit und Zwei-Faktor-Authentifizierung bietet uns das und dann brauchen wir ein Verfahren, was hier einfach anzuwenden ist.

Lisa:

Fällt dir gerade ein Beispiel aus der Praxis ein, wer HOTP verwendet?

Christoph:

Auf der Client Seite macht das Google, Authenticator kann dieses HOTP Verfahren und ich meine auch Microsoft kann das auch. Da bin ich mir nicht ganz sicher. Es gibt also ein paar Clients dafür, aber auf der Server Seite tun das nur noch wenige, weil die nehmen eigentlich jetzt alle das TOTP Verfahren, welches ein bisschen besser an der Stelle ist.

Lisa:

Ja, dann lass uns direkt dahin springen. Was ist denn TOTP und warum ist das besser?

Christoph:

TOTP steht für Time-based One-Time Password und das ist relativ ähnlich. Da wird auch über einen HMAC mit einem Geheimnis und einem zweiten Parameter ein Passwort erzeugt, auch wieder mit so einer Truncate Funktion. Der Unterschied ist: Diesmal kann dieser HMAC auch SHA-256 oder SHA-184, also die anderen SHA-Funktionen nehmen. Da kriegt er noch ein bisschen mehr Entropie raus. Und dieser Parameter, der zweite Parameter unterscheidet sich. Das ist jetzt kein Zähler mehr, sondern das ist die Zeit. Und zwar ist das die Zeit eigentlich typischerweise im 30 Sekunden-Takt. Man nimmt irgendwie die Ursprungszeit der Unix-Uhr, der ist irgendwann 1979 hast du nicht gesehen. Und die aktuelle Zeit. Da zieht man von der aktuellen Zeit den Startpunkt ab und teilt das dann durch 30, rundet das und dann hat man sozusagen alle 30 Sekunden einen Sprung in dem Passwort. Deshalb bist du, der diese Authenticator Apps auf seinem Mobiltelefon kennt, sieht man immer, wie lange die noch gültig ist. Beim Google Authenticator werden die dann am Ende auch rot und zeigen, die sind nicht mehr lange gültig und dann springt es irgendwann um und dann hat man das nächste. Und dann kommt man nicht aus dem Takt, solange die Uhren vernünftig synchronisiert sind. Und das Gute ist, Server sind normalerweise an NTP Server angeschlossen, in irgendeiner Form und haben immer eine vernünftige Uhr oder sollte man von ausgehen. Gerade solche Server sollten das haben. Und wo man das typischerweise anwendet, sind diese Mobiltelefon Apps, Google Authenticator oder Microsoft Authenticator, FreeOTP. Da gibt es ganz viele. Also mein Mobiltelefon ist auch immer irgendwie am Netz und kann die aktuelle Uhrzeit ziehen und deshalb sind die relativ genau und haben einen minimalen Time Drift. Das heißt, das brauche ich eigentlich nie groß zu synchronisieren. Synchronisieren heißt, die Uhr muss mal wieder richtig gestellt werden. Und das macht das Mobiltelefon automatisch. Also von daher ist das gar nicht schlecht und besser als das HOTP.

Lisa:

Das hört sich jetzt ja so an, als würde es überhaupt keine Probleme damit geben. Aber gibt es nicht doch irgendwelche Angriffsszenarien oder Probleme mit dem TOTP?

Christoph:

Ja, TOTP ist auch nicht problemfrei. Wir haben dasselbe Problem wie bei HOTP. Das Secret kann natürlich leaken auf dem Application Server, wo das benutzt wird. Das kann natürlich auch in der App leaken. Das ist auch klar, aber das ist sowieso schwierig, wenn man keine Hardware-Tokens benutzt. Da kommen wir vielleicht gleich noch mal drauf bei WebAuthn. Aber das größere Problem, wenn es auf der Server-Seite leakt. Und das andere ist, wenn ich dann doch kein Mobiltelefon benutze, sondern vielleicht eine Hardware, damit zum Beispiel das Secret auf meiner App nicht leaken kann. Also dedizierte Hardware mit einer Anzeige. Dann ist das nicht am Netz. Und dann hat das auch keine Uhr, die sich automatisch synchronisiert. Und solche Uhren gehen auf Dauer, wenn man das auf eine Nutzungszeit von vielleicht zwei, drei Jahren sieht. Dann kriegen die schon einenganz schönen Time-Drift. Gerade so gut funktionierende Uhren sind auch nicht ganz so billig. Und wenn dann etwas billiger eingebaut wird, dann hat man da ein Problem. Und da gibt es auch keinen großen standardisierten Sync. Es gibt in der NFC auch den Vorschlag zu sehen, okay, ich mache jetzt auch so ein Fenster. Ich nehme sozusagen von den letzten 30 Sekunden, von den aktuellen 30 Sekunden und ich berechne schon die nächsten 30 Sekunden sozusagen im Voraus. Und dann schaue ich so ungefähr, wenn das kommt, ob ich so einen Time Drift ermitteln kann, also ob das immer hinter mir ist und oder immer vor mir und kann versuchen meine Uhr danach zu stellen, nach der Uhr, die dann falsch geht. Und das ist aber problematisch, weil a) ist es nicht standardisiert. b) muss ich das für für jeden Token einzeln machen. Da muss ich immer diesen Time Drift haben und man kann das auch nur sehr ungenau bestimmen, weil ich weiß gar nicht, wie oft er mir so ein Token schickt. Eigentlich müsste ich relativ viele Messpunkte haben, um das zu bestimmen. Deshalb wird in der NFC auch gesagt: Man könnte auch sagen, wenn man die mal wieder stellen will, dann soll der Nutzer einfach mal 4, 5 Tokens hintereinander schicken. Gerade auch für den Zeitübergang, um einen Time Drift festzustellen. Aber dazu muss man dann eine Extra-Funktion machen, wo man jetzt sozusagen in der Weboberfläche sagt: Uhr synchronisieren. Und dann gebe ich erst mal zwei Minuten lang irgendwelche Tokens ein, damit der Server ungefähr weiß, wie die Uhr auf meinem Hardware-Device gerade läuft. Deshalb ist es da nicht so gut und es gibt auch gar nicht so viele von diesen Hardware-Devices, die so eine Anzeige haben. Man kennt das vielleicht diese RSA-Tokens, diese Security ID Dinger. So sehen die aus. Da ist eine Segment-Anzeige drin, dann läuft das, hat eine Batterie und alles ist gut. Wobei man sagen muss, jetzt diese RSA-Tokens benutzen ein anderes Verfahren. Die benutzen ein eigenes Verfahren, das auf AES basiert, spielt aber keine Rolle. So sehen die Dinger auch aus und die hat man vielleicht schon mal gesehen, diese RSA-Dinger. Auf dem Mobiltelefon überhaupt kein Problem. Uhr ist synchronisiert. Auf so einem Hardware Device…Naja, geht so.

Lisa:

Was du vorhin noch irgendwie sagtest. Es gibt da so verrückte Barcodes zum Einrichten. Das hast du bei HOTP gesagt und dann hast du gesagt, da reden wir aber bei TOTP nochmal darüber. Was meintest du mit Barcodes, mit irgendwelchen lustigen URLs oder was auch immer zum Einrichten dafür?

Christoph:

Barcodes sind erst einmal gar nicht das Gute daran, sondern in den Barcodes steckt eine URL und diese URL richtet mir mein Authenticator-Programm ein. Und da gibt es so einen informellen Standard, ein Proposed Standard, der eigentlich von allen so benutzt wird. Da hat man ein eigenes URL-Schema gemacht, da beginnt es dann nicht vorne mit HTTP oder HTTPS, sondern mit OTPOS:// und dann kommen die ganzen Parameter. Dann kommt zuerst nämlich der Typ, dann steht Typ heißt entweder HOTP oder TOTP. Und dann kommt ein / und dann kommt der Label. Der Label ist dann sozusagen der Account ist da drin, und zwar aus dem Issuer und dem Account Name. Da wird dann drinstehen, zum Beispiel: example.org:christoph@innoq, der Name, mit dem man sich anmeldet. Es muss gar keine E-Mail-Adresse sein. Es könnte auch etwas anderes sein, womit man sich anmeldet. Aber dann kann man sehen, für welchen Account ist er dann. Und dann kommen noch als Query Parameters, optional die eigentlichen Parameter, um das einzurichten. Da ist einmal das Secret drin. Das ist Base32 encoded da drin. Dann ist nochmal der Issuer drin. Der sollte dann gleich sein wie mit dem vorne. Der ist auch optional. Warum man den doppelt da reingemacht hat, ist mir nicht so ganz klar. Dann kommt der Algorithmus bei TOTP. Dann habe ich gesagt, da kann man SHA nehmen. Also SHA-1, SHA-256, SHA-512. Bei HOTP ist immer nur SHA-1. Da kann ich festlegen, wie viele Ziffern ich bekommen soll. Standardmäßig sind das 6, aber ich könnte auch sagen, ich will jetzt aber 8 oder 7 haben. Ich kann den Counter mitgeben. Den Start Counter. Der muss nicht bei 1 sein. Für HOTP und für TOTP könnte ich noch das Zeitintervall mitgeben, wie lange das gültig sein soll, standardmäßig 30 Sekunden. Aber ich könnte auch sagen: Wir machen nur 15 Sekunden oder 60 Sekunden. Das kann man dann einstellen, je nach Sicherheitsbedürfnis. Wenn man gemein ist, macht man viele Ziffern und das Intervall sehr klein. Da muss man schnell tippen. Aber wie gesagt, standardmäßig sind es 30 Sekunden und sechs Ziffern. Das ist dann in der URL. Auf dem Mobiltelefon haben sich dann die Authenticator Apps auf diese URL registriert. Sagen wir mal, der Microsoft Authenticator ist darauf registriert. Und wenn so eine URL aufgerufen wird, dann wird der Authenticator aufgerufen und der kann die Parameter auslesen und kann sich selbstständig konfigurieren. Der Barcode wird dazu benutzt, diese URL zu kodieren, dann brauche ich, jedes Mobiltelefon, hat auch einen Fotoapparat und wahrscheinlich auch einen Barcode Scanner drin und dann wird er gescannt. Dann wird die URL geöffnet oder versucht zu öffnen oder ich werde gefragt: Möchtest du die öffnen? Und dann öffnet er vielleicht meinen Microsoft Authenticator oder wenn ich mehrere habe, dann werde ich vielleicht auch gefragt: Welchen willst du denn jetzt öffnen? Und dann ist das alles eingerichtet. Das ist sehr gut für den Endnutzer. Wenn ich ein Geheimnis eintippen muss, was auch länger ist, und dann auch noch vielleicht den Namen plus Account, also relativ viele Parameter auf eine Mobiltelefon Tastatur, ist das nicht so bequem. Deshalb ist so ein Barcode echt super. Kann ich scannen, fertig. Und das bietet auch die Möglichkeit, ein Backup anzulegen.

Lisa:

Dann einfach den Barcode bzw. die URL im Password Manager hinterlegen oder wie meinst du das mit dem Backup?

Christoph:

Backup brauche ich, wenn mein Mobiltelefon kaputt gegangen ist und ich möchte trotzdem noch in meinen Account, da muss ich das vielleicht auf meinem neuen Mobiltelefon auch wieder einrichten. Oder ich wechsle das, weil mein Altes jetzt wirklich zu alt ist und ich jetzt ein Neues brauche, dann muss ich das irgendwie wiederherstellen. Vielleicht wechsele ich von Android auf iPhone oder umgekehrt, da muss ich das neu einstellen. Dazu brauche ich irgendwie ein Backup dieser Daten und es würde reichen, die Daten alle einzeln aufzuführen, dann kann man das manuell einrichten. Aber wenn ich einfach nur so einen Ausdruck von dem Barcode irgendwo in den Safe lege oder in meine Kladde, dann ist das ein sehr gutes Backup, um das einfach so wieder einzurichten. Wo man aber aufpassen sollte, was du gesagt hast, in den Password Managern ist es eher schlecht, weil ich will zwei Faktoren haben und wenn ich das Passwort und diesen Barcode an der gleichen Stelle speichere, ist das nicht ganz so günstig. Da kommt es aber auch wieder darauf an, gegen welchen Angriff ich mich wehren will. Wenn er lokal auf meinem Rechner ist und mein Password Manager wird kompromittiert, dann ist beides weg. Wenn ich mich gegen Angriffe auf dem Server schützen will, wenn da was wegkommt, dann kann ich das bei mir trotzdem noch versuchen gleich zu speichern. Aber besser ist es natürlich ausdrucken und dann weg. Aber aufpassen, nicht das Foto dann irgendwie mit iCloud Synchronisierung, Microsoft oder Android synchronisieren und in die Cloud stellen. Das Foto direkt löschen, das muss dann weg sein. Das darf dann natürlich nicht relativ öffentlich zugänglich sein. Sofort Barcode drucken und fertig, weil sonst hebel ich mich da selbst noch ein bisschen aus. Ich glaube, das ist die größte Falle für den Endnutzer. Das ist total komfortabel, aber ich wette auf ganz vielen Mobiltelefonen, die das benutzen und sich nicht wirklich so auskennen, liegen noch Fotos von diesen Barcodes rum, die dann vielleicht auch noch irgendwo hinsynchronisiert werden und vielleicht sogar noch öffentlich gemacht werden. Hier schau mal meine Fotogalerie. Da muss man ein bisschen aufpassen.

Lisa:

Oder die Barcodes sind gar nicht mehr zugänglich, weil man sich dachte: Ach, jetzt habe ich es eingerichtet und nicht an diesen Teil dachte, dass das Handy vielleicht mal gewechselt wird und das das jetzt wirklich daran gekoppelt ist.

Christoph:

Ja genau, oder der große Aberglaube, dass Barcodes auch nur einmal gescannt werden können.

Lisa:

Das habe ich noch nicht gehört.

Christoph:

Das hört man nicht in dem Zusammenhang, aber das hört man jetzt so viel über diese Impfzertifikate, dass große Medien berichten, dass man den Barcode einfach kopieren kann und an verschiedenen Handys einrichten kann. Das scheint ein verbreiteter Glaube zu sein, dass es One-Time Barcodes gibt. Die müssen wir vielleicht einmal finden und dann verbrennen danach.

Lisa:

So wie bei Harry Potter. Auf einmal löst sich das Ganze auf und verpufft.

Christoph:

Ja, so ungefähr. Na ja, gut, aber das ist schon noch ein Problem für den Endnutzer, das klarzumachen, dass dieser Barcode dann wirklich gut verschlossen sein muss.

Lisa:

Was ich jetzt fragen möchte: HOTP und TOTP. Irgendwie hört sich das extrem ähnlich an, steckt da zufällig der gleiche Creator dahinter?

Christoph:

Ja, da hast du recht. Die sind beide von der Initiative For Open Authentification, abgekürzt OATH. ich weiß nicht, ob man das so ausspricht, die Abkürzung. Die haben diese Standards produziert, das ist eine Industrie Allianz, die noch mehr Sachen spezifiziert hat und auch Produkte machen will. Das Problem bei der ist, die sind nicht ganz so offen. Das ist so ISO-like ist. Man muss für Dinge zahlen, um an Informationen ranzukommen oder nicht. Deshalb hat sich das auch nicht so ganz so verbreitet, was die sonst so machen. Außer diesen beiden, weil das ist eine RFC, die sind frei verfügbar. Es steht auch extra dran, dass die frei sind und die haben extreme Verbreitung gebracht. Und dazu gibt es noch die Konkurrenz, das ist die FIDO Allianz, das ist Fast IDentity Online, Abkürzung FIDO. Und die haben auch ein paar Standards gemacht, den Universal 2nd Factor und FIDO 1 und FIDO 2 und WebAuthn ist daraus entstanden. Wir haben gesagt WebAuthn schauen wir uns heute auch noch mal an, was da so hintersteckt. Auf jeden Fall sind in dieser FIDO Allianz die Internet Größen alle dabei. Google, Microsoft, Facebook, Alibaba. Und im Zweifelsfall haben die doch ein bisschen mehr Power dabei, besonders weil die nicht darauf aus sind, groß Geld damit zu verdienen, sondern die wollen Standards machen, um ihre Nutzer besser zu schützen. Das ist nicht unbedingt deren Geschäftszweck, sondern der Geschäftszweck dabei ist vielleicht Vertrauen zu schaffen, dass man auf diesen Plattformen bleibt und denen auch Daten anvertraut.

Lisa:

Genau, jetzt hast du schon gesagt, wer WebAuthn gemacht hat. Was ist das überhaupt? Wie funktioniert WebAuthn?

Christoph:

Ja, WebAuthn hat eine längere Geschichte. Vielleicht rollen wir die noch mal kurz aus, um die Begrifflichkeiten, die alle durch den Raum fliegen, zu klären. Es hat angefangen mit dem Universal 2nd Factor. Das war eine Initiative, da war Google dabei und Yubico, die diese YubiKey herstellen und noch ein anderer Hardware Hersteller NXP. Da bin ich mir jetzt nicht ganz sicher, ob die das gemacht haben und andere haben das Universal Authentification Framework gemacht und die sind beide unter den Schirm dieser FIDO Allianz gegangen. Dann hat man das OAF, das war viel umfangreicher, da ging es darum, wie man sich mit Mobiltelefonen authentifizieren kann, und zwar nicht nur als zweiter Faktor, sondern nur so, dass man den nutzen kann, die Gesichtserkennung oder der Fingerabdruck-Sensor und dass man das benutzen kann, um sich überall zu authentifizieren, auf seinem Rechner, seinem Betriebssystem oder bei irgendeinem Service, bei seiner Bank, bei seinem anderen Finanzdienstleister. Da kommen die beiden her und dann hat man gedacht: Irgendwie müssen wir das auch alles zusammenbringen. Und dann ist das Ganze unter dem FIDO 2.0 aufgegangen. Da sind eigentlich zwei Standards darunter, das ist WebAuthn und das Client Authenticator Protocol. Aber was ist das jetzt? WebAuthn hat man dann an das W3C übergeben und die haben das weiter standardisiert. Das kam aus diesen anderen Spezifikationen von denen und da geht es darum eine JavaScript API zu machen, um im Web eine Authentifizierung hinzukriegen. Und das zweite ist dieses Client to Authenticator Protocol, weil das sehr darauf abzielt, dass man keine App hat, sondern ein Hardware Device, zum Beispiel so einen Key von Yubico, von Nitro oder von anderen Herstellern, also eine Hardware, also einen richtigen Besitz und Hardware dabei hat. Und um mit Hardware zu sprechen, ist das nicht ganz so einfach. Deshalb hat man da versucht, dieses Protokoll zu spezifizieren. Und um es noch ein bisschen komplizierter zu machen, hat man dann das Universal 2nd Factor, was Google und Yukico zuerst angefangen hatten auch noch später umbenannt in das Client to Authenticator Protocol I und was jetzt benutzt wird, ist die Version II. Ja und WebAuthn ist auch noch rückwärts kompatibel mit Extensions, zu diesem Universal 2nd Factor, ist alles relativ kompliziert, aber wenn man jetzt neu damit anfängt, dann sollte man WebAuthn im Web nehmen. Und dieses Client to Authenticator Protocol, da muss man sich wahrscheinlich nur darum kümmern, wenn man ein Browser Hersteller ist, damit der Chrome, der Firefox, der Edge mit diesen Hardware Devices sprechen kann. Und früher war das ganz einfach bei diesem Universal 2nd Factor. Bei dem Vorgänger haben sich diese Devices einfach als Tastatur angemeldet, als Human Device Interface. Da braucht man keinen Treiber für oder nichts. Das war relativ einfach. Das schließt dann aber eine ganze Reihe von Möglichkeiten aus. Wenn ich irgendwie NFC habe oder andere Möglichkeiten, mich irgendwie zu authentifizieren oder auch Smart Cards, die jetzt nicht unbedingt als Tastatur drin sind oder andere Geräte, wo es dann vielleicht auch gar nicht durch den USB Bus gehen soll, weil das könnte man abhören, im Hochsicherheitsbereich. Deshalb gibt es dieses Client to Authenticator Protocol um solche Cases abzudecken. Aber wir sind keine Hardware Experten, deshalb lassen wir das mal ein bisschen raus und schauen mehr um den Webteil, diesen WebAuthn-Teil. Aber wie gesagt, beides zusammen. WebAuthn, Client to Authenticator Protocol II ist FIDO II und das ist jetzt eigentlich das, was man heutzutage machen sollte.

Lisa:

Aber das heißt auch, dass ich für WebAuthn immer einen Hardware Device noch brauche.

Christoph:

Nein, das braucht man nicht. Das ist zwar bevorzugt und wird auch gepusht, aber ich kann das auch in Software machen. Das ist erst mal möglich. Es gibt von der FIDO so eine Liste wie man sein Authenticator zertifizieren kann. Und da gibt es Level 1, 2, 3 und 3+. Und da gibt es bestimmte Anforderungen daran. Level 1 ist irgendwie beliebige Hardware oder Software ohne irgendwelche Anforderungen. Und bei Level 2 braucht man so eine Trusted Execution Engine, auf den Prozessoren spezielle Elemente, wo man Berechnungen ausführen kann, die von anderswo nicht zugänglich sind. Und bei 3 braucht man dann auch noch Schutz gegen physikalische Attacken. Wenn man so einen Key versucht aufzumachen, um das auszulesen, indem man ein Röntgenbild macht oder sonst wie. Ich weiß nicht, ich bin kein Hardware Hacker, aber wie man da dran kommt, dass das dann zum Beispiel auch kaputt geht, weil die so Versieglungstechniken haben und sobald man das aufmacht, ist der Chip zerstört. Und man versucht das zu pushen auf diese Hardware Tokens, die dann schon, wenn die zertifiziert sind mit solchen Maßnahmen gegen Tempering, gegen Angriffe, dass man den aufschleift und das auslesen will auf dem Chip. Das ist dann schon Level 3 und das versuchen wir natürlich entsprechend zu bauen. Aber das kann auch in der Software passieren. Und zum Beispiel gibt es jetzt eine Beta-Version von der Keychain auf iOS, MacOS, auf welchen Systemen das alles verfügbar ist, die auch dieses WebAuthn Protokoll sprechen können, wo der Safari dann mit der Keychain spricht und sagt: Hier kannst du das mal übernehmen? Das geht auch. Und das hat auch gewisse Vorteile in Sachen Backup, aber vielleicht kommen wir da gleich darauf. Vielleicht sollten wir erst einmal klären, wie das so alles geht.

Lisa:

Ja, genau das wäre meine nächste Frage gewesen. Das hörte sich schon alles spannend an, aber so ganz verstanden, wie es richtig funktioniert, habe ich noch nicht. Das würde mich jetzt brennend interessieren.

Christoph:

Wir haben bei WebAuthn zwei Phasen. Einmal müssen wir diesen Authenticator, ob das jetzt eine Software ist oder eine Hardware Key ist, mit der Web App bekannt machen. Das ist einmalig und die zweite, die Betriebsphase ist, wenn wir uns dann damit auch authentifizieren wollen. Wie funktioniert das Ganze? Da gibt es eine JavaScript API, das Navigator.credentials und dann muss ich Public Key machen und kann da tausend Options mit reingeben, was ich denn so haben will. Das ist sehr flexibel das Protokoll. Aber das Grundprinzip ist, dass das auf Public Private Key, auf asymmetrischer Kryptographie basiert. Und wie funktioniert das? Wenn ich den einrichte, dann wird er erst mal gefragt, er erzeugt erst mal ein neues Schlüsselpaar. Der Authenticator wird gefragt: Erzeug bitte ein neues Schlüsselpaar und der Server schickt mir eine Challenge da drin und die signiere ich mit meinem privaten Key und schicke dem Server das Ergebnis dieser Signatur Operation und den öffentlichen Key. Dann kann er das überprüfen und dann weiß er: Du bist wahrscheinlich im Besitz des Private Key und ich speichere mal den Schlüssel für dich bei mir. Dazu kommen noch ein paar Metadaten, eine ID, die dazugehört. Welche Schlüssel ID das ist, damit ich vielleicht auch mehrere Schlüssel für einen Account einrichten kann. Das sind ein paar Details, die jetzt auf der Tonspur wahrscheinlich relativ schwierig sind, da muss man mal in die Spec schauen. Und dann habe ich das auf jeden Fall eingerichtet, dass er meinen Schlüssel mit einer gewissen ID hat. Und wenn ich mich jetzt wieder anmelden will, liefert er auch wieder sein JavaScript aus und da steht dann wieder auch Navigator.credentials. Und da kann er mich auch dann entsprechend abfragen und sagen: Ich müsste mich jetzt mal bitte anmelden. und dann kriege ich wieder so eine Challenge dabei und die müsste ich dann auch wieder signieren. Und wenn ich das signiert habe, schicke ich das dem Server und der Server kann das überprüfen, weil der meinen öffentlichen Schlüssel hat. Wie gesagt, da kommen wieder Metadaten dazu. Der kann dann sagen welche Key ID er haben will, welcher Schlüssel das sein soll. Der kann auch mehrere schicken, welche er haben will, welche Credentials, Timeouts, ich kann da irgendwelche Extensions reinnehmen. Ein Extension ist, damit ich rückwärts kompatibel zu Universal 2nd Factor bin. Ich kann reingeben, dass ich bevorzugterweise irgendein Authenticator habe, der gewisse Eigenschaften hat. Zum Beispiel kann ich als Eigenschaften angeben, dass der in Hardware ist. Es gibt eine Liste, was man da so alles einstellen kann, was die Authenticator angehen. Da gibt es zum Beispiel Key Protection, das kann eine Software sein, kann Hardware sein, kann Trusted Execution Environment sein. Das sind Spezial-Bereiche in den Chips, wo nicht jedes Programm drankommt, ein Secure Element. Dann gibt es die Frage: Wie ist denn der eigentliche Matcher geschützt? Also der diese Vergleichsoperationen oder die Operationen ausführt mit Signatur, der kann auf der Software sein und Chip Trusted Execution Environment. Ich kann auch sagen, wie soll denn der User verifiziert werden an diesem Hardware Device? Ich kann sagen: Okay, der muss irgendwie präsent sein. Das heißt, meistens haben die dann einen Knopf und dann muss ich da mal draufdrücken. Das heißt, ich muss an dem Gerät sein. Ich kann da keinen Remote Angriff machen. Oder ich muss sogar ein biometrisches Merkmal, Fingerprint abgeben oder einen Pass Code oder Gesichtserkennung, Iris Scan. Und dann kann ich sagen. Ich kann danach fragen, ich bevorzuge hier, dass der Authenticator folgendes erfüllt. Sowas kann man alles mitgeben als Metadaten und dann schauen. Da kann man dann verschiedene Sicherheitsniveaus erreichen. Ich nehme das aber nur auf Trusted Hardware und mit User Presence. Und dann kann ich das machen. Aber im Prinzip ist das eine relativ einfache JavaScript API, wo ich sage: Hier Credentials, hier ist die Challenge, die kommt vom Server, dann wird sie signiert. Das wird dann in der Hardware gemacht und dann wird die Antwort an den Server geschickt. Oder vielleicht wird die Signatur wie gesagt wie bei der neuen iCloud Version oder Beta Version auch in der Software gemacht und dann geht das rüber. So funktioniert das dann eigentlich. Und dadurch weiß er: Ich habe den Key und damit weise ich Besitz an der Stelle aus.

Lisa:

Das hört sich auf jeden Fall irgendwie schon mal sicherer an als die ersten beiden, die wir besprochen haben. Ein Vorteil, der mir jetzt sogar aufgefallen ist, als du erzählt hast, ist, dass wir gar kein Geheimnis mehr zwischen Server und Client sharen müssen. Gibt es da noch weitere Vorteile?

Christoph:

Ja, die gibt es. Aber du hast den wichtigsten Vorteil genannt. Bei den anderen haben wir gesagt, wenn die Secrets liegen, die auch auf dem Server sind, dann kann sich irgendein anderer diesen Authenticator einrichten für TOTP oder HOTP bei öffentlichen und privaten Schlüsseln und dann fällt der öffentliche Schlüssel in andere Hände, dann ist das kein Problem, weil der ist eigentlich öffentlich. Das heißt, er könnte höchstens meine Signaturen noch überprüfen. Das macht dann nicht so viel aus, sondern der private Schlüssel liegt nur bei mir und die wurden auch bei mir erzeugt. Und das ist der Riesenvorteil in Sachen Sicherheit. Es gibt noch einen weiteren Vorteil zwischen diesen Daten. Ich habe gesagt, da wird der öffentliche Schlüssel mit irgendeiner ID abgespeichert. Wichtig ist, auf meinem Authenticator wird auch die Domain gespeichert, zu der er gehört. Und das heißt, das bewahrt mich vor Phishing Angriffen. Also nehmen wir mal wieder diese OTP Sachen von vorhin. Da könnte ich jetzt eine Seite nachbauen, die heißt dann INNOQ-Podcast.com. Da reserviere ich jetzt einfach mal die Domain und dann mache ich dann eine Anmeldeseite und verlange die INNOQ Credentials und irgendwer könnte von uns dann vielleicht darauf reinfallen und dabei seine Credentials eintippen. Und die Seite, wenn die automatisiert ist, nimmt dann einfach das Passwort und das One-Time Passwort und loggt sich sofort für mich ein und kann dann Aktionen in meinem Namen ausführen. Das will man nicht. Und bei WebAuthn funktioniert das nicht, weil der Key auch an die Domain gebunden ist. Und eine Phishing Webseite hat nicht die Domain. Wenn sie unsere Domain nicht übernommen haben, dann haben sie eine andere Domain. Da kann man zwar so schöne Sachen machen, wie versuchen, irgendwelche Zeichen reinzuschmuggeln. Dass das so ähnlich aussieht. Es gibt diese Angriffe wo Buchstaben in anderen Alphabeten und anderen Zeichen ganz gleich aussehen. Also bei dem I zum Beispiel ist das auch so eine Sache, dass er sehr gleich aussehen kann, auch wenn man da vielleicht ein L macht. Ein L kann auch wie ein I aussehen oder eine 1. Das funktioniert dann alles nicht, weil der Browser arbeitet nicht optisch, sondern er vergleicht dann mal die Bytes und dann sagt er: Nein, das ist nicht dieselbe Domain. Mein Authenticator rückt dann auch den Schlüssel nicht raus. Da sagt er: Nein, das ist nicht die Domain für diesen Schlüssel, den gebe ich dir nicht. Da gibt es also ein paar Details, wie die Domain aussehen muss. Du willst nicht auch für jede Subdomain was haben. Das wird dann wieder reduziert auf diese so effektiv registrierbare Domain. Das sind aber Details, die jetzt, vielleicht mal für die Audiospur keine Rolle spielen. Das muss man dann noch mal nachlesen, wenn man das dann entsprechend auf der Server-Seite einrichtet und sich damit beschäftigen, welche Domains will ich denn da eigentlich mit haben? Aber generell stellt der Browser durch das Protokoll dann sicher, dass die Anfrage mit der Domain kommt und dann sagt mein Authenticator: Nein, mache ich nicht. Das ist wahrscheinlich ein Phishing-Angriff. Das sagte mir nicht, aber er wird das verweigern und dann gibt es da einen Fehler. Das heißt, der Angriffvektor ist auch geschlossen.

Lisa:

Bei so vielen Vorteilen gibt es auch Nachteile bei WebAuthn?

Christoph:

Ja, das hatte ich schon ein bisschen angesprochen. Das Backup ist damit natürlich ein bisschen schwierig. Man will diese Hardware Tokens auch deshalb ein bisschen pushen, weil da auch das Secret auf der Stelle nicht raus leaken kann. Wenn wir das in Software haben, haben wir immer noch ein Problem. Dann könnten wir auch selbst angegriffen werden und der Key geht verloren und bei Hardware ist es schwierig. Selbst wenn man mir dann den Rechner stiehlt und ich habe den Token an meinen Schlüsselbund, kommt man da nicht dran. Das ist sehr gut für die Security, aber der Nachteil ist, die sind ausgelegt, dass man diese Keys auch gar nicht auslesen kann. Das heißt, ich kann auch kein Backup machen. Und wenn mir der Key dann mal verloren geht, weil ich meinen Schlüsselbund verloren habe bzw. weil der Key kaputt gegangen ist, das ist Hardware und sonst fliegt mein Schlüssel auch mal runter. Die sind zwar schon sehr robust, aber das kann trotzdem mal kaputt gehen. Und dann kann ich mich selbst aussperren aus so einem Account, da muss ich da irgendwie wieder dran kommen. Und Backup heißt aber, ich brauche noch einen zweiten Key, den ich auch einrichte, damit ich sozusagen zwei Keys habe. Aber den zweiten Key soll ich natürlich nicht auch immer gleichzeitig mit mir rumschleppen, weil wenn ich dann den Schlüsselbund verliere, verliere ich beide, sondern das ist auch wieder so was, was fürs Backup zu Hause in den Tresor wandern sollte. Und dann ist das Problem, wenn ich mir jetzt einen Account einrichte, im Büro und müsste für einen Auftraggeber Accounts einrichten und die sind damit gesichert. Dann müsste ich das irgendwann nachholen, den zweiten Key. Dann muss ich vielleicht am nächsten Tag den anderen Key mitnehmen und den auch noch mal einrichten. Und das kann ich leicht vergessen. Es ist schwierig, zwei Keys synchron zu halten, dass alle Accounts darauf sind. Und das andere ist, muss ich auch noch regelmäßig testen. Also bei einem Barcode kann ich relativ gut sehen, ab wann ich da eine Kopie von machen sollte oder das Papier sich langsam auflöst. Es ist auch relativ schnell da, mal auf dem Kopierer dreimal den Barcode in den Safe zu legen, diesen Key mal wieder auszuprobieren, ob da noch alles in Ordnung ist und wie langlebig der ist, das ist natürlich deutlich schwieriger. Und das ist jetzt im professionellen Umfeld eher weniger das Problem. Der kostet natürlich auch was. So ein guter Key kostet 40, 50 Euro pro Stück. Das heißt 100 Euro und wenn man das für den Privatgebrauch macht, ich weiß das nicht, da sparen die Leute immer an der falschen Stelle. Das ist natürlich auch das Problem mit dem WebAuthn. Da muss man schauen, welche Funktion man da noch drauf hat. Meistens können die dann noch das alte Verfahren. Manche können dann noch den GPG Key schlüsseln oder S/MIME und noch ein bisschen mehr als einfach nur WebAuthn. Und was die so alles selbst als Sicherheitsmerkmale haben, weil ich habe kurz erwähnt, dass vielleicht so eine Taste dran, die muss ich drücken. Damit die nicht einfach einsteckbar sind und von anderen genutzt werden können, ist es auch noch so, dass die auch noch abgesichert werden können. Zum Beispiel mit einer PIN, die dann auch mal abgefragt wird, bevor ich die dann benutzen kann. Ich stecke ihn dann ein und wenn das WebAuthn aufgerufen wird und ich benutze ihn dann zum ersten Mal wieder, seit er neu im Computer eingesteckt ist, dann muss ich vielleicht die PIN eingeben. Das ist dann unterschiedlich. Das kann auch über das Protokoll gesteuert werden, ob das jedes Mal abgefragt wird oder nicht. Und es gibt dann auch welche mit der Biometrie, mit Fingerabdruck. Die sind ein bisschen komfortabler als sich noch einen PIN zu merken. Dann steckt man den ein und die haben einen Fingerabdruck Sensor drauf. Da kann ich ihn dann auch noch mal drücken und da muss man sehen, welche Merkmale man haben will und wo dann die Preis Range liegt. Das kann von 20 bis 60 Euro sein. Die ganz billigen würde ich nicht nehmen. Es gibt auch so China Zeug für 5 Euro. Die sind zwar funktional, aber da weiß man nichts über die Langlebigkeit und auch nicht, ob die Leute da nicht ihr Geld noch mit Vektors verdienen, anstatt mit der Hardware. Da würde ich schon auf vertrauenswürdige Anbieter zählen und da gibt es einige. Wie gesagt, YubiKey könnte man dabei nennen. Nitrokey, Google hat einen eigenen Stick, die haben einen Titan Chip drauf, so ein spezieller Chip, der entwickelt dafür ist, um solche Geheimnisse zu halten. Also da gibt es eine ganze Reihe. Bestimmt 10 Anbieter, wo man sagen kann, den würde man jetzt nicht sofort zutrauen, dass sie damit Schindluder treiben. Und es gibt aber bestimmt hunderte auf den einschlägigen China-Versendern, die sehr billig sind, die man noch nie gehört hat. Da muss man, würde ich dazu raten, die Finger davon zu lassen. Das ist wahrscheinlich an der falschen Stelle gespart, wo ich natürlich keine Ahnung habe, ob die wirklich da irgendwelche Backdoors dran haben oder nicht, aber das will ich gar nicht riskieren wollen.

Lisa:

Du hattest vorhin auch gesagt, dass Apple an der Software-Variante dran ist.

Christoph:

Genau.

Lisa:

Möglicherweise kommen da dann noch andere Anbieter noch hinterher und vielleicht ist das für den Anfang auch gar nicht so schlecht.

Lisa:

Ja, ich glaube Android ist da auch dran. Ich meine, die konnten dieses Universal 2nd Factor schon, aber da bin ich nicht ganz sicher. Schreiben wir mal in die Shownotes dann einen Link drauf, wenn das so ist, dass die das auch benutzen und wer das auch benutzt oder jetzt in Zukunft verstärkt benutzen will, ist Microsoft. Und zwar gibt es dieses Windows Hello, womit man sich irgendwie per Fingerabdruck und auch mit dem Gesicht scannen und mit anderen Merkmalen anmelden kann. Ich weiß gar nicht, was da alles geht. Und das ist dann in viele Rechner verbaut und unter Windows kann das auch WebAuthn sprechen. Dann kann man das als Authenticator benutzen. Das ist natürlich ganz praktisch, dann hat man das schon mal eingebaut. Da ist natürlich die Frage, die wir mal ganz am Anfang hatten. Wenn wir das alles auf demselben Gerät haben, sind das dann noch wirklich zwei Faktoren? Wenn ich meinen Password Manager darauf habe und die Software, die für Windows Hello den Fingerabdruck gespeichert hat, dann ist das nicht wirklich ganz Zwei-Faktor Authentifizierung, aber besser als nur das Passwort. Microsoft geht aber noch ein bisschen weiter. Die wollen eigentlich gar kein Passwort mehr haben und die nutzen den WebAuthn als einzige Anmeldung. Das ist eigentlich auch ein Use Case, der vorgesehen ist, dass man WebAuthn als einzige Anmeldung benutzt und gar keinen zweiten Faktor dafür hat, dass man sagt: Du meldest dich an, aber auf jeden Fall gesichert mit Biometrie. Dann reicht das uns auch als einziger Faktor. Ich habe so ein Fingertip, wo man nur den Knopf drücken muss. Der User ist an dem Gerät, würde ich sicherstellen. Das würde ich als einzigen Faktor nicht nehmen. Aber das ist bei Windows Hello auch gar nicht so. Man hat da relativ gesicherte Verfahren, die meisten oder alle biometrisch. Von daher kann es sein, dass das in Zukunft auch dann vielleicht in einigen Bereichen das Passwort komplett verdrängen wird. Das werden wir sehen. Es kommt auch drauf an, wie das angenommen wird.

Lisa:

Was ist dein Gefühl?

Christoph:

Auf dem Mobiltelefon hat sich das super durchgesetzt. Fingerabdruck und Gesichtserkennung nutzen wahrscheinlich 80% der Leute. Bei dem Rechner bin ich mir nicht so ganz sicher, da habe ich schon oft gesehen, dass solche Teile verbaut sind, die Leute das aber gar nicht unbedingt nutzen. Apple hat das auch, die haben in den neueren MacBooks auch so einen Fingerabdruck Sensor drin und den könnte man auch nutzen. Und wie gesagt, Windows Geräte haben das auch sehr oft und das ist auch vom Betriebssystem jeweils vorgesehen. Aber da sehe ich das oft, dass die Leute trotzdem ihr Passwort benutzen. Das muss man mal sehen. Also ich kann mir vorstellen, das funktioniert dann gut, wenn man so was hat. Wenn ich zum Beispiel das auf meiner Uhr habe. Man kann auch die Apple Watch benutzen, um sich anzumelden. Ich glaube, das spricht noch nicht WebAuthn da drunter. Man kann sich sowas vorstellen, dass man das andere Alltagsgerät hat und als Anmeldeverfahren dann nutzt und dass das dann auch auf WebAuthn aufsetzt. Aber ich kann auch nicht in die Zukunft sehen. Von daher lassen wir uns mal überraschen. Gerade wo wir alle, wahrscheinlich die meisten Hörerinnen und Hörer von uns auch in der IT arbeiten werden, ist wahrscheinlich ein Hardware Token und WebAuthn schon eine gute Sache. Und da sollten die Kosten auch nicht abschrecken lassen. Das sollte meistens auch eigentlich der Arbeitgeber bezahlen. Und dann ist gerechnet eigentlich auch nicht viel, wenn man mal 100 Euro ausgibt und dann so eine Lebenszeit von 2, 3 Jahren für diese Keys wahrscheinlich hat, vielleicht auch länger, dann fällt das wahrscheinlich nicht so ins Gewicht.

Lisa:

Hatten wir schon irgendwie Beispiele genannt, wo ich jetzt schon mit WebAuthn arbeiten kann, also wo ich das als zweiten Faktor verwenden kann, zum Beispiel so ein YubiKey?

Christoph:

GitHub geht zum Beispiel, bei Google geht das und ich glaube die meisten großen Webdienste können das auch. Ich bin mir relativ sicher, dass man das auch bei Facebook machen kann. Ich bin selbst kein Facebook-Nutzer, deshalb kann ich das nicht mit Sicherheit sagen. Aber die sind alle da drin in der Allianz und da kann man das ganz gut nutzen. Was vielleicht zu erwähnen ist, vielleicht interessant für die Hörerinnen und Hörer, dass, wenn man das selbst benutzen will, dass der Keycloak, ein relativ bekannter OpenID Connect OAuth und Sammelserver für Authentifizierungs-, Autorisierungszwecke ist. Der kann das auch in den neueren Versionen, ist aber noch ein bisschen eingeschränkt. Ich weiß nicht, ob das schon behoben ist, aber man konnte eine ganze Zeit nur einen Key registrieren. Das ist für ein Backup natürlich schlecht. Andererseits, wenn man den firmenintern nutzt, dann kann der Administrator auch so ein Ding wieder rauslöschen und sagen, man kann ein neues einrichten. Dann hat man noch so ein Backup. Das kann man, wenn man sich an ein breites Publikum wendet und jeden anonymen User bei sich einen Account machen lassen kann, dann ist das mit dem Support ein bisschen schwierig. Firmenintern kann man das dann auch leisten. Dann wäre dieses Use Case-Szenario zum Beispiel abgedeckt. Wenn man den nutzt, um anonyme User zu machen, dann sollte man vielleicht warten, bis der dann zwei Keys kann, dass man das sozusagen im Self Service auch regelt, sonst wird es ein bisschen schwierig. Der kann das. Wie gesagt, den allerneuesten Stand habe ich nicht. Vielleicht kann er jetzt auch schon zwei aber das ist so eine Mindestanforderung.

Lisa:

Spannend. Christoph, ich glaube, ich habe keine Fragen mehr. Hast du noch irgendwas, was du so als letzte Worte mitgeben möchtest zu dem Thema?

Christoph:

Ja, ich würde empfehlen. Ich habe vorhin schon gesagt: WebAuthn für die Professionals sozusagen, aber auch für alle anderen: TOTP ist auch ein Sicherheitsgewinn und das ist so einfach, macht das einfach. Nicht nur wenn ihr gezwungen seid, weil eure Bank euch das vorschreibt und Banken auch verpflichtet sind, einen zweiten Faktor anzubieten. TOTP ist ganz einfach und bringt einen Sicherheitsgewinn, also macht das. Und auch wenn ihr das auf demselben Device habt, das gibt in allen Szenarien immer noch einen Sicherheitsgewinn. Also solltet ihr das tun. Das ist so das Beste. Und dann schauen wir mal, wie sich so mit WebAuthn, den Software-Lösungen und den integrierten Hardware Lösungen, die man sowieso mitgeliefert kriegt, dann entwickelt.

Lisa:

Es bleibt also spannend auf dem Gebiet. Ja, vielen Dank Christoph. Es war wirklich richtig interessant heute und du hast viele Fragen beantwortet. Das freut mich. Das war für mich eine coole Folge. Ich hoffe, für die Zuhörerinnen und Zuhörer da draußen war es genauso spannend und interessant wie für mich. Falls es euch gefallen hat, würden wir uns natürlich freuen, wenn ihr die Folge bewerten könntet. Und falls ihr irgendwelches Feedback habt oder vielleicht sogar noch weitergehende Fragen, freuen wir uns auch auf eine Mail von euch an [email protected]. Das Ganze ist natürlich auch in den Shownotes verlinkt, damit ihr das nicht abtippen müsst. Vielen Dank für die schöne Folge und bis zum nächsten Mal.

Christoph:

Bis bald. Ciao.