3 Flashcards
def authN e schema authN
authN factors
generic authN protocol e problemi generali
password based authN
pwd sniffing, MITM, pwd captured via server spoofing o phishing, pwd duplication, attacchi contro db, crypto function invecchiate, pwd guessing offline, pwd enumeration (main usare dictionary words)
dictionary attack
rainbow table
salt
{id,salt,salted hash} , permette di usare stessa pwd su più server
strong authN
no formal definition, ce ne sono varie, mfa con authenticator indipendenti e diversi, tecnica è strong/weak in base a threat a cui deve resistere
challenge-response authN
f non invertivile , challenge deve essere nonce
symmetric cra
problema pwd storata in chiaro a verifier ->scram (channel binding e mutual authN)
mutual symmetric CRA e relativo attacco
gsm
A3 authN , A5 stream cypher, A8 per generazione chiave di sessione -> debole funzione comp128 (clonabile sim)
asymm cra
implementa peer authN,verifier non stora nessun segreto, lento (pki issues), problema integrità chiavi pubbliche
otp
come vengono generate? (device lento/insicuro vs veloce/sicuro)
s/key system
mitm possibile , server authN
generazione pwds s/key
totp
devono essere sincronizzati, tempo diviso in slot (perchè?) , una run per slot, vengono considerati anche t+1 e t-1, attacchi di desincronizzazione (fake ntp, femtocell)
rsa secure id
es totp, 2 fattori (knowledge e ownership)
2 modi (con o senza tastierino)
eotp
più run possibili in poco tempo, vengono considerati anche c+1,c+2, potrei aver premuto inavvertitamente il bottone
precomputazione possibile a client e server (non me lo devo portare dietro)
ootp
push over tls meglio di sms(voip), devo comunque comunicare pwd (no authN factor)
authn of humain being
tecniche biometriche e problemi
kerberos
basato su ttp (truste 3rd party), usato per non http, pwd mai trasmessa, client authN obbligatoria, server opzionale
ticket usati per autenticare un client a un server, encryptati con la chiave del target server, bound to ip address of client
kerberos funzioni di versioni recenti
extended ticket timelife, inter realm-authN, , ticket forwardable e extensibili, algo flexibility, pre-authN per evitare pwd enumeration e dictionary atk,as_req con pk crypto
sso
unica autenticazione x accedere a + servizi o sistemi , fictious/integral sso
oath
hotp hmac-otp nasato su counter o tempo, obiettivo è interoperability tra più sistemi di autentivazione
fido
make the user experience in authN simple
biometric authN (no pwd), 2-factor authN
biometric mai lascia user device (privacy)
asymm challenge
fido registration
no x.509 cert
fido login
fido security
solo x quella sfida solo x quel sito, new key pair every registration (no likability among different services usati da user), no phishing because authN response can’t be reused: (it’s a signature over various data, including the RP identity),there is no limit because private keys are not stored in the
authenticator but recomputed as needed based on an
internal secret and RP identity
fido 2.0
roaming authenticator
