Photo by Jose Antonio Gallego Vázquez on Unsplash

Zur Abstimmung E-ID

Dieser Artikel dreht sich um die Sicherheit der in der Schweiz geplanten E-ID, zu welcher am 07.03.2021 das Referendum zur Abstimmung kommt.

Da es aus meiner Sicht als Fachexperte, in der ganzen E-ID Diskussion zu viele Schlagworte und einen von traditionellen Annahmen geprägten Technologie-Idealismus gibt, versuche ich, in diesem Artikel meine Bedenken zu teilen und Alternativen zum aktuellen Konzept in den Diskurs mit einzubringen.

Vorab: am Sinn und dem allgemeinem Bedarf eines Mittels zur sicheren digitalen Identifikation zweifle ich nicht. Ich bin allerdings der Meinung, dass dieses Mittel für seinen Zweck, gemäss empfohlener Praxis, sicher und aus Sicht des Datenschutzes unbedenklich sein sollte.

Eine Frage der Zielsetzung!

Die erste Problematik der E-ID Diskussion ist meiner Meinung nach, dass der Einsatzzweck einer solchen Identität unklar definiert wurde. Die Illusion, dass damit alle möglichen Google, Microsoft, usw. Konten abgelöst werden können, möchte ich bereits an dieser Stelle aus dem Weg räumen. Grundsätzlich ist es so, dass eine Identität durch die Service Provider (SP) akzeptiert werden muss, um überhaupt eine sinnvolle Verbreitung zu erreichen.

Als Identity Provider (IDP oder OP im OAuth und OpenID Connect Jargon) steht man in einer “Sandwich Position”. Als IDP mit geringer Relevanz stehen die Chancen sehr gering, von einem SP eingebunden zu werden. Ebenfalls müssen die SP explizit ein Vertrauensverhältnis zu einem IDP aufbauen, damit dessen Identitäten der Zugriff gestattet wird. Um dieses Vertrauen aber zu erlangen, müssen zuerst genügend Nutzer überzeugt werden, den IDP zu nutzen. Dies mag für einen Social Login (wie z.B. Facebook oder Twitter) eine Strategie darstellen, fühlt sich bei einer Identität mit beglaubigten Attributen aber merkwürdig an.

Daher soll aus meiner Perspektive die E-ID eine klare Fokussierung auf das “rechtlich abgesicherte Geschäft” legen, in welchem die Nichtabstreitbarkeit im Fokus steht und gewisse Abstriche im Bereich der User Experience eingegangen werden müssen. Dies zugunsten der Sicherheit der E-ID und des Datenschutzes. Gerade bei der Nutzung einer E-ID im Kontext von sensitiven Daten wie beim elektronischen Patientendossier (EPD), Betreibungsregister usw. denke ich, dass sich diese Haltung auszahlen wird.

In diesem Artikel werde ich folglich nur auf das E-ID Sicherheitsniveau “Hoch” eingehen. Diese soll für den Einsatz bei kritischen Services wie dem EPD, Betreibungsdaten, Steuern usw. geeignet sein.

Die Problemstellung

Aus meiner Sicht birgt das aktuelle Konzept an den folgenden drei grundlegenden Punkten (Impersonation, Nichtabstreitbarkeit und Datenschutz) gewisse Risiken.
Die E-ID muss, wenn sie für kritische Zugriffe geeignet sein soll, folgende und durchaus bereits aus der Praxis bekannte Probleme, adressieren.

Impersonation

Das Risiko der Impersonation¹, also der unberechtigte Zugriff auf Daten einer dritten Person, muss im Rahmen des Möglichen zwingend reduziert werden. Eine Impersonation kann durch technische Fehler sowie auch durch Angriffe entstehen. Dies ist im aktuellen Konzept mit zentralen IDPs nicht gewährleistet (vgl. Abschnitt Risiken).

Mögliche Lösung: Die eingesetzten Mittel und Prozesse müssen eine End-to-End Verifikation (vom Benutzer bis zum SP) erlauben und soweit wie möglich gegen Extraktion von Secrets auf dem User-Agent (beispielsweise ein Browser) und der Transportverbindung (TLS) geschützt sein.

Nichtabstreitbarkeit

Birgt die E-ID ein Risiko der Impersonation, so kann der SP diese nicht für geschäftliche Beziehungen einsetzen, in welchen eine Nichtabstreitbarkeit benötigt wird. Aus meiner Sicht ist dies jedoch einer der Hauptgründe für die Etablierung einer E-ID.

Beispiel: Sollte die E-ID mit einem Remote-Signatur-Verfahren kombiniert werden und als Nachweis für den “Signer” (Unterzeichner) genutzt werden, so ergibt sich hier das Risiko, dass eine kompromittierte Identität, anstelle des eigentlichen Nutzers, unbemerkt rechtsgültig Dokumente signiert.

Mögliche Lösung: Impersonation als Risiko muss reduziert werden (Lösung siehe weiter unten) oder auf die Möglichkeit des Remote-Signatur-Verfahrens mit der vorgeschlagenen E-ID muss verzichtet werden, was wiederum in der digitalen Abwicklung von Rechtsgeschäften hinderlich ist.

Datenschutz

Um das Risiko eines Missbrauches von Attributen (Name, Vorname, …) und Metadaten (User-Agent, Sprache, Version, IP, …) zu reduzieren, muss ein Konzept gewählt werden, welches verhindert, dass solche an einem zentralen Punkt entstehen und gespeichert werden können.

Mögliche Lösung: Bei einem Verfahren mit einer dezentralen Authentifizierung (die Authentifizierung findet direkt zwischen dem User-Agent, und dem SP statt) fallen keine Metadaten an einem zentralen Ort an, folglich wird die Verarbeitung und das Sammeln von Daten minimiert. Solch ein dezentrales Verfahren kann auf verschiedene Arten adressiert werden. Zum Beispiel der Einsatz von Client Zertifikaten (mutual TLS) oder durch DID’s (dezentrale Identitäten).

Bemerkung: Privacy entsteht nicht durch Trust! Nur weil ich einem IDP vertraue, entsteht noch lange kein ausreichender Schutz meiner persönlichen Daten. Es besteht weiterhin die Chance des Missbrauchs oder des Verlustes von Daten — auch ein vertrauenswürdiger IDP kann kompromittiert werden.

Risiken

Da das grösste Risiko einer digitalen Identität die Impersonation ist, sei es durch technische Fehler oder Angriffe, sollte das E-ID Konzept eine Minderung dieses Risikos von Grund auf vorsehen. In diesem Kapitel versuche ich, einige der Probleme darzustellen, welche diese Risiken fördern. Ich erhebe keinen Anspruch auf Vollständigkeit der Massnahmen.

Login

Die offensichtlichste Problematik sind Angriffe auf die Login-Verfahren der IDPs. Selbst 2FA-Lösungen (2-Faktor-Authentifizierung) sind nicht über alle Zweifel erhaben, wie die jüngst vermehrten Angriffe² ³ ⁴ auf SMS-TAN und OTP zeigen.

Mögliche Mitigationen

• Einsatz von Phishing-resistenten 2FA Verfahren (U2F / CTAP1)
• Nutzung von Phishing-resistenten Passwordless Verfahren (FIDO2 / CTAP2)

Diese beiden Verfahren wurden von der FIDO Alliance, welcher sowohl die weltweit grössten Unternehmen, als auch internationalen Regierungsstellen angehören, zur Lösung der Probleme mit unsicheren Anmeldeverfahren entwickelt.

Föderations-Protokolle

Der Einsatz von Föderations-Protokollen birgt diverse Risiken. Meist handelt es sich dabei um Fehlkonfigurationen, welche beim IDP als auch beim SP entstehen können. Ein erfolgreicher Angriff äussert sich primär darin, dass der Angreifer Zugriff auf die Tokens erhält. Mit diesen kann dieser möglicherweise auf die Schnittstellen des SP sowie des IDP zugreifen. So erhält der Angreifer Zugang zu den gespeicherten Daten.

Vorkommende Probleme:

OAuth 2.0 / OpenID Connect 1.0

• Besonders bei mobilen Geräten Angriff auf die Callback Handler um Authorization Codes abzugreifen⁵
• Open Redirect (Covert Redirect)⁶
• Issuer Mix-Up⁶ ⁷
• Fehler in JWT Librarie⁸ ⁹
• Replay Attacks¹⁰

SAML 2.0

• Fehler in den XML Libraries¹¹

Mögliche Mitigationen: Für fast alle diese Probleme existieren Mitigationen, welche allerdings meist komplex zu verstehen und anzuwenden sind. Durch die genannte Komplexität, sowie die Tatsache, dass die meisten Massnahmen durch den IDP und den SP implementiert werden müssen, erhöht sich das Risiko.

Man-in-the-Middle TLS

Verfügt ein Angreifer über ein Zertifikat, welches vom User-Agent als vertrauenswürdig eingestuft wird, können sämtliche Inhalte, welche über die belauschte Verbindung versendet werden, manipuliert oder extrahiert werden. Da standardmässig Security Tokens von Autorisierungsservern nicht an den Client gebunden werden, können diese bis zu ihrem Ablaufdatum, oder anderen Sperrmechanismen, vom Angreifer weiterverwendet werden.

Dies ist insbesondere beim Einsatz von TLS terminierenden Enterprise Proxys ein valides Risiko¹². Auch kommt es immer wieder zu Angriffen, bei welchen über verschiedene Kanäle zusätzliche Zertifikate in den Truststore des Betriebssystems geladen werden und dadurch der Verkehr auf einen Proxy umgeleitet werden kann.

Mögliche Mitigationen: Damit Token, Cookies und ähnliche Merkmale nicht (oder nur schwer) durch einen Man-in-the-middle (MITM) abgegriffen werden können, gibt es verschiedene Konzepte. Diese müssen durch alle Beteiligten (User-Agent, SP, RP) unterstützt werden und sind teilweise schwer zu implementieren.

• OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (User-Agent zum IDP)¹³
• Token Binding¹⁴
• Mutual TLS (User-Agent zum SP)¹⁵ ¹⁶

Bemerkung: Token Binding ist ebenfalls anfällig für MITM Angriffe, bei welchen der Angreifer das Föderations-Protokoll implementiert. Token Binding wird von den verbreiteten Browsern nicht (mehr)unterstützt¹⁷.

Man-in-the-Middle DNS

Angriffe auf die DNS Einträge sind ein grosses Problem, da durch einen falschen DNS Eintrag ein Opfer auf einen Proxy geleitet werden könnte, welcher sich als Login des IDP ausgibt. Dieser Proxy kann versuchen, eine Verbindung ohne TLS zu etablieren¹⁸ um so die Problematik zu umgehen dass die CA (Certificate Authority) des MITM Proxies nicht im Client vorhanden ist. Dieser Angriff kann in Kombination mit MITM TLS (siehe oben) angewendet werden.

Mögliche Mitigationen: Damit sich die Angriffsfläche für MITM reduziert, empfiehlt es sich zusätzlich die DNS Dienste zu härten.

• DNSSEC (Domain Name System Security Extensions)¹⁹
• DoH (DNS over HTTPS)²⁰
• HTTP Strict Transport Security (HSTS) Preload List²¹
• HTTP Strict Transport Security (HSTS)²⁸

Bemerkung: Da nicht alle DNS Anbieter, Betriebssysteme und Browser (User-Agent) mit DNSSEC korrekt umgehen, ist die Wirksamkeit möglicherweise eingeschränkt.

Angriffe auf den User-Agent (Browser)

Angriffe auf den Browser können in verschiedenen Formen erfolgen.

Eine mögliche Angriffsfläche können Browser-Extensions sein, welche Zugriff auf die Cookies und Tokens im Speicher des Browsers erhalten. Als Beispiel könnte ein kompromittierter Adblocker dienen.

In Szenarien, in welchen der SP eine Single Page Application ist, speichert dieser in den meisten Fällen die ID- und Access-Token im Session- oder Local-Storage des Browsers.

Zusätzliche Angriffsvektoren sind vorhanden, wenn die Web-Applikation, die geladen wird, unzureichend vor Veränderung und Cross-Site-Scripting geschützt ist.

Mögliche Mitigationen: Um das Extrahieren von Sicherheitsmerkmalen (Cookies, Tokens, …) zu erschweren empfiehlt es sich die Web-Applikationen vor Übergriffen zu schützen. Folgende Header sollten vom IDP als auch vom SP angewendet werden:

• Content Security Policy (CSP)²⁶
• Cross-Site Request Forgery Token / Cookie²⁷
• Cookie mit SameSite Flag²⁷
• HTTP Strict Transport Security (HSTS)²⁸

Bemerkung: Grundsätzlich sollte versucht werden, ein Zero Trust Ansatz zu etablieren, in welchem auch ein kompromittierter Browser einen geringen Einfluss hat. Dies kann erreicht werden, wenn ein externer Key Store zum Einsatz kommt. Dies ist insbesondere für FIDO2 und Smartcard gültig. Wobei Smartcard mit mTLS einen besseren Schutz bietet, da TLS vom Betriebssystem geleistet wird und nicht vom Browser¹⁷.

Technische Fehler bei der Attribut Assertion

Ein durchaus denkbares Szenario ist, dass aufgrund technischer Probleme beim IDP, verfälschte Attribute an die SP gesendet werden. Beispielsweise kann statt meiner Identität diejenige einer komplett anderen Person gesendet werden. In diesem Fall würde der Nutzer Zugriff auf kritische Daten erhalten, die nicht für ihn bestimmt sind, wie etwa Einsicht in das EPD (elektronische Patientendossier) einer anderen Person.

Mögliche Mitigationen: Fehler dieser Art sind schwer zu verhindern, kommen aber zum Glück nicht häufig vor. Allerdings bergen diese ein hohes Risiko für Datenverlust und Missbrauch.

• Integration und Unit Testing des Source Codes
• SAST (Static Application Security Testing)
• Code Fuzzing
• End to End (User-Agent zum SP) Verifikation der Attribute

Bemerkung: Der Nutzer muss dem IDP vertrauen, dass dieser die richtigen Informationen weitergibt und hat nahezu keine Möglichkeiten, dies zu prüfen. Im weiteren hat der SP so gut wie keine Möglichkeit, die erhaltenen Attribute und Daten End to End zu validieren.

Multiple IDP

Das aktuelle Konzept setzt darauf, dass sowohl mehrere Firmen, als auch der Staat, als IDP auftreten können. Dies steigert das Risiko für Angriffe, da Angreifer gleich mehrere IDP kompromittieren können und den jeweils Schwächsten missbrauchen könnten. Es gilt das Prinzip des schwächsten Glieds in einer Kette.

Dabei spielen auch Schwachstellen in der Software oder den Protokollen eine Rolle. Jeder IDP kann eigene Schwachstellen aufweisen. Dadurch erhöht sich die Angriffsfläche auf die E-ID mit jedem zusätzlichen IDP.

Mögliche Mitigationen:

• Verzicht auf mehrere IDP
• Integration und Unit Testing des Source Codes
• SAST (Static Application Security Testing)
• Code Fuzzing
• End to End (User-Agent zum SP) Verifikation der Attribute

Brokering

Aktuell ist aus den Unterlagen nicht klar ersichtlich, ob das Konzept von Identity-Brokering zum Einsatz kommt. Dabei geht es darum, dass der SP dem Broker vertraut und dieser mehrere IDPs hinter sich bündelt. In dieser Konstellation ist es nahezu unmöglich, Privacy und Security zu kombinieren.

Ein Konzept mit einem Broker hat ein grundsätzliches Problem. Da ein Broker mehrere IDPs bündelt, hat der Broker Zugriff auf eine Vielzahl von Meta- und Nutzungsdaten. Dieser Umstand stellt den Broker als attraktives Ziel für Angriffe dar.

Mögliche Mitigationen:

• Verzicht auf einen Broker
• End to End (User-Agent zum SP) Verifikation der Attribute

Bemerkung: Der Verzicht auf einen Broker hätte zur Folge, das Privacy Konzepte wie Double Blinding²² nicht angewendet werden könnten. Allerdings ist dies schwer umzusetzen, wenn eine End-to-End-Verifikation der Attribute eingesetzt wird.

Verifikation der Identität

Ein weiteres Problem ist die Beantragung und Prüfung einer natürlichen oder juristischen Person als Halterin der E-ID.

Da die Verordnung noch nicht der Öffentlichkeit zugänglich ist, ist unklar, wie der Prozess der Verifikation aussieht.

Anmerken lässt sich jedoch, dass Personenkreise, welche über die nötigen Daten für eine Verifikation meiner Person verfügen, durchaus ein Risiko darstellen. Dazu könnten auch private Firmen zählen, wie zum Beispiel eine Krankenkasse.

Mögliche Mitigationen:

• Publikation der E-ID in eine Prüfliste analog zu Certificate Transparency²³
• Sicherstellung, dass eine Person nur exakt eine E-ID besitzt

Bemerkung: Angriffe auf die Verifikation können auch mit Social Engineering / Social Hacking o.ä angegangen werden.

Zeitstempel

Um sicherzustellen, dass eine Operation zu einer bestimmten Zeit vonstatten gegangen ist, muss in den entsprechenden Sicherheitsmerkmalen, Protokollen usw. ein Zeitstempel enthalten sein. Dieser Zeitstempel könnte durch technische Fehler oder Angriffe verfälscht werden. Dies erschwert die Nachvollziehbarkeit der Ausführungszeit einer bestimmten Aktion.

Mögliche Mitigationen:

• Signierte Zeitstempel
• Nutzung von konsensusbasierten Systemen

Bemerkung: Auch die Signierung von Zeitstempel hat Risiken, da die Zeitserver weiterhin angegriffen werden können oder falsche Zeitangaben halten können.

Eine Zusammenfassung des Problems

Das eigentliche Problem des aktuellen Konzeptes beruht darauf, dass sich die unterschiedlichen Parteien gegenseitig vertrauen müssen. Zudem gibt es mit dem vorgeschlagenen Konzept wenige bis keine Möglichkeiten, die erhaltenen Daten End-to-End auf deren Integrität, Vollständigkeit und Korrektheit zu prüfen. Dadurch entsteht ein Szenario, in welchem der Endnutzer das höchste Risiko trägt. Sollte ein Sicherheitsleck ausgenutzt werden, so sind es die Daten des Endnutzers, welche missbraucht werden.

Eine (sichere) Alternative

An dieser Stelle möchte ich die Idee von mutual TLS, also der Nutzung von Client Zertifikaten, beliebt machen.

Einer der Nachteile ist sicherlich die schlechtere User Experience. Aber unter Berücksichtigung der Anforderungen der Sicherheit gegen Impersonation, dem Datenschutz und der allgemeinen Sicherheit, scheint mir dies vernachlässigbar. In diesem Kontext hat der Schutz der Daten den höheren Stellenwert.

Mutual TLS, also die gegenseitige Authentifizierung, hat den grossen Vorteil, dass es fast alle Risiken, welche oben dargestellt werden, eliminiert und daher für diesen Einsatzzweck besser geeignet ist. Beim Einsatz von Mutual TLS als dezentrale Authentifizierung vom User-Agent zum Service Provider entstehen keine unnötigen zentralen Nutzungsdaten bei einem IDP — und reduzieren damit zahlreiche Angriffsvektoren, welche im Konzept zur E-ID vorhanden sind

Warum also nicht ein E-ID Konzept etablieren, in welchem der Staat, wie bereits heute, die Personen prüft — beispielsweise beim Ausstellen einer ID auf dem Passbüro.

In diesem Prozess könnte der Nutzer entweder ein Zertifikat erhalten — oder noch besser — mit einem Certificate Signing Request (CSR) seinen eigenen Schlüssel signieren lassen.

Diese Identität könnte eine Laufzeit analog zur ID Karte haben und immer gleichzeitig ersetzt werden.

Als Datenträger könnten die heute üblichen USB Sticks mit NFC dienen, welche von diversen Herstellern wie “solokey” oder “yubikey” angeboten werden.

Diese Datenträger würden die Nutzung an fast allen Geräten ermöglichen. Mobile per NFC und am PC / Notebook per USB. Estland verfolgt unter anderem diesen Ansatz, in Kombination mit den TPM Modulen der Geräte und SIM Karten²⁴. Dabei scheint das Modell erfolgreicher zu sein als bei anderen Nationen²⁵.

Im Gegensatz zum aktuellen Konzept kann man in diesem Verfahren auch eine Erkennung gegen Impersonation etablieren. Wenn alle Zertifikate, die von einer Person im Umlauf sind, publiziert werden (selbstverständlich nur hashed), kann jederzeit geprüft werden, ob ein Zertifikat für eine Person erstellt wurde (analog CT Prozess). Dies schützt zu einem gewissen Teil gegen die Impersonation von Personen, welche die Beglaubigung durchführen (Einwohnerkontrolle und Passbüro).

Bemerkungen: Auch wenn in diesem Prozess eine Certification Authority als Trust Anchor zum Einsatz kommt, so ist dies nicht verwerflich. Dieses Risiko besteht in jedem IDP. Allerding muss hierbei, im Gegensatz zu der zentralen Authentifizierung, diese CA nicht nahe am Internet sein und kann Offline verwahrt werden. Einzig Revocation-Meldungen (OCSP) und die Certificate Transparency (CT) Infos, müssen publiziert werden.

Um die Privacy noch weiter zu erhöhen, könnten die Attribute des Zertifikats als Hash gespeichert werden. So könnte der Benutzer sich beim SP anmelden, ohne dass seine Attribute transparent sind. Wenn der SP diese dann prüfen möchte, könnte er den Benutzer auffordern, die Attribute bei ihm (dem SP) einzugeben und diese dann zu hashen und mit dem Hash aus dem Zertifikat zu vergleichen. Weitere Möglichkeiten für die Sicherung der Attribute sind zu prüfen.

Schematische Darstellung der Unterschiede

Wie man den Grafiken entnehmen kann, besteht der Hauptunterschied der zwei Verfahren darin, dass beim mTLS keinen Man-in-the-middle gibt. Im Gegensatz dazu zeigt der Prozess mit einem (oder: mehreren) IDP auf, dass Daten beim IDP generiert werden, welche damit ein potentielles Angriffsziel darstellen.

Dies zeigt schlussendlich auch die Schwäche des Konzeptes der E-ID mit zentralen IDP deutlich auf.

Schema mit Mutual TLS

Eigene Darstellung: Mutual TLS

Prozess mit IDP

Eigene Darstellung: Identity Provider

Fazit

Soll die E-ID jemals für kritische Daten genutzt werden können — was vor dem Hintergrund der Digitalisierung von Rechtsgeschäften, Behördengängen und ähnlichen Anwendungsfällen der Fall sein wird, so bleibt bei genauer Betrachtung der in diesem Artikel formulierten Risiken nur die Option mit mTLS übrig.

Alle anderen Konzepte haben massgebliche Nachteile, welche das Risiko aller Beteiligten und insbesondere der Benutzer signifikant erhöhen. Aufgrund dessen, dass wenn etwas schiefgeht, es sich um (persönliche oder kritische) Daten des Benutzers handelt, sollte grossen Wert darauf gelegt werden, diese so zu schützen, dass die Risiken so gut wie möglich mitigiert werden können. Des Weiteren bringt die dezentrale Authentifizierung den Vorteil des “Privacy by Design” mit, was verhindert, dass unnötig Nutzungsdaten entstehen.

Dank an die Reviewer

An dieser Stelle möchte ich mich noch bei allen Personen herzlich für das Review bedanken. Ohne euch wäre es nicht möglich gewesen, einen fachlich korrekten Artikel zu schreiben, der ein sinnvolles Niveau, sowie eine sinnvolle Botschaft aufweist. Danke Vielmals!

Änderungsverlauf

27.01.21 Initiale Veröffentlichung

[1]: “Sec-Consult My name is Johann Wolfgang von Goethe — I can ….” 20 Nov. 2018, https://sec-consult.com/blog/detail/my-name-is-johann-wolfgang-von-goethe-i-can-prove-it/. Accessed 24 Jan. 2021.

[2]: “All That’s Needed To Hack Gmail And Rob Bitcoin: A … — Forbes.” 18 Sept. 2017, https://www.forbes.com/sites/thomasbrewster/2017/09/18/ss7-google-coinbase-bitcoin-hack/. Accessed 24 Jan. 2021.

[3]: An update on our security incident — Twitter Blog.” 18 Jul. 2020, https://blog.twitter.com/en_us/topics/company/2020/an-update-on-our-security-incident.html. Accessed 24 Jan. 2021.

[4]: “Phishing for OTP — Cyberint.” https://blog.cyberint.com/phishing-for-otp. Accessed 24 Jan. 2021.

[5]: “BCP 212 — OAuth 2.0 for Native Apps — IETF Tools.” https://tools.ietf.org/html/bcp212. Accessed 24 Jan. 2021.

[6]: ”Covert Redirect is not new but.. A risk analysis and … — .Nat Zone.” 8 May. 2014, https://nat.sakimura.org/2014/05/08/covert-redirect-is-not-new/. Accessed 24 Jan. 2021.

[7]: “Mix-Up, Revisited — danielfett.de.” https://danielfett.de/2020/05/04/mix-up-revisited/. Accessed 24 Jan. 2021.

[8]: “Critical vulnerabilities in JSON Web Token libraries — Auth0.” 21 Aug. 2020, https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/. Accessed 24 Jan. 2021.

[9]: “Common JWT security vulnerabilities and how to … — Connect2id.” https://connect2id.com/products/nimbus-jose-jwt/vulnerabilities. Accessed 24 Jan. 2021.

[10]: “OpenID Connect Security Considerations — Ruhr-Universität ….” 13 Jan. 2017, https://www.nds.ruhr-uni-bochum.de/media/ei/veroeffentlichungen/2017/01/13/OIDCSecurity_1.pdf. Accessed 24 Jan. 2021.

[11]: “XML Signature Validation Bypass in simpleSAMLphp and ….” 6 Nov. 2019, https://www.hackmanit.de/en/blog-en/82-xml-signature-validation-bypass-in-simplesamlphp-and-xmlseclibs. Accessed 24 Jan. 2021.

[12]: “OAuth 2.0 und OIDC — Angriffe und Gegenmassnahmen.” https://ba-pub.engineering.zhaw.ch/BA_WebPublication/Flyer.pdf?version=Bachelorarbeit2020&code=BA20_tebe_04&language=de. Accessed 25 Jan. 2021.

[13]: “RFC 8705 — OAuth 2.0 Mutual-TLS Client … — IETF Tools.” https://tools.ietf.org/html/rfc8705. Accessed 24 Jan. 2021.

[14]: “RFC 8471 — The Token Binding Protocol Version 1.0 — IETF Tools.” https://tools.ietf.org/html/rfc8471. Accessed 24 Jan. 2021.

[15]: “RFC 5246 — The Transport Layer Security (TLS … — IETF Tools.” https://tools.ietf.org/html/rfc5246. Accessed 24 Jan. 2021.

[16]: “Vergleich Authentisierung.” http://www.it-rm.ch/files/Technologie_Vergleich_1_2.pdf. Accessed 24 Jan. 2021.

[17]: “Feature: Token Binding — Chrome Platform Status.” 9 Nov. 2020, https://www.chromestatus.com/feature/5097603234529280. Accessed 24 Jan. 2021.

[18]: “Downgrade attack — Wikipedia.” https://en.wikipedia.org/wiki/Downgrade_attack. Accessed 25 Jan. 2021.

[19]: “Domain Name System Security Extensions — Wikipedia.” https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions. Accessed 25 Jan. 2021.

[20]: “DNS over HTTPS — Wikipedia.” https://en.wikipedia.org/wiki/DNS_over_HTTPS. Accessed 25 Jan. 2021.

[21]: “HSTS Preload List Submission.” https://hstspreload.org/. Accessed 24 Jan. 2021.

[22]: “eCH-0224 — Vermittlerbasierte Identity Federation ….” 5 Jun. 2020, https://www.ech.ch/de/dokument/0918729f-07b1-45fc-9e27-a1e87700c391. Accessed 25 Jan. 2021.

[23]: “Certificate Transparency.” https://www.certificate-transparency.org/. Accessed 24 Jan. 2021.

[24]: “E-identity, ID card — e-Estonia.” https://e-estonia.com/solutions/e-identity/id-card/. Accessed 24 Jan. 2021.

[25]: “Digital Government Factsheet Estonia — Joinup.eu — europa.eu.” 15 Mar. 2019, https://joinup.ec.europa.eu/sites/default/files/inline-files/Digital_Government_Factsheets_Estonia_2019.pdf. Accessed 25 Jan. 2021.

[26]: “Content Security Policy — OWASP Cheat Sheet Series.” https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html. Accessed 26 Jan. 2021.

[27]: “Cross-Site Request Forgery Prevention — OWASP Cheat Sheet ….” https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html. Accessed 26 Jan. 2021.

[28]: “HTTP Strict Transport Security — OWASP Cheat Sheet Series.” https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html. Accessed 26 Jan. 2021.