Password storage & Friends
Password-based authentication
• Tuttora e in futuro molto diffusa
• Pro:
Economica: facile da implementare, password facili
da distribuire e conservare
Livello di sicurezza dignitoso se password workflow
implementato correttamente
Password-based authentication - II
• Contro:
– Le implementazioni allo stato dell’arte sono rare
– Tutti i passaggi del password workflow sono
soggetti a possibili problemi di sicurezza
– Il fattore umano ha un impatto notevole
"Humans are incapable of securely storing high-quality cryptographic keys, and they
have unacceptable speed and accuracy when performing cryptographic operations.
They are also large, expensive to maintain, difficult to manage, and they pollute the
environment. It is astonishing that these devices continue to be manufactured and
deployed. But they are sufficiently pervasive that we must design our protocols
around their limitations. " -- Kaufman, Perlman, and Speciner quoted in Anderson's
"Security Engineering"
Password workflow
• Attori:
– Utente dotato di credenziali (UID + Pass)
– Servizio di varia natura (Web server, OS, etc.)
– Host utente, Host server, canale trasmissivo
• Workflow
–
–
–
–
–
Storage lato utente
Introduzione credenziali
Trasmissione
Validazione
Storage lato server
Storage lato utente
• Mentale
• Cartaceo
• Ausili digitali
Inserimento
• Keyloggers: hardware & software
– Attacchi solo mitigabili con metodi di inserimento
alternativo (e.g. keylogger beater)
– http://www.keylogger.org/
Trasmissione
• Svariati metodi di validazione senza
trasmissione della password disponibili
– Challenge based: HTTP digest, CHAP, MS-CHAPv2
• --- Vedi lezioni apposite ---
Scelta della password
• Lunga o corta?
• Comune o non comune?
• Singola o multipla?
Password Storage
• In genere i servers non memorizzano le passwords
reali, piuttosto ricavano un valore hash della
password, memorizzano questo valore ed eliminano
la password
• Il valore hash viene usato per verificare una
password tramite un modulo di login ma non è
possibile riconvertirlo nel valore testuale della
password
• Uso di hashing iterativo per rallentare il brute-forcing
• In molti casi resta possibile fare login usando l’hash…
Rainbow Tables
1.
2.
3.
•
Immaginiamo di avere un “dizionario” costituito, ad esempio, da
combinazioni alfanumeriche < 15 caratteri
Indicizziamo rispetto ai valori hash delle combinazioni a disposizione
Memorizziamo i risultati su un DVD
tutte le
A questo punto si hanno diverse centinaia di milioni di valori hash che si possono
riconvertire nei corrispondenti valori testuali – una “rainbow table”. Per usarla,
1.
2.
3.
Prendiamo la tabella di valori hashes di cui siamo venuti in possesso
Per ciascun valore hash h
Cerchiamo h nella rainbow table
•
Se c’è, lo abbiamo scoperto
Nessun moderno schema di
Password storage dovrebbe essere vulnerabile a questo tipo di attacco
Rainbow tables
• Si possono facilmente neutralizzare
• Per ogni password è sufficiente generare un numero random
(nonce)
• Calcolare il valore hash della password con il nonce, e
memorizzare sia il valore hash che il nonce
• Il server ha informazioni sufficienti per verificare le passwords
(il nonce è memorizzato in chiaro)
• Ma anche con un valore random piccolo, ad esempio 16 bits,
le rainbow tables non sono praticabili: ci sarebbero 65,536
“varianti” di ogni valore hash, e invece di 300 miliardi di
entries nella rainbow table ne servirebbero quadrilioni
• Il nonce in questo schema è detto “salt”
Programming Practise
• La maggior parte dei problemi di sicurezza delle industrie si è
verificato perchè gli sviluppatori hanno gestito il codice
relativo alla sicurezza nello stesso modo in cui hanno gestito il
resto del codice
• La differenza tra il codice relativo ai problemi di sicurezza è il
codice applicativo è che quando il secondo fallisce, è possibile
accorgersene subito, mentre quando fallisce il codice relativo
alla sicurezza, c’è il rischio di scoprirlo anche dopo anni*
*quando un DVD con tutte le informazioni riservate sulle carte di credito degli utenti e
CVV2 inizia a circolare in Estonia
Esempio
• “Salt” fai da te:
hash = md5('deliciously-salty-' + password)
• Ci sono almeno 2 problemi in questo pezzo di codice:
– Certamente, l’autore non sa cos’è un salt
– “deliciously-salty-” non è un nonce
Esempio
• Ma l’altro problema è l’utilizzo delle lettere “md5”
– Non solo perchè MD5 è “superato” e non è conveniente
come metodo generale per calcolare valori hash
– Ma soprattutto perchè la codifica MD5 avviene molto
velocemente (così come per SHA1 e SHA256)
• la velocità è un obiettivo di design per le tecniche di hashing sicuro
(…i valori hashes costituiscono i pilastri di qualsivoglia sistema di
crittografia…ma)
La velocità è esattamente ciò che non si vuole in una
funzione di codifica hash per una password!
Password crackers
• Gli schemi di password moderni sono attaccati con i password
crackers incrementali
– Questo approccio non pre-calcola tutte le possibili passwords cracked
– Considera ogni valore hash della password individualmente e riempie
il dizionario tramite la funzione hash per la password (così come
accadrebbe in una pagina di login)
• I rainbow table crackers (Ophcrack) usano la risorsa spazio
per attaccare le passwords.
• Gli incremental crackers (John the Ripper, Crack, LC5)
lavorano sfruttando la risorsa tempo (statistiche ed
elaborazioni)
Password attack game
• Il “punteggio” è calcolato in base al tempo impiegato per scoprire la
password
• Nel caso di rainbow tables, questo tempo dipende da quanto grande deve
essere la tabella e da quanto velocemente si riesce a navigarla
• Nel caso dei crackers incrementali, il tempo dipende da quanto
velocemente si può eseguire la funzione hash per la password (più
velocemente si può ottenere il valore hash per la password più debole
diventa lo schema)
– MD5 e SHA1 sono pensati per essere veloci, perciò MD5, SHA1 (e di
conseguenza DES) sono deboli come password hashes
– Sulle moderne CPUs il calcolo di DES e MD5 può essere ottimizzato
enormemente.
Usare direttamente funzioni hash per autenticare e memorizzare passwords
è una soluzione semplice ma debole tanto quanto quella di usare
funzioni hash senza salt, quindi è da evitare
Stato dell’arte
• Usare cosa il sistema operativo già offre: uno schema di password
storage “ottimizzato” per essere computazionalmente costoso.
– PHK’s FreeBSD MD5 scheme
– “stretching” = PHK applica MD5 per migliaia di iterazioni (su Linux e BSD)
• “Adaptive Hashing”
– Inventato da Neils Provos e David Mazieres per OpenBSD nel 1999
– Il loro schema originale è chiamato “bcrypt”
– 3 differenze rispetto allo schema PHK’s
• Bcrypt usa Blowfish invece di MD5. Blowfish è un algoritmo a blocchi che
richiede un tempo di setup molto elevato
• Provos e Mazieres lo hanno esteso in "Eksblowfish“ che prevede un tempo di
setup ancora più lungo (possibilità di specificare il numero di passate fatte con
Blowfish)
Vantaggi di bcrypt
Analizziamo il problema dalla prospettiva server e attacker
Server:
• Un server riceve migliaia di logins
all’ora. Rispetto ai tempi di database
hits, page refreshes e I/O, il tempo di
verifica della password è trascurabile
• Non importa se il test di verifica della
password richiede il doppio del
tempo o anche 10 volte tanto!
Attacker:
• L’attacker deve effettuare moltissimi
test della password
• Diventa importantissimo quindi il
tempo necessario per ciascun test!
Il più grande vantaggio dell’ adaptive hashing è che al crescere della
velocità di elaborazione delle macchine, lo stesso blocco di codice
continuerà a produrre passwords a loro volta più difficili da scoprire..
Progetto di password storage
• Tradeoff:
1.
Memorizzare il valore hash di una chiave
•
se si perde il database degli hash, comunque non sono state rese visibili le
password
Tuttavia non c’è modo di conoscere le password in chiaro, quindi per validarle,
l’utente deve trasmetterle in chiaro! (Sarebbe inutile comunque trasmettere
l’hash della password dal client al server)
L’autenticazione richiede di essere protetta a sua volta, e.g. con uno schema
Diffie-Helmann
•
•
2.
Usare uno schema di challenge-response:
•
•
da entrambi i lati si usa un problema matematico per dimostrare rispettivamente
che si è a conoscenza della password ma senza trasmettere la password in chiaro
sulla rete
Questi schemi funzionano a patto che entrambi gli interlocutori abbiano accesso
alla password in chiaro !
• Entrambi i tipi di attacco, database stealing e password
phishing/sniffing/stealing si possono verificare
– Il furto di database può mettere a repentaglio un intero DB di account
Authentication Protocols
•
•
•
•
PAP
CHAP & estensioni (MS-CHAP)
Kerberos
PEAP/EAP
– LEAP, EAP-TLS, EAP-MD5, EAP-PSK, EAP-TTLS, EAPIKEv2, EAP-FAST, EAP-SIM, EAP-AKA, EAP-GTC,
EAP-EKE, EAP-MSCHAPv2
• IKEv2
• HTTP – Digest
• …
Stanford Secure Remote Password protocol
• SRP è un sistema di cifratura a chiave pubblica
pensato per memorizzare in modo sicuro e validare
le passwords senza memorizzarle nè trasmetterle in
chiaro (risolve il problema del tradeoff…)
• Estensione del Diffie-Hellman
– Invece di memorizzare un password hash con salt si
memorizza un “verifier”, che è un numero elevato alla
potenza del valore hash della password modulo N
Stanford Secure Remote Password protocol
• È un protocollo di challenge-response che consente a un
server di dimostrare che l’utente è a conoscenza della
password senza che questa debba viaggiare sulla rete
• Non richiede la memorizzazione in chiaro, si memorizza
un verifier crittografato non reversibile
• Poter invertire gli SRP verifiers velocemente
significherebbe un avanzamento significativo delle
tecniche di crittografia
• SRP è sufficientemente semplice da poter funzionare su
un browser con Javascript.
Stanford Secure Remote Password protocol
• All’inizio si sceglie un numero primo sufficientemente grande, n
• Tutte le operazioni di addizione, moltiplicazione, elevamento a
potenza vengono implicitamente effettuate modulo n
n
g
s
P
x
v
u
a,b
A,B
H()
m,n
K
Un numero primo grande
Un generator
Una stringa random usata come user's salt
Password utente
Una chiave privata derivata da password e salt
Host's password verifier
Un parametro random pubblico
Chiavi private generate in modo random e non pubblicamente rivelate
Chiavi pubbliche corrispondenti
One-way hash function
Due stringhe concatenate
Session key
Steve prende un salt s e calcola:
x = H(s, P)
v = g^x
Steve memorizza v and s come Carol's password verifier e salt
1.
2.
Carol invia a Steve la sua username, (ad esempio carol)
Steve prende la entry corrispondente alla password di Carol, accede al verifier v e
al salt s. Invia s a Carol. Carol calcola la sua chiave privata di lungo termine x
usando s e la sua password reale P
Carol
1.
Steve
C -->
2.
x = H(s, P)
<-- s
3.
A = g^a
A -->
4.
<-- B, u
(lookup s, v)
B = v + g^b
5.
S = (B - g^x)^(a + ux)
S = (A · v^u)^b
6.
K = H(S)
K = H(S)
7.
M[1] = H(A, B, K)
M[1] -->
(verify M[1])
8.
(verify M[2])
<-- M[2]
M[2] = H(A, M[1], K)
3.
Carol genera un numero random a, 1 < a < n, calcola la sua chiave pubblica A = g^a,
e la invia a Steve.
Steve genera un suo numero random b, 1 < b < n, calcola la sua chiave pubblica B =
v + g^b, e la invia a Carol, insieme al paramemtro generato in modo random
u. Carol e Steve calcolano il loro valore esponenziale comune S = g^(ab + bux)
Se la password di Carol P corrisponde a quella che ha usato originariamente per
generare v, entrambi I valori S saranno uguali
4.
5.
Carol
1.
Steve
C -->
2.
x = H(s, P)
<-- s
3.
A = g^a
A -->
4.
<-- B, u
(lookup s, v)
B = v + g^b
5.
S = (B - g^x)^(a + ux)
S = (A · v^u)^b
6.
K = H(S)
K = H(S)
7.
M[1] = H(A, B, K)
M[1] -->
(verify M[1])
8.
(verify M[2])
<-- M[2]
M[2] = H(A, M[1], K)
6.
7.
Ad entrambi i lati si calcola lo stesso esponenziale S e la chiave K.
Carol invia a Steve M[1] come dimostrazione del fatto che possiede una session
key. Steve calcola M[1] e verifica che corrisponde a quello inviatogli da Carol.
Steve invia a Carol M[2] come prova del fatto che possiede la session key corretta.
Carol verifica a sua volta M[2] accettandola solo se corrisponde al valore di Steve.
8.
Carol
1.
Steve
C -->
2.
x = H(s, P)
<-- s
3.
A = g^a
A -->
4.
<-- B, u
(lookup s, v)
B = v + g^b
5.
S = (B - g^x)^(a + ux)
S = (A · v^u)^b
6.
K = H(S)
K = H(S)
7.
M[1] = H(A, B, K)
M[1] -->
(verify M[1])
8.
(verify M[2])
<-- M[2]
M[2] = H(A, M[1], K)
Rubare il file delle pw con SRP consente un
costoso attacco a dizionario
• x = H(s, P)
v = g^x
• I valori memorizzati sono v e s
• Per trovare P, dovrei impostare un enorme
attacco di forza bruta:
– Calcolo x’ a partire da P’ e s: verifico che v = g^x’
Cosa manca a SRP per funzionare via
Web?
• SRP è solo da poco rilasciato con licenza simil-BSD
• Per farlo funzionare in modo sicuro su un browser è
necessario far comunque riempire la pagina di login via SSL
– Altrimenti il sistema è vulnerabile a facili attacchi di phishing
– Ne risulta uno schema che può essere colpito da chiunque possa
compromettere una pagina web
MS-CHAP v2 protocol
• Microsoft
Protocol
Challenge-Handshake
Authentication
• In MS-CHAP il processo di autenticazione è
reciproco, il client e il server si presentano e il
server deve dimostrare al client che è in grado
di accedere al database dove è contenuta la
password dell'utente che sta tentando la
connessione
MS-CHAP v2 protocol
0. Il server conserva delle coppie <uid,NTLM hash>
1. Client requests a login challenge from the Server.
2. The Server sends back a 16-byte random challenge (RC).
3a. The Client generates a random 16-byte number, called the Peer Authenticator
Challenge (PAC)
3b. The Client generates an 8-byte challenge (CH) by hashing RC received in step (2), the
16-byte PAC generated in step (3a), and the Client's username. (See Section 3 for
details.) CH = SHA1(RC + PAC + UID).
3c. The Client creates a 24-byte reply (REP), using the Windows NT hash function
and the 8-byte challenge generated in step (3b): REP = DES(X, C) +DES(Y,C) + DES(Z, C).
X | Y | Z = NTLM Hash (16 byte + 5 byte nulli).
3d. The Client sends the Server the results of steps (3a) and (3c).
4a. The Server uses the hashes of the Client's password, stored in a database,
to decrypt the replies. If the decrypted blocks match the challenge, the
Client is authenticated.
MS-CHAPv2 - II
4b. The Server uses the 16-byte Peer Authenticator Challenge from the client,
as well as the Client's hashed password, to create a 20-byte Authenticator
Response."
5. The Client also computes the Authenticator Response. If the computed
response matches the received response, the Server is authenticated.
MPPE Key derivation
• MK = SHA1(NT password hash + RE + “This is
the MPPE Master Key"). Truncate to get a 16byte master-master key.
• Derive two session keys:
Hash the master-master key, 40 bytes of 0x00, an 84-byte
constant and 40 bytes of 0xF2 with SHA. Truncate to get a 16byte output.
Constants: «Magic server to client constant», «Pad to make it
do more than one iteration», «session key to client-to-server
signing key magic constant»,
MS-CHAP v2 protocol
0. Il server conserva delle coppie <uid,NTLM hash>
1. Il client richiede un authenticator challenge al server
2.
3.
Il server invia un random authenticator challenge di 16-bytes (SC)
Il client genera la risposta:
a)
b)
c)
d)
e)
f)
genera un random peer challenge di 16-bytes (PC)
genera il challenge calcolando l’hash dell’authenticator challenge, del peer
challenge, e della user's login con SHA
genera l’hash NTLM H della password dell’utente (16 byte)
H è riempito con 5 bytes di zero. Dai risultanti 21 bytes si ottengono 3 chiavi
DES di 7-byte
i primi 8 bytes dell’hash generato in (b) sono cifrati con DES con ciascuna delle
chiavi generate in (d)
i 24 bytes risultanti da (e), i 16-byte random peer challenge, e la user's login
sono inviate al server come risposta
MS-CHAP v2 protocol
4.
5.
Il server decifra la risposta con la password hashed del client che è
memorizzata in un database
Se questo valore corrisponde al challenge, il server invia una risposta di
autenticazione positiva
a)
b)
c)
6.
Il server calcola un valora SHA-1 ottenuto da Hash(H) e il letterale costante
“Magic server to client signing constant“
Il server genera un altro valore hash usando SHA dall’output di 20-byte del
passo 5.a), il challenge di 8-byte (passo 3 (b)), e una costante “Pad to make it
do more than one iteration“
I risultanti 20 bytes sono inviati al client nella forma “S=<hupper-case ASCII
representation of the byte values>“
Il client usa la stessa procedura per produrre i 20 bytes e li confronta alla
servers authenticator response. Se c’è corrispondenza client e server sono
reciprocamente autenticati