Password storage & Friends

Password-based authentication

• Tuttora e in futuro molto diffusa• Pro:

Economica: facile da implementare, password facili da distribuire e conservareLivello 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. Immaginiamo di avere un “dizionario” costituito, ad esempio, da tutte le combinazioni alfanumeriche < 15 caratteri

2. Indicizziamo rispetto ai valori hash delle combinazioni a disposizione3. Memorizziamo i risultati su un DVD

• 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. Prendiamo la tabella di valori hashes di cui siamo venuti in possesso2. Per ciascun valore hash h3. 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 unafunzione 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, EAP-

IKEv2, 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 Un numero primo grandeg Un generator s Una stringa random usata come user's salt P Password utente x Una chiave privata derivata da password e salt v Host's password verifier u Un parametro random pubblico a,b Chiavi private generate in modo random e non pubblicamente rivelateA,B Chiavi pubbliche corrispondentiH() One-way hash function m,n Due stringhe concatenateK Session key

Carol Steve 1. C --> (lookup s, v) 2. x = H(s, P) <-- s 3. A = g^a A --> 4. <-- B, u 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)

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. Carol invia a Steve la sua username, (ad esempio carol)2. 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 Steve 1. C --> (lookup s, v) 2. x = H(s, P) <-- s 3. A = g^a A --> 4. <-- B, u 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.

4. 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)

5. Se la password di Carol P corrisponde a quella che ha usato originariamente per generare v, entrambi I valori S saranno uguali

Carol Steve 1. C --> (lookup s, v) 2. x = H(s, P) <-- s 3. A = g^a A --> 4. <-- B, u 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. Ad entrambi i lati si calcola lo stesso esponenziale S e la chiave K.7. 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.8. 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.

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 Challenge-Handshake Authentication Protocol

• 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

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 functionand 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, theClient is authenticated.

MS-CHAP v2 protocol

MS-CHAPv2 - II4b. 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 AuthenticatorResponse." 5. The Client also computes the Authenticator Response. If the computedresponse 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 16-byte 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 16-byte 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»,

0. Il server conserva delle coppie <uid,NTLM hash>

1. Il client richiede un authenticator challenge al server2. Il server invia un random authenticator challenge di 16-bytes (SC)3. Il client genera la risposta:

a) genera un random peer challenge di 16-bytes (PC)b) genera il challenge calcolando l’hash dell’authenticator challenge, del peer

challenge, e della user's login con SHAc) genera l’hash NTLM H della password dell’utente (16 byte)d) H è riempito con 5 bytes di zero. Dai risultanti 21 bytes si ottengono 3 chiavi

DES di 7-byte e) i primi 8 bytes dell’hash generato in (b) sono cifrati con DES con ciascuna delle

chiavi generate in (d) f) 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. Il server decifra la risposta con la password hashed del client che è memorizzata in un database

5. Se questo valore corrisponde al challenge, il server invia una risposta di autenticazione positiva

a) Il server calcola un valora SHA-1 ottenuto da Hash(H) e il letterale costante “Magic server to client signing constant“

b) 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“

c) I risultanti 20 bytes sono inviati al client nella forma “S=<hupper-case ASCII representation of the byte values>“

6. 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

MS-CHAP v2 protocol