| OpenID Connect (CHAP Beispiel) | > Authentifizierung und Identitätsmanagement für Web-SSO
> Basiert auf OAuth2.0
> Nutzer kann selbst verschiedene Dienste mit den selben Zugangsdaten nutzen
> Dritte Party (OpenID Provider zB Google)
> Andere Websites erhalten keinen Zugriff auf Zugangsdaten |
| Mehrfaktor-Authentifizierung | Kombination verschiedener Authentifierungsverfahren |
| Einseitige Authentifizierung | Eine Partei identifiziert sich über einer anderen
zB
Nutzer gegenüber PC
www Server gegenüber Nutzer |
| Wechselseitige Authentifizierung | zwei Parteien authetifizieren sich gegenseitig
ZB
Online Banking |
| Autorisation | Festlegung und Überprüfung von Berechtigungen basierend auf einer Policy |
| Zugriffskontrolle | - Sicherheitsfunktion die den Zugriff auf konkrete Ressourcen kontrolliert
- "Implementierung der Authorisation"
Zusätzlich
- Dokumentation des Umfangs der Nutzung eines Dienstes
- Authentifikation, Authorisation, Accounting (AAA)
- Zugriffe auf Netzwerke über Protokolle |
| Authentifikation durch Wissen: Passwörter | Speicherung als Hashwert
Shadowpasswörter (Salt)
Probleme:
- "schwach" Passwörter
- wiederverwendete Passwörter
- manche Unix-Tools übertragen PW im Klartext
- Authentifikationsverfahren ohne Übertragung des PW |
| Passwort Hashing | Alternative zur SHA Familie für Passwörter
- Bcrypt, Aragon2, PBDKF
- Variablen steuern Laufzeit und Resourcenverbrauch
- sind langsamer als SHA
- 100 ms länger bei login stört nicht
> braucht deutlich länger zu knacken |
| Challange Response Verfahren (Authentfizierung durch Wissen) | Authentifizierung eines Subsjekts gegenüber einer Instantz
- Subjekt (zB Mensch, Gerät, Dienst)
- Instanz (zB Server, Gerät, Dienst, Mensch)
Idee: Authentizitätsnachweis bei jedem Login
- Subjekt gibt seine Identität an (zB MAC-Adresse)
- Instanz sendet eine Challange (zB Zufallszahl) zum Subjekt
> Meist einmal verwendete Zufallszahl (RAND) oder Zählerwert: NONCE (Number used ONCE)
- Subjekt berechnet Respons (zB mittels Verschlüsselung)
- Instanz prüft Response, falls korrekt, dann hat das Subjekt geheimes Wissen (Schlüssel) nachgewiesen |
| Symmetrisches Challenge Respons Verfahren | > Vorab vereinbaren beide Parteien einen gemeinsamen Schlüssel k_AB
> Subjekt A authentifiziert sich gegenüber Instanz B
Problem:
- Klartextraum für Challanges Nounce muss groß sein
> Ansonsten hört Angreifer alle Nachrichten NOUNCE und c ab und speichert sie
> Angreifer kann somit wiederverwendete Challanges richtig beantworten
- Verwendete Chiffre muss sicher gegenüber Known-Plaintext-Angriffe sein
- Man in the middel und Replay Angriff?? |
| Asymmetrisches Challenge Respons Verfahren | > Schlüsselpaare eines asymmetrischen Schlüsselpaares sk und pk |
| One Time Password (OTP) (Authentifizreung durch Wissen) | - Passwörter sind nur ein einziges Mal gültig
- S/Key-Verfahren
- Anwendung Login:
> Beibehalten des "normalen" Passworts-Logins
> Bei entfernten Login Nutzung eines S/Key-Verfahren
> Prüfer muss passwort nicht kennen
> weil PW eine Verkettung von Hashwerten ist |
| Einmal Passworte (Time based One Time Passwords TOTP) | Idee:
Passwort berechnet sich durch einen HMAC über die aktuelle Uhrzeit
- (verwendet von Dropbox und Google Authenticator) |
| HMAC-based OTP (HOTP) | Idee:
Passwort berechnet sich durch einen HMAC über einen Zählerwert
> (benötigt sym. Schlüssel zwischen Sender und Empfänger)
> (verwendet von google Authenticator) |
| S/Key-Verfahren | - Benutzer: besitzt geheimes Benutzerpasswort s
- Localer PC: kennt auch s
- Entfernter Server: kennt s nicht
1. OTP-Berechnung, Initiierung
> berechnung von OTP p mithilfe einer krypt. Hashfunktion aus s
> wahl der Anzahl der PW N und eines Seed-Wertes k
> Berechnung p = H(s/k), jeweils
> Übertragung von Nutzerkennung und startwerten p, N, k an Login-Server
2. Nutzung
> Hashkette entgegengesetzt zur Erzeugung genutzt
> Server kennt p_N, N, k
> PC brechnet p_N-1 = H^N-1(S/K)
> Server vergleicht Ergebnisse
SICHERHEIT: Angreifer kennt p_i und möchte p_i-1 berechnen
Angreifer müsste p_i-1 = H^-1(p_i) berechnen, was nicht geht |
| S/Key-Verfahren (Angriffe) | SICHERHEIT: Angreifer kennt p_i und möchte p_i-1 berechnen
Angreifer müsste p_i-1 = H^-1(p_i) berechnen, was nicht geht
- Man in the middel Angriffe möglich
1> Servermaskierung
>> Angreifer maskiert sich als Server und schickt Client SeqenzNR j << i
>> falls Server nicht ggü. Client authentifiziert werden muss, antwortet Client mit p_j
>> Angreifer berechnet Einmalpassworte
2> Abfangen von p_i
>> Abfangen von p_i und hindert, dass Server dieses empfängt
>> Server bricht Authentifizierung ab
>> Angreifer kann unverbrauchtes p_i verwenden, um sich als Client auszugeben
>> Schutz: Server zählt counter auch bei abgebrochener Authetifizierung hoch
>> Wie Prüft Server bei der nächsten Authetifizierung den Wert |
| Authentifizierung durch Besitz | - Zusätzliche Kosten
- kann verloren gehen/gestohlen werden
- kann weiter gegeben werden
- Speichert Nutzerdaten
- spezielle Gegenmaßnahme gegen Angreifer |
| ID-Token (Authentifizierung durch besitz) | Hardware-basierte OTP-Verfahren: ID-Token
> OTP-Verfahren zur Authentifizierung beim Server
> Benutzer erhält Hardwaretoken
> Token besitzt eindeutige Nummer
> Server kennt diese Nummer |
| FIDO (Fast Identity Online) Alliance (Authenzifizierung durch Besitz) | - Industriestandarts zur Authentifizierung im Internet
> Zweifaktorauthetifizierung bzw. Ersatz für Passwörter
> Schutz gegen MITM und Phishing-Angriffe |
| FIDO U2F (Fast Identity Online, Universal 2nd Factor) | Ansatz:
- Für jeden Dienstag wird ein asymmetrisches Schlüsselpaar erzeugt
> privater Schlüssel bleibt auf Hardwaretoken gespeichert
> öffentlicher Schlüssel wird an den Server des Dienstes übertragen
- Nutzer Authentifiziert sich zunächst mit BName und Passwort
- Nutzer muss einen Knopf betätigen
- Einsatz eines Challange-Response-Verfahrens zur Nutzerauthentifizierung
Erschwert MITM Angriffe und Phishing
Integration von manip. rest. Secure Elements (SE) im Token schützt den private Key |
| FIDO2 (Fast Identity Online) | Kombiniert CTAP und WebAuthn
- Server (Relying Party) speichert öffentliche Schlüssel der Nutzer
- privater Schlüssel im Authenticator gespeichert
- Authentification mittels Challange-Response
> Nachweis der Kenntnis des privaten Schlüssels
- Nutzer führt eine Authorization Gesture aus |
| FIDO2 Passkeys | - FIDO2-Schlüsselpaar
> CTAB und WebAuthn Level 3
> Nutzung Analog zu FIDO2
- Backup und Sync. von Passkeys über Cloud möglich
- keine verpflichtende Nutzung von Hardwaretokens
- Benutzerfreundlich
> Integriert in Smartphone
> Gesichtserkennung, Fingerabdruck, Pin
Speicherung von Passkeys
- Roaming Authenticators
- Platform Authenticators |
| Arten von FIDO2 Passkeys | Multi-Device
> Backup und Synchronisation über versch. Geräte via Cloud Dienst
> keine Notwendigkeit jedes Gerät neu zu registrieren
Singe Device
> Privater Schlüssel ist fest an ein Gerät gebunden
> Für Geräte mit hohen Sicherheitsanforderungen
Cross-Ecosystem-Authetifizierung
> keine direkte Synchronisation über Ökosystem-Grenzen
> Nutzung Roaming-Authenticator |
| Authentifizierung durch Merkmal - Biometrie | Vorgehen bei bionmetrischer Authentifizierung
> Registrierung d. Nutzers (Enrolment)
>> Messdatenerfassung durch biometrischen Sensor
>> Aufnahme, Auswahl und Speicherung von Referenzdaten
> Authentifizierung
>> Erfassung der aktuellen Verifikationsdaten (mit Sensoren)
>> Verfikationsdaten digitalisieren (ggf normieren)
>> Vergleich mit Referenzwert
>> ggf zusätzlich Erkennungsanalyse von Angriffen oder Fälschungen |
| Verifikation durch Biom. Daten | - ist immer Fehlerbehaftet
- False Positiv (unberechtigter Zugriff FAR)
> Sicherheitsproblem!
- false Negativ (Berechtigter wird Abgewiesen FRR)
> Problem bei Benutzbarkeit
- FRR und FAR können durch mehr Merkmale gemindert werden
- Equal Error Rate (EER)
- Meist ungeprüfte Herstellerangaben |
| Angriffe auf Biometrische Authentifikation | - Bspw. Abnehmen des Fingerabdrucks
- Foto bei Gesichtserkennung reicht aus
DeepMasterPrints
- KI generiert quasi-Univeralschlüssel - Fingerabdrücke |
| PRO Biometrische Authentifikatin - was spricht dafür? | Pro
- Einfache Benutzung
- Ausfallsicher
- kein Verlust möglich
- kein Vergessen von PINs, Passwörtern etc. möglich
- Steigerung der Sicherheit
- Zusätzlicher Authentifizierungsfaktor
- Delegation nur schwer möglich |
| CONTRA Biometrische Authentifikatin - was spricht dagegen? | Contra
- je stärker, desto komplexer umzusetzen
- unscharfes Ergebnis
- schwellwerte notwendig
- leicht Angriffsmöglichkeiten bei schwacher Umsetzung
- Enge Kopplung zwischen Merkmal und Person
- Bedrohung der Informationellen Selbstbestimmung
- Gefahren durch gewaltsame Angriffe gegen Personen
- Unveränderlichkeit
- Problem der Öffentlichkeit der Daten und rechtliche Aspekte |
| Anforderungen an Authentifizierungsprotokolle | - wechselseitige Authentifizierung der Partner
- Schlüsselaustausch für vertrauliche und integere Datenübertragung
- in verteilten Umgebungen oft Singe Sign-On (SSO) |
| Needham-Schroeder-Protokoll | - Authentifizierungsprotokoll
- Basis ist vertrauenswürdiger Authentifizierungsserver AS
- AS: Authentifizierung und Schlüsselverteilung
- Pre-Shared Keys: jeder Client A hat einen gemeinsamen Master Key K_A mit AS vereinbart
- Weiterentwicklung im Kerberos-Protokoll
- Ebenfalls eine asymmetrische Variante vorhanden |
| Single Sign-On (SSO) | Ziel:
- Benutzer authentifiziert sich einmal (zentral)
- keine seperate Authentifizierung bei Dienstleistungen mehr erforderlich
Ansätze:
- Kerberosbasiert
- Smartcard-basiert
- Security Assertion Markup Language (SAML) |
| Kerberos | Ziel:
- Authentifikation von Subjekten, genannt Principals: u.a. Benutzer, PC/Laptop Server
- Austausch von Sitzungs-Schlüsseln für Prinzipals basierend auf Needham-Schroeder
- Single-Sign-On (SSO) für Dienste in einer administrativen Domäne (realm) |
| Single Sign On Konzept | Ziel:
> Benutzer authentifiziert sich einmal (zentral)
> keine seperate Authentifikation bei Dienstleistungen mehr erforderlich |
| Design von Kerberos : | > Pro Domäne ein Vertrauenswürdiger Server
Aufgabe:
> Authentifizierung der Clients (Prinzipals) seiner Domäne
> Ausstellen von Tickets als Identitätsausweise |
| Authentifizierung eines Prinzipals | Basis:
- Pre-Shared Secrets zwischen KDC und Prinzipal
> Prinzipal ist Benutzer: gehashtes Benutzerpasswort, daraus abgeleiteter Master-Key K_A
> Prinzipal ist Server: KDC kennt gemeinsamen Master-Key K_S |
| Inhalt eines Kerberos Tickets | T_C,S =
S, (Name des Servers)
C, (Name des Clienten)
adrr, (IP Adresse des Clienten)
timestamp, (aktuelle Zeit)
lifetime, (Lebenszeit des Tickets)
K_C,S = Sitzungsschlüssel für Kommunikation zw. S und C |
| Authentifizierungsprotokolle - PAP | Password Authentification Protocol
> Verwendet Point-to-Point Protocol (PPP)
> OSI-Model Schicht2
> Passwort-basierte Authentifizierung
- Problem: Unverschlüsselte Übertragung von Kennung und Passworten |
| OAuth2.0 Autorisation Framework (PAP Beispiel) | > Autorisierungs- und Datenaustauschprozess
> Temporäre Freigabe von eigenen (ausgewählten) Ressourcen eines Webdienstes an Dritte
> Nutzer können Dritte autorisieren ohne ihre Zugangsdaten weiterzugeben |
| Authentifizierungsprotokolle - CHAP | Challenge Handshake Authentifizierung Protocol
> Symmetrische Challange-Response
> Standard: MD5-MAC, Aushandlung anderer Verfahren möglich
> Client und Server teilen ein Geheimnis (Passwort)
Probleme:
> Verwendung von MD5, nur einseitige Authentifizierung, Wörterbuchangriff
> Varianten MS-CHAP und MS-CHAPv2 ebenfalls unsicher |
| OpenID Connect (CHAP Beispiel) | > Authentifizierung und Identitätsmanagement für Web-SSO
> Basiert auf OAuth2.0
> Nutzer kann selbst verschiedene Dienste mit den selben Zugangsdaten nutzen
> Dritte Party (OpenID Provider zB Google)
> Andere Websites erhalten keinen Zugriff auf Zugangsdaten |
| Wer Authentifiziert sich? | - Mensch an Gerät
- Maschine zu Maschine
- Gerät/Dienst zu Dienst/Gerät |
