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) –

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 disposizione 3.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 possesso 2.Per ciascun valore hash h 3.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, 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 grande g 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 rivelate A,B Chiavi pubbliche corrispondenti H() One-way hash function m,n Due stringhe concatenate K Session key

CarolSteve 1.C -->(lookup s, v) 2.x = H(s, P)<-- s 3.A = g^aA --> 4.<-- B, uB = v + g^b 5.S = (B - g^x)^(a + ux)S = (A · v^u)^b 6.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

CarolSteve 1.C -->(lookup s, v) 2.x = H(s, P)<-- s 3.A = g^aA --> 4.<-- B, uB = v + g^b 5.S = (B - g^x)^(a + ux)S = (A · v^u)^b 6.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

CarolSteve 1.C -->(lookup s, v) 2.x = H(s, P)<-- s 3.A = g^aA --> 4.<-- B, uB = v + g^b 5.S = (B - g^x)^(a + ux)S = (A · v^u)^b 6.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 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-CHAP v2 protocol

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 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 1.I l client richiede un authenticator challenge al server 2.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 SHA c)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= “ 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

Weaknesses Generazione del challenge di 8-byte – Non è scontato nè documentato come.. – È derivato da informazione inviata in chiaro, quindi può essere calcolata da un intruso – Può essere calcolata da un potenziale impostore – Quando viene scoperta challenge, l’ authenticator challenge, il peer challenge, e la user's login sono sostituite da questa informazione

Weaknesses Deriving 3 DES Keys from the NT Password Hash – Il difetto più rilevante del protocollo – Dato che gli ultimi 5 bytes della terza chiave sono zero, la chiave è effettivamente lunga 16 bytes brute force attack, exhaustive search (nell’ordine di secondi) Conoscendo gli ultimi 16 bytes è possibile ridurre lo spazio di ricerca dei possibili valori hashes di un fattore di 2^16 (e quindi anche lo spazio delle password collassa di un fattore pari) dictionary attack e exhaustive search