Please enable JavaScript.
Coggle requires JavaScript to display documents.
2.2 Benutzerauthentisierung (RADIUS Remote Authentication Dial In User…
2.2 Benutzerauthentisierung
Passwörter
OTP
One Time Password
Server speichert immer nur das letzte PW
Client legt fest
Anzahl an Anmeldungen (n)
Seed s
Passwort P
mit einer
sicheren Hashfunktion
wird das Passwort mit dem seed n mal interiert
sichere Hashfunktion ist nicht umkehrbar!
seed ermöglicht selbes Passwort bei unterschiedlichen Servern, denn mit einem anderen Seed entstehen bei gleicher hashfunktion immer andere Folgen
Server vergleicht dann OTP mit zuletzt gespeichertem Passwort nachdem er es durch die Hashfunktion gelassen hat, die beiden Werte sollten dann identisch sein
Man-in-the-Middle-Attack
Angreifer gibt sich als server aus, greift somit echtes Anmeldepaar ab. Damit kann er sich dem Server als Client ausgeben
KERBEROS
KDS
Key Distribution Center
Client stellt Anfrage (Client ID, Server-ID, t1)
KDS antwortet
Ec (SessionKey), t1 und Es(ticket)
= (SK, C-ID, valid from ..to ...)
Client schickt
Authenticator
Esk(timestamp) ü Es(ticket) an Server
Server decrypt ticket, hat jetzt auch SK -> decrypt Authenticator, check if valid - fertig.
:warning: Passwort muss bei jeder Antwort vom KDS (neues ticket) angegeben werden. Häufiges eingeben des PW erhöht dessen ausspähung :warning:
wobei Ec() = encrypted mit client key
Es() = encrypted with server key
TGS
Ticket Granting Server
Video
Das Ticket kommt nicht vom KDS, sondern vom TGS
Anfrage ähnlich wie vorher (C-ID, TGS-ID, t1)
Dieser antwortet jetzt mit SK, t1 und TGT = Ticket-Granting-Ticket
Der Client beantragt beim TGS nun ein Ticket für den Server mit dem er sich eigentlich verbinden möchte (S-ID, t2, TGT). Mit dem TGT authentifiziert sich der client gegenüber dem TGS
TGS erstellt ticket für Server und neuen SessionKey SK
Esk(SK
, t2, ticket)
Mit dem erhaltenen Ticket authentifiziert sich der Client dann beim Server den er ansprechen will Esk'(t3), Es(ticket)
Vorteil
Passwort muss nur einmal pro Tag eingegeben werden
Bei erfolgreichen Angriff Kontrolle nur für einen Tag erlangt
biometrisch
Identifikation = one-to-many
Verfikation = one-to-one-matching
kriterien biometrischer Merkmale
Einduetigkeit
Erfassbarkeit
Fälschbarkeit
automat. auswertung
zeitliche Konstanz
Verfügbarkeit (z.B. keine Finger mehr)
Benutzerakzeptanz (Fingerabdruck -> Verberecher)
Sicherheit
FRR (False Rejection Rate)
FAR (False Acceptance-Rate)
RADIUS
Remote Authentication Dial In User Service
Ablauf
Benutzer wählt sich über RADIUS Client ein
Radius Client gleicht Informationen Mit Radius Server ab
Radius server antwortet und gibt zusätzlich noch Konfiguartionsinfos mit
Kommunikation über IP-Netz
UDP Transportprotokoll
Paketaufbau
Code (Accept, Reject, Request)
Identifier
länge des Pakets
Authenticator
16B zufallszahl
Attribute
Benutzerkennung werden verschlüsselt als Attribute übertragen
Passwort auf x*16 mit 0en auffüllen = p
zerlege p in 16B große Teile
3.verkette nun alles folgendermaßen
c1 = p1 xor MD5-Hash(S | RA)
c2 = p2 xor MD5-Hash(S | c1) usw...
Konkateniere alle c1 ... cn -> zu einerm Wert der dann übertragen wird
Benutzerpasswort p
Pre-Shared Secret S
Request Authenticator RA
Challenge-Response-Protocols
z.B. TAN-Verfahren
mit symmetrischer Verschlüsselung
Client schickt Authentisierungsanfrage
Server erzeugt Zufallszahl z und verschlüsselt diese mit gemeinsamen Geheimnis
Client entschlüsselt z und verändert auf vereinbarte weise -> z'
Client verschlüsselt z' und schickt an Server zurück
Server überprüft diese Antwort
assymetrische verschlüssel (2keys)
Client schickt authentisierungsanfrage
Server schickt mit public Client Key Verschlüsselte Zufalszahl z als Challenge zurück
Client entschlüsslet mit priv Key und erhält z
4.1 Client antwortet mit z
oder
4.2 Client verschlüsselt seine Antwort mit z
Server vergleicht ob Nachricht z ist oder ob mit z entschlüsselte Nachricht sinnvoll ist
Gefahr wenn Client, Challenge nur signieren würde
Ein Angreifer könnte den Client dazu bringen jedes Dokument zu signieren
angreifer schickt gehashtes Dokument als Challenge an Client
Client kann Dokument von einer wirklichen Challenge nicht unterscheiden, da Hashfunktionen gut streuen
LÖSUNG
:
Client signiert nie nur die Challenge sondern nimmt noch einen weiteren Wert dazu z.B. timestamp (konkatenierter string = hashwert d. challenge + timestamp)
zur Überprüfung bekommt der Server vom Client den konkatenierten string und die digitale Signatur
