際際滷

際際滷Share a Scribd company logo

OAuthorize yourself 2.0

Download as PPTX, PDF
DevDay
DevDay

Il talk si propone di fornire strumenti utili ai developer che vogliono offrire ai propri utenti autenticazione ed autorizzazione da differenti canali quali mobile e browser su differenti tipi di risorse come web-application e REST services. Saranno mostrati gli algoritmi di crittografia ed i protocolli pi湛 noti di autenticazione/autorizzazione, evitando noie matematiche e considerando solo le applicazioni pratiche. Gli argomenti trattati saranno Crittografia (25 minuti) symmetric key, asymmetric key, key exchange, key derivation function, key management, hash function, MAC function Autenticazione e Autorizzazione (50 minuti) HTTPS, Password, autenticazione a 2 fattori, Cookie (stateful), Access Token (stateless), JWT,OAuth2 e OpenID Connect

1 of 48
Downloaded 16 times
OAuthorize yourself 2.0 Dalla crittografia ai protocolli web Ciro Bologna Security Architect presso QUI! Group S.p.A. 1
Agenda parte 1 Crittografia Introduzione Symmetric Key Asymmetric Key Key Exchange Key Derivation Function Key Management Hash Function MAC Function 2
Alice vuole inviare un messaggio a Bob Alice vorrebbe che Eve non capisca il messaggio Secure Channel msg msg $ # / 3 Introduzione 1/3
Confidenzialit Il messaggio 竪 leggibile solo dai destinatari Integrit Il messaggio originale 竪 inalterato durante la trasmissione da mittente a destinatario Disponibilit Il messaggio 竪 fruibile per gli scopi cui 竪 stato creato Identit Attraverso un processo (autenticazione) si 竪 garantiti che mittente e destinatario siano chi dicono di essere Non ripudiabilit Il mittente non pu嘆 negare di aver trasmesso il messaggio 4 Introduzione 2/3
Introduzione 3/3 5 Ciphers Classical Substitution Monoalphabetic Polyalphabetic Transpositional Modern Symmetric Block Cipher Stream Cipher Aymmetric
Symmetric Key 1/3 Algoritmo noto pubblicamente, la sicurezza dipende dalla chiave Stessa chiave condivisa tra Alice e Bob (Ka=Kb=K) 6 Insecure Channel Encipher Decipher plaintext plaintext ciphertext ciphertext
Symmetric Key 2/3 Considerazioni Scambio e memorizzazione della chiave? Bruteforce sulla chiave Analisi statistica Efficienza Confidenzialit ed Integrit Quale algoritmo? 7
Symmetric Key 3/3 Modes of Operation, consigli del NIST (National Institute of Standards Technology) ElectronicCodeBook CipherBlockChaining CipherFeedbackMode OutputFeedbackMode CounterMode Prestare attenzione ai parametri di inizializzazione dellalgoritmo (es. random IV) 8
Asymmetric Key 1/3 Algoritmo noto pubblicamente, la sicurezza dipende dalla chiave Coppia di chiavi pubblica, privata appartenenti a Bob K=(Kpub,Kpriv) Kpriv 竪 disponibile solo a Bob, mentre Kpub 竪 disponibile a tutti, tra cui Alice 9 Insecure Channel Encipher Decipher plaintext plaintext ciphertext ciphertext
Asymmetric Key 2/3 Algoritmo noto pubblicamente, la sicurezza dipende dalla chiave Coppia di chiavi pubblica, privata appartenenti a Bob K=(Kpub,Kpriv) Kpriv 竪 disponibile solo a Bob, mentre Kpub 竪 disponibile ad Alice ed anche a Eve! 10 Insecure Channel Sign Message Verify Digest Message Trusted Message Message+Digest Message+Digest Diges t Diges t Diges t
Asymmetric Key 3/3 Considerazioni Memorizzazione chiave privata? Problemi di Scambio Chiave risolti, la chiave per cifrare 竪 pubblica Bruteforce sulla chiave troppo costoso Scarsa efficienza Confidenzialit, Integrit, e Non ripudio Quale algoritmo? 11
Symmetric vs Asymmetric Key Raccomandazioni NIST su lughezza delle chiavi e crittoperiodo https://www.keylength.com/en/4/ In generale la crittografia a chiave asimmetrica 竪 utilizzata per scambiare e/o stabilire in maniera sicura una chiave simmetrica valida per un periodo di tempo limitato In base ad unanalisi dei rischi, la memorizzazione potrebbe avvenire in locazioni/dispositivi dedicati con adeguate propriet di Tamper Resistance Tamper Evidence Tamper Responsivess 12
Key Exchange 1/2 Es. Algoritmo Diffie Hellman tra Alice e Bob 13 Insecure Channel Compute Compute Segreto random a Segreto Random b Valore A pubblico Valore B pubblico p, g Valori Noti a Tutti p, g, A, B ??? Compute Compute a B p b A p
Key Exchange 2/2 Algoritmo Diffie Hellman Consente di calcolare lo stesso segreto condiviso tra Alice e Bob senza che Eve possa ascoltarlo I valori segreti a e b non vengono mai trasmessi! Lidea di fondo 竪 che Eve non abbia la capacit computazionale necessaria a calcolarli Manca lautenticazione! E possibile un attacco man in the middle 14
Key Derivation Function 1/2 Derivazione di una o pi湛 chiavi segrete a partire da un segreto dellutente come ad esempio una password (es. Apple passcode) Sono computazionalmente costose per rendere il cracking della chiave pi湛 difficile 15 KDF SEGRETO N iterazioni SALT
Es. supponiamo che Alice e Bob abbiano pre-condiviso un segreto su un altro canale (es. posta, mail, SMS) Possono derivare ogni volta (es. ogni transazione) la stessa chiave senza mai pi湛 trasmettere il segreto! Key Derivation Function 2/2 16 KDF ID_TRANSAZIONE N iterazioni SALT KDF SEGRETO N iterazioni SALT
Key Management NIST 800-130: A Framework for Designing Cryptographic Key Management System Security Policies Roles and Responsibilities Cryptographic Keys and Metadata Security Controls Testing and System Assurances Disaster Recovery Security Assessment Technology Challenges La gestione delle chiavi crittografiche 竪 il punto pi湛 delicato, non solo dal punto di vista tecnologico, ma anche negli aspetti gestionali nonch辿 organizzativi 17
Hash Function Funzioni che hanno le seguenti propriet Deterministiche Non invertibili Output a lunghezza fissa indipendentemente dallinput Un piccolo cambio nellinput produce un output totalmente diverso Resistenza alle collisioni Garantiscono Integrit se applicate ad un messaggio? No! 18
MAC Function Combinazione di crittografia simmetrica e funzioni di Hash E possibile ora garantire lIntegrit Porre sempre attenzione allo scambio della chiave! 19 MAC MAC
Agenda parte 2 Autenticazione ed Autorizzazione Certificate HTTPS Password 2FactorsAuthentication Cookie Access Token JWT OAuth2 OpenID Connect 20
Certificates 1/3 Public Key Infrastructure Sistema gerarchico per lemissione dei certificati Le Certification Authority (CA) nascono con lobiettivo di garantire lIdentit degli attori dello scambio di messaggi, che seguono delle procedure per registrarsi alla CA Domain Validation Organization Validation Extended Validation X.509 v.3 definisce la struttura ed i campi presenti in un certificato rilasciato da una CA Version, Serial Number, Signature Algorithm identifier, Issuer Name, Period of Validity (Not Before, Not After) Subject Name, Subjects public key info Issuer Unique Identifier, Subject Unique Identifier Extension (Key Usage) Signature (algorithm, parameters, encrypted hash) 21
Certificates 2/3 Es. Catena dei certificati 22 La root CA firma con la sua chiave privata il certificato della intermediate CA Lintermediate CA firma con la sua chiave privata il certificato associato allo specifico dominio Il certificato del dominio pu嘆 essere verificato con la chiave pubblica della intermediate CA Il certificato della intermediate CA pu嘆 essere verificato con la chiave pubblica della root CA
Certificates 3/3 Revoca anzitempo dei certificati compromissione della chiave utente non pi湛 certificato dalla CA il certificato della CA 竪 compromesso Certificate Revocation List la CA mantiene aggiornata la lista dei certificati revocati il client dovrebbe verificare la CRL, non necessariamente aggiornata OCSP Online Certificate Status Protocol Pi湛 recente, consente la verifica del singolo certificato interrogando un servizio real time https://letsencrypt.org/getting-started/ https://ietf-wg-acme.github.io/acme/ 23
HTTPS 1/3 https://tools.ietf.org/html/rfc2818 Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS precisely as you would use HTTP over TCP Obiettivi TLS Confidenzialit ed Integrit TLS Record Protocol Crittografia simmetrica MAC con chiave simmetrica TLS Handshake Protocol Crittografia asimmetrica Negoziazione sicura di un segreto condiviso Negoziazione affidabile Per ogni sessione c竪 una nuova chiave simmetrica scambiata grazie alla crittografica asimmetrica 24
HTTPS 2/3 PKI e CA rendono possibile lapplicazione di HTTPS I browser hanno una lista di CA note E possibile fidarsi di CA private inserendo in un trust-store le chiavi pubbliche, generalmente evitare certificati Self-Signed Mutua autenticazione Entrambe le parti sono verificate Costi di gestione Dove memorizzo la chiave privata del client? 25
HTTPS 3/3 Limplementazione del protocollo non 竪 immune da falle di sicurezza Utilizzare ultima versione del protocollo TLS v1.2 Forzare lutilizzo di cifrari aggiornati Non consentire downgrade dei cifrari in fase di handshake Valutazione Certificate Pinning https://www.owasp.org/index.php/Certificate_and_P ublic_Key_Pinning Prestare attenzione alla certificate rotation Utile per mobile app 26
Password 1/2 Strong Password a seconda di una opportuna analisi di rischio Utilizzo di regex sia front-end che back-end Es. PCI-DSS 7 caratteri, 1 minuscola, 1 maiuscola, 1 numero, 1 carattere speciale, diversa dalla username, e diversa dalla password precedente Memorizzazione sul database utilizzando funzioni di hash Utilizzare salt random Utilizzare primitive crittografiche aggiornate Protezione del backup Trasmissione esclusivamente su HTTPS H Authorization : Basic Base64(username:password) H Content-Type : application/x-www-form-urlencoded-d username=user&password=AxcC91$ 27
Password 2/2 Punti di Attenzione Infrastruttura SSL Offloading Web Server/Reverse Proxy Application Server File di Log Procedure di recovery password Mail dellutente Backoffice di assistenza Aggiornamento periodico forzato es. 90 giorni Centralizzazione della gestione password in un componente dedicato, evitando la trasmissione della password tra le applicazioni 28
2FactorsAuthentication 1/2 Per Strong Authentication, si intende lapplicazione di almeno 2 delle seguenti Something you know es. password, pin Something you have es. device, certificato Something you are es. biometria Attenzione alla fase di enrolment dei device Attenzione alla fase di acquisizione di dati biometrici https://cubs.buffalo.edu/images/pdf/pub/symmetric- hash-functions-for-secure-fingerprint-biometric- systems.pdf 29
2FactorsAuthentication 2/2 Es. Password + OTP Utilizzare protocolli standard come ad esempio HOTP, basato su HMAC In molti scenari utilizzare una soluzione software di OTP garantisce una sicurezza sufficiente Utile in uno scenario mobile, dove 竪 possibile usare SMS o Notifiche sul device Es. Password + Certificato Client La mutua autenticazione con il certificato 竪 una strategia efficace in scenari enterprise 30
Cookie 1/2 https://tools.ietf.org/html/rfc6265 HTTP State Management Mechanism defines the HTTP Cookie and Set-Cookie header fields Es. Browser utilizza webapp servita da Application Server == Server -> User Agent == Set-Cookie: SID=31d4d96e407aad42 == User Agent -> Server == Cookie: SID=31d4d96e407aad42 Il server pu嘆 anche modificare lo scope del cookie == Server -> User Agent == Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com == User Agent -> Server == Cookie: SID=31d4d96e407aad42 Il cookie sar valido in ogni sottodominio di example.com 31
== Server -> User Agent== Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly; Expires=Wed, 09 Jun 2021 10:18:14 GMT I cookie dovrebbero avere una scadenza piuttosto breve Il flag HttpOnly impedir che i cookie siano accessibili via Javascript Il Secure flag impedier di inviare il cookie in assenza di HTTPS Mitigazioni al CSRF Cross Site Request Forgery Synchronizer Token Pattern Verificare header Referer e Origin Al solito, non affidarsi ad implementazioni custom 32 Cookie 2/2
Access Token 1/2 I Cookie sono utili in un contesto di applicazioni stateful, dove il server mantiene una sessione In un contesto di API RESTful 竪 preferibile unautenticazione stateless Il server pu嘆 generare un access_token come una semplice stringa alfanumerica random memorizzata nel WebStorage (localStorage/sessionStorage HTML5) del client curl H Authorization : Bearer df15e2ff-95ea-3515- a7b1-1ca8e1591547 X GET https://service/resource/1 33
Access Token 2/2 Un access_token ha una durata limitata ed a seconda del contesto 竪 possibile prevedere meccanismi di refresh XSS Cross Site Scripting Javascript pu嘆 accedere al Web Storage, di conseguenza 竪 possibile effettuare code injection nelle form <script>alert('You are Hacked');</script> Escape ed Encoding di tutti i dati untrusted OWASP Cheat Sheet 34
JWT 1/3 JWT JSON Web Token Un particolare tipo di access_token utilizzato per scambiare informazioni (claims) tra le parti Tale informazioni sono firmate e pertanto possono essere verificate 35 Header Body JWS - con chiave simmetrica
JWT 2/3 36 Header Body JWS - con chiave asimmetrica Numerose librerie a supporto su https://jwt.io/
JWT 3/3 Nel caso JWS simmetrica prestare attenzione allo scambio ed alla memorizzazione della chiave! Il JWT non dovrebbe avere informazioni sensibili, nel caso sia necessario valutare il JWE che tra le sue informazioni ha una Content Encrypted Key con cui cifra i claims Replay Attack possono essere mitigati utilizzando un nonce (jti claim), data di scadenza (exp claim), ed il data di creazione (iat claim) tra i claims E possibile memorizzare i JWT nei Cookie! 37
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf Ruoli coinvolti Resource Owner: un entit in grado di garantire laccesso ad una risorsa protetta. Quando tale entit 竪 una persona, viene detta end- user Resource Server: il server che espone le risorse protette e che ne garantisce laccesso in caso di access token valido Client: un applicazione che vuole accedere alle risorse protette con lautorizzazione del Resource Owner Authorization Server: il server che rilascia gli access token ai client dopo una corretta autenticazione ed autorizzazione del Resource Owner 38 OAuth2.0 1/6
Registrazione Client si registra presso Authorization Server specificando un redirect_uri (in HTTPS!) Riceve client_id (info pubblica) e secret (info privata) Grant Type implicit: mobile app, webapp frontend only authorization_code: webapp frontend + backend password: webapp frontend + backend nel caso in cui Authorization Server e Resource Server coincidano client_credentials: server to server 39 OAuth2.0 2/6
Grant Type implicit Endpoint /authorize indicando allAuthorization Server client_id e redirect_uri Redirect alla pagina di login dellAuthorization Server dove il Resource Owner si autentica prima e poi autorizza il Client ad accedere ad i suoi dati Redirect al redirect_uri mostrando laccess_token https://localhost/index#access_token=7fbd257e-6184-3a33-873a- 1b690058292c&token_type=Bearer&expires_in=2807 Accesso al Resource Server garantito grazie allaccess_token curl -k -X GET -H 'Accept: application/json' -H 'Authorization : Bearer be987a62-f3f4-3947-a359-acdbac9719b5' 'https://localhost:8243/test/1.0/resource' { "data" : "sample JSON"} 40 OAuth2.0 3/6
Grant Type authorization_code Endpoint /authorize indicando allAuthorization Server client_id e redirect_uri Redirect alla pagina di login dellAuthorization Server dove il Resource Owner si autentica prima e poi autorizza il Client ad accedere ad i suoi dati Redirect al redirect_uri mostrando lauthorization_code https://localhost/index?code=44d5aaf4-2012-326c-86fb-2c29f2f8c23e Endpoint /token indicando allAuthorization Server Base64(client_id, secret), redirect_uri, authorization_code curl -k -d "grant_type=authorization_code&code=44d5aaf4-2012-326c-86fb- 2c29f2f8c23e&redirect_uri=https%3A%2F%2Flocalhost%2Findex" -H "Authorization: Basic bFY4SDlxM0dPaWl4RnFlZjZZZTdvZV9USEFNYTp2V3ZfS21jbDlRQzU1ZDh1NDV0bENtVm9NSFFh" https://localhost:8243/token {"access_token": "be987a62-f3f4-3947-a359-acdbac9719b5, "expires_in": 1212, "refresh_token": "23939ba5-5b17-3f71-916c-8042da3f2c36, "scope": "default, "token_type": "Bearer} Accesso al Resource Server garantito grazie allaccess_token curl -k -X GET -H 'Accept: application/json' -H 'Authorization : Bearer be987a62-f3f4-3947-a359- acdbac9719b5' 'https://localhost:8243/test/1.0/resource' { "data" : "sample JSON"} 41 OAuth2.0 4/6
Grant Type password Endpoint /token indicando allAuthorization Server Base64(client_id, secret), username, password curl -k -d "grant_type=password&username=end-user&password=Password1$" -H "Authorization: Basic bFY4SDlxM0dPaWl4RnFlZjZZZTdvZV9USEFNYTp2V3ZfS21jbDlRQzU1ZDh1NDV0bENtVm9 NSFFh" https://localhost:8243/token {"access_token": "be987a62-f3f4-3947-a359-acdbac9719b5, "expires_in": 567, "refresh_token": "23939ba5-5b17-3f71-916c-8042da3f2c36, "scope": "default, "token_type": "Bearer} Accesso al Resource Server garantito grazie allaccess_token curl -k -X GET -H 'Accept: application/json' -H 'Authorization : Bearer be987a62-f3f4- 3947-a359-acdbac9719b5' 'https://localhost:8243/test/1.0/resource' { "data" : "sample JSON"} Stiamo autenticando contemporaneamente sia Client che Resource Owner in una sola chiamata 42 OAuth2.0 5/6
Grant Type client_credentials Endpoint /token indicando allAuthorization Server Base64(client_id, secret) curl -k -d "grant_type=client_credentials" -H "Authorization: Basic bFY4SDlxM0dPaWl4RnFlZjZZZTdvZV9USEFNYTp2V3ZfS21jbDlRQzU1ZDh1NDV0bENtVm9 NSFFh" https://localhost:8243/token {"access_token": "f93a66a2-d51a-341e-830a-a190dd4b2258, "expires_in": 278, "scope": "am_application_scope default, "token_type": "Bearer} Stiamo autenticando solo il Client e NON il Resource Owner! Lo scope di questo access_token 竪 in genere differente dagli altri grant_type e non 竪 detto che garantisca laccesso a tutte le risorse presenti sul Resource Server Per ogni richiesta di token 竪 possibile specificare un particolare scope, che viene assegnato se e solo se chi richiede il token ne ha gli opportuni diritti Gli scope possono essere utili nel caso di fine grained authorization 43 OAuth2.0 6/6
OpenID Connect 竪 un identity layer sviluppato sulle basi di OAuth2.0, di cui condivide gli endpoint /token, /authorize I Client non ricevono pi湛 semplici access_token bens狸 degli id_token, ovvero dei JWT con i claim relativi ad un Resource Owner id_token standard claims "at_hash": "nRQa2D-pBK3dbqrH0KaICw", "sub": "end-user@carbon.super", "aud": [ "lV8H9q3GOiixFqef6Ye7oe_THAMa" ], "azp": "lV8H9q3GOiixFqef6Ye7oe_THAMa", "auth_time": 1480476397, "iss": "https://localhost:9443/oauth2/token", "exp": 1480479997, "iat": 1480476397 44 OpenID Connect 1/3
Lendpoint /token risponder quindi fornendo sia access_token che id_token { "access_token": "bd2fde09-1afd-3f35-a2f7-a1766312dedd", "expires_in": 3052, "id_token": "eyJ4NXQiOiJObUptT0dVeE16WmxZak0yWkRSaE5UWmxZVEExWXpkaFpUUmlPV0UwTldJMk0ySm1PVG MxWkEiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiblJRYTJELXBCSzNkYnFySDBLYUlDdyIsInN1YiI6ImVuZC11 c2VyQGNhcmJvbi5zdXBlciIsImF1ZCI6WyJsVjhIOXEzR09paXhGcWVmNlllN29lX1RIQU1hIl0sImF6cCI6Imx WOEg5cTNHT2lpeEZxZWY2WWU3b2VfVEhBTWEiLCJhdXRoX3RpbWUiOjE0ODA0NzYzOTcsImlzcyI6Imh0 dHBzOlwvXC8xOTIuMTY4LjEuNjo5NDQzXC9vYXV0aDJcL3Rva2VuIiwiZXhwIjoxNDgwNDgwMjQ0LCJpYXQi OjE0ODA0NzY2NDR9.e5573sl- szD4M3jX5SorGIYKNKNlEsmOpfM2qpVKGnzaRJyBOGEJt0gXbvAqWKlyOLrYP8rvDImQ9HlqbL60IbF0OwI0 z7LfJqWA2YcaQ5M3JWHQ3naM1uZi3mjWywnEcGzGUcftmCoJmgh4J48eZlDJpTQj2gW89nR_x1t-Xj4", "refresh_token": "2892d0b3-12ec-399c-b575-e7accc128486", "scope": "openid", "token_type": "Bearer } Valgono le considerazioni sul JWT fatte in precedenza, bisogna verificarne la signature 45 OpenID Connect 2/3
Inoltre 竪 presente un endpoint /userinfo specifico per recuperare standard claims relativi ad un utente 竪 necessario invocare lendpoint con gli opportuni scope per ottenere i claim associati email - email, email_verified phone - phone_number, phone_number_verified profile - name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at address address per non incorrere in problematiche di privacy 竪 opportuno utilizzare solo gli scope effettivamente necessari 46 OpenID Connect 3/3
OpenID Connect 竪 retrocompatibile OpenID Connect realizza una standardizzazione per laccesso alle informazioni sullidentit dellutente OAuth2 nasce come framework di autorizzazione, mentre OpenID Connect come framework di autenticazione OAuth2 lascia maggiore libert nellimplementazione della specifica 47 OAuth2.0 vs OpenID Connect 3/3
In definitiva Utilizzare protocolli ed implementazioni standard Scegliere una determinata soluzione in base ai requisiti ed i rischi associati Valutare sempre i costi di gestione delle chiavi crittografiche Tenersi aggiornati costantemente, parte della crittografia dipende dalle capacit computazionali Guardare alla sicurezza a 360 gradi, in generale si riesce a definire sicuro un sistema, con un certo grado di rischio, non solo grazie alla tecnologia, ma anche grazie ai processi ed alle strutture organizzative a supporto Domande? 48 Conclusioni

More Related Content

OAuthorize yourself 2.0

  • 1. OAuthorize yourself 2.0 Dalla crittografia ai protocolli web Ciro Bologna Security Architect presso QUI! Group S.p.A. 1
  • 2. Agenda parte 1 Crittografia Introduzione Symmetric Key Asymmetric Key Key Exchange Key Derivation Function Key Management Hash Function MAC Function 2
  • 3. Alice vuole inviare un messaggio a Bob Alice vorrebbe che Eve non capisca il messaggio Secure Channel msg msg $ # / 3 Introduzione 1/3
  • 4. Confidenzialit Il messaggio 竪 leggibile solo dai destinatari Integrit Il messaggio originale 竪 inalterato durante la trasmissione da mittente a destinatario Disponibilit Il messaggio 竪 fruibile per gli scopi cui 竪 stato creato Identit Attraverso un processo (autenticazione) si 竪 garantiti che mittente e destinatario siano chi dicono di essere Non ripudiabilit Il mittente non pu嘆 negare di aver trasmesso il messaggio 4 Introduzione 2/3
  • 6. Symmetric Key 1/3 Algoritmo noto pubblicamente, la sicurezza dipende dalla chiave Stessa chiave condivisa tra Alice e Bob (Ka=Kb=K) 6 Insecure Channel Encipher Decipher plaintext plaintext ciphertext ciphertext
  • 7. Symmetric Key 2/3 Considerazioni Scambio e memorizzazione della chiave? Bruteforce sulla chiave Analisi statistica Efficienza Confidenzialit ed Integrit Quale algoritmo? 7
  • 8. Symmetric Key 3/3 Modes of Operation, consigli del NIST (National Institute of Standards Technology) ElectronicCodeBook CipherBlockChaining CipherFeedbackMode OutputFeedbackMode CounterMode Prestare attenzione ai parametri di inizializzazione dellalgoritmo (es. random IV) 8
  • 9. Asymmetric Key 1/3 Algoritmo noto pubblicamente, la sicurezza dipende dalla chiave Coppia di chiavi pubblica, privata appartenenti a Bob K=(Kpub,Kpriv) Kpriv 竪 disponibile solo a Bob, mentre Kpub 竪 disponibile a tutti, tra cui Alice 9 Insecure Channel Encipher Decipher plaintext plaintext ciphertext ciphertext
  • 10. Asymmetric Key 2/3 Algoritmo noto pubblicamente, la sicurezza dipende dalla chiave Coppia di chiavi pubblica, privata appartenenti a Bob K=(Kpub,Kpriv) Kpriv 竪 disponibile solo a Bob, mentre Kpub 竪 disponibile ad Alice ed anche a Eve! 10 Insecure Channel Sign Message Verify Digest Message Trusted Message Message+Digest Message+Digest Diges t Diges t Diges t
  • 11. Asymmetric Key 3/3 Considerazioni Memorizzazione chiave privata? Problemi di Scambio Chiave risolti, la chiave per cifrare 竪 pubblica Bruteforce sulla chiave troppo costoso Scarsa efficienza Confidenzialit, Integrit, e Non ripudio Quale algoritmo? 11
  • 12. Symmetric vs Asymmetric Key Raccomandazioni NIST su lughezza delle chiavi e crittoperiodo https://www.keylength.com/en/4/ In generale la crittografia a chiave asimmetrica 竪 utilizzata per scambiare e/o stabilire in maniera sicura una chiave simmetrica valida per un periodo di tempo limitato In base ad unanalisi dei rischi, la memorizzazione potrebbe avvenire in locazioni/dispositivi dedicati con adeguate propriet di Tamper Resistance Tamper Evidence Tamper Responsivess 12
  • 13. Key Exchange 1/2 Es. Algoritmo Diffie Hellman tra Alice e Bob 13 Insecure Channel Compute Compute Segreto random a Segreto Random b Valore A pubblico Valore B pubblico p, g Valori Noti a Tutti p, g, A, B ??? Compute Compute a B p b A p
  • 14. Key Exchange 2/2 Algoritmo Diffie Hellman Consente di calcolare lo stesso segreto condiviso tra Alice e Bob senza che Eve possa ascoltarlo I valori segreti a e b non vengono mai trasmessi! Lidea di fondo 竪 che Eve non abbia la capacit computazionale necessaria a calcolarli Manca lautenticazione! E possibile un attacco man in the middle 14
  • 15. Key Derivation Function 1/2 Derivazione di una o pi湛 chiavi segrete a partire da un segreto dellutente come ad esempio una password (es. Apple passcode) Sono computazionalmente costose per rendere il cracking della chiave pi湛 difficile 15 KDF SEGRETO N iterazioni SALT
  • 16. Es. supponiamo che Alice e Bob abbiano pre-condiviso un segreto su un altro canale (es. posta, mail, SMS) Possono derivare ogni volta (es. ogni transazione) la stessa chiave senza mai pi湛 trasmettere il segreto! Key Derivation Function 2/2 16 KDF ID_TRANSAZIONE N iterazioni SALT KDF SEGRETO N iterazioni SALT
  • 17. Key Management NIST 800-130: A Framework for Designing Cryptographic Key Management System Security Policies Roles and Responsibilities Cryptographic Keys and Metadata Security Controls Testing and System Assurances Disaster Recovery Security Assessment Technology Challenges La gestione delle chiavi crittografiche 竪 il punto pi湛 delicato, non solo dal punto di vista tecnologico, ma anche negli aspetti gestionali nonch辿 organizzativi 17
  • 18. Hash Function Funzioni che hanno le seguenti propriet Deterministiche Non invertibili Output a lunghezza fissa indipendentemente dallinput Un piccolo cambio nellinput produce un output totalmente diverso Resistenza alle collisioni Garantiscono Integrit se applicate ad un messaggio? No! 18
  • 19. MAC Function Combinazione di crittografia simmetrica e funzioni di Hash E possibile ora garantire lIntegrit Porre sempre attenzione allo scambio della chiave! 19 MAC MAC
  • 20. Agenda parte 2 Autenticazione ed Autorizzazione Certificate HTTPS Password 2FactorsAuthentication Cookie Access Token JWT OAuth2 OpenID Connect 20
  • 21. Certificates 1/3 Public Key Infrastructure Sistema gerarchico per lemissione dei certificati Le Certification Authority (CA) nascono con lobiettivo di garantire lIdentit degli attori dello scambio di messaggi, che seguono delle procedure per registrarsi alla CA Domain Validation Organization Validation Extended Validation X.509 v.3 definisce la struttura ed i campi presenti in un certificato rilasciato da una CA Version, Serial Number, Signature Algorithm identifier, Issuer Name, Period of Validity (Not Before, Not After) Subject Name, Subjects public key info Issuer Unique Identifier, Subject Unique Identifier Extension (Key Usage) Signature (algorithm, parameters, encrypted hash) 21
  • 22. Certificates 2/3 Es. Catena dei certificati 22 La root CA firma con la sua chiave privata il certificato della intermediate CA Lintermediate CA firma con la sua chiave privata il certificato associato allo specifico dominio Il certificato del dominio pu嘆 essere verificato con la chiave pubblica della intermediate CA Il certificato della intermediate CA pu嘆 essere verificato con la chiave pubblica della root CA
  • 23. Certificates 3/3 Revoca anzitempo dei certificati compromissione della chiave utente non pi湛 certificato dalla CA il certificato della CA 竪 compromesso Certificate Revocation List la CA mantiene aggiornata la lista dei certificati revocati il client dovrebbe verificare la CRL, non necessariamente aggiornata OCSP Online Certificate Status Protocol Pi湛 recente, consente la verifica del singolo certificato interrogando un servizio real time https://letsencrypt.org/getting-started/ https://ietf-wg-acme.github.io/acme/ 23
  • 24. HTTPS 1/3 https://tools.ietf.org/html/rfc2818 Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS precisely as you would use HTTP over TCP Obiettivi TLS Confidenzialit ed Integrit TLS Record Protocol Crittografia simmetrica MAC con chiave simmetrica TLS Handshake Protocol Crittografia asimmetrica Negoziazione sicura di un segreto condiviso Negoziazione affidabile Per ogni sessione c竪 una nuova chiave simmetrica scambiata grazie alla crittografica asimmetrica 24
  • 25. HTTPS 2/3 PKI e CA rendono possibile lapplicazione di HTTPS I browser hanno una lista di CA note E possibile fidarsi di CA private inserendo in un trust-store le chiavi pubbliche, generalmente evitare certificati Self-Signed Mutua autenticazione Entrambe le parti sono verificate Costi di gestione Dove memorizzo la chiave privata del client? 25
  • 26. HTTPS 3/3 Limplementazione del protocollo non 竪 immune da falle di sicurezza Utilizzare ultima versione del protocollo TLS v1.2 Forzare lutilizzo di cifrari aggiornati Non consentire downgrade dei cifrari in fase di handshake Valutazione Certificate Pinning https://www.owasp.org/index.php/Certificate_and_P ublic_Key_Pinning Prestare attenzione alla certificate rotation Utile per mobile app 26
  • 27. Password 1/2 Strong Password a seconda di una opportuna analisi di rischio Utilizzo di regex sia front-end che back-end Es. PCI-DSS 7 caratteri, 1 minuscola, 1 maiuscola, 1 numero, 1 carattere speciale, diversa dalla username, e diversa dalla password precedente Memorizzazione sul database utilizzando funzioni di hash Utilizzare salt random Utilizzare primitive crittografiche aggiornate Protezione del backup Trasmissione esclusivamente su HTTPS H Authorization : Basic Base64(username:password) H Content-Type : application/x-www-form-urlencoded-d username=user&password=AxcC91$ 27
  • 28. Password 2/2 Punti di Attenzione Infrastruttura SSL Offloading Web Server/Reverse Proxy Application Server File di Log Procedure di recovery password Mail dellutente Backoffice di assistenza Aggiornamento periodico forzato es. 90 giorni Centralizzazione della gestione password in un componente dedicato, evitando la trasmissione della password tra le applicazioni 28
  • 29. 2FactorsAuthentication 1/2 Per Strong Authentication, si intende lapplicazione di almeno 2 delle seguenti Something you know es. password, pin Something you have es. device, certificato Something you are es. biometria Attenzione alla fase di enrolment dei device Attenzione alla fase di acquisizione di dati biometrici https://cubs.buffalo.edu/images/pdf/pub/symmetric- hash-functions-for-secure-fingerprint-biometric- systems.pdf 29
  • 30. 2FactorsAuthentication 2/2 Es. Password + OTP Utilizzare protocolli standard come ad esempio HOTP, basato su HMAC In molti scenari utilizzare una soluzione software di OTP garantisce una sicurezza sufficiente Utile in uno scenario mobile, dove 竪 possibile usare SMS o Notifiche sul device Es. Password + Certificato Client La mutua autenticazione con il certificato 竪 una strategia efficace in scenari enterprise 30
  • 31. Cookie 1/2 https://tools.ietf.org/html/rfc6265 HTTP State Management Mechanism defines the HTTP Cookie and Set-Cookie header fields Es. Browser utilizza webapp servita da Application Server == Server -> User Agent == Set-Cookie: SID=31d4d96e407aad42 == User Agent -> Server == Cookie: SID=31d4d96e407aad42 Il server pu嘆 anche modificare lo scope del cookie == Server -> User Agent == Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com == User Agent -> Server == Cookie: SID=31d4d96e407aad42 Il cookie sar valido in ogni sottodominio di example.com 31
  • 32. == Server -> User Agent== Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly; Expires=Wed, 09 Jun 2021 10:18:14 GMT I cookie dovrebbero avere una scadenza piuttosto breve Il flag HttpOnly impedir che i cookie siano accessibili via Javascript Il Secure flag impedier di inviare il cookie in assenza di HTTPS Mitigazioni al CSRF Cross Site Request Forgery Synchronizer Token Pattern Verificare header Referer e Origin Al solito, non affidarsi ad implementazioni custom 32 Cookie 2/2
  • 33. Access Token 1/2 I Cookie sono utili in un contesto di applicazioni stateful, dove il server mantiene una sessione In un contesto di API RESTful 竪 preferibile unautenticazione stateless Il server pu嘆 generare un access_token come una semplice stringa alfanumerica random memorizzata nel WebStorage (localStorage/sessionStorage HTML5) del client curl H Authorization : Bearer df15e2ff-95ea-3515- a7b1-1ca8e1591547 X GET https://service/resource/1 33
  • 34. Access Token 2/2 Un access_token ha una durata limitata ed a seconda del contesto 竪 possibile prevedere meccanismi di refresh XSS Cross Site Scripting Javascript pu嘆 accedere al Web Storage, di conseguenza 竪 possibile effettuare code injection nelle form <script>alert('You are Hacked');</script> Escape ed Encoding di tutti i dati untrusted OWASP Cheat Sheet 34
  • 35. JWT 1/3 JWT JSON Web Token Un particolare tipo di access_token utilizzato per scambiare informazioni (claims) tra le parti Tale informazioni sono firmate e pertanto possono essere verificate 35 Header Body JWS - con chiave simmetrica
  • 36. JWT 2/3 36 Header Body JWS - con chiave asimmetrica Numerose librerie a supporto su https://jwt.io/
  • 37. JWT 3/3 Nel caso JWS simmetrica prestare attenzione allo scambio ed alla memorizzazione della chiave! Il JWT non dovrebbe avere informazioni sensibili, nel caso sia necessario valutare il JWE che tra le sue informazioni ha una Content Encrypted Key con cui cifra i claims Replay Attack possono essere mitigati utilizzando un nonce (jti claim), data di scadenza (exp claim), ed il data di creazione (iat claim) tra i claims E possibile memorizzare i JWT nei Cookie! 37
  • 38. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf Ruoli coinvolti Resource Owner: un entit in grado di garantire laccesso ad una risorsa protetta. Quando tale entit 竪 una persona, viene detta end- user Resource Server: il server che espone le risorse protette e che ne garantisce laccesso in caso di access token valido Client: un applicazione che vuole accedere alle risorse protette con lautorizzazione del Resource Owner Authorization Server: il server che rilascia gli access token ai client dopo una corretta autenticazione ed autorizzazione del Resource Owner 38 OAuth2.0 1/6
  • 39. Registrazione Client si registra presso Authorization Server specificando un redirect_uri (in HTTPS!) Riceve client_id (info pubblica) e secret (info privata) Grant Type implicit: mobile app, webapp frontend only authorization_code: webapp frontend + backend password: webapp frontend + backend nel caso in cui Authorization Server e Resource Server coincidano client_credentials: server to server 39 OAuth2.0 2/6
  • 40. Grant Type implicit Endpoint /authorize indicando allAuthorization Server client_id e redirect_uri Redirect alla pagina di login dellAuthorization Server dove il Resource Owner si autentica prima e poi autorizza il Client ad accedere ad i suoi dati Redirect al redirect_uri mostrando laccess_token https://localhost/index#access_token=7fbd257e-6184-3a33-873a- 1b690058292c&token_type=Bearer&expires_in=2807 Accesso al Resource Server garantito grazie allaccess_token curl -k -X GET -H 'Accept: application/json' -H 'Authorization : Bearer be987a62-f3f4-3947-a359-acdbac9719b5' 'https://localhost:8243/test/1.0/resource' { "data" : "sample JSON"} 40 OAuth2.0 3/6
  • 41. Grant Type authorization_code Endpoint /authorize indicando allAuthorization Server client_id e redirect_uri Redirect alla pagina di login dellAuthorization Server dove il Resource Owner si autentica prima e poi autorizza il Client ad accedere ad i suoi dati Redirect al redirect_uri mostrando lauthorization_code https://localhost/index?code=44d5aaf4-2012-326c-86fb-2c29f2f8c23e Endpoint /token indicando allAuthorization Server Base64(client_id, secret), redirect_uri, authorization_code curl -k -d "grant_type=authorization_code&code=44d5aaf4-2012-326c-86fb- 2c29f2f8c23e&redirect_uri=https%3A%2F%2Flocalhost%2Findex" -H "Authorization: Basic bFY4SDlxM0dPaWl4RnFlZjZZZTdvZV9USEFNYTp2V3ZfS21jbDlRQzU1ZDh1NDV0bENtVm9NSFFh" https://localhost:8243/token {"access_token": "be987a62-f3f4-3947-a359-acdbac9719b5, "expires_in": 1212, "refresh_token": "23939ba5-5b17-3f71-916c-8042da3f2c36, "scope": "default, "token_type": "Bearer} Accesso al Resource Server garantito grazie allaccess_token curl -k -X GET -H 'Accept: application/json' -H 'Authorization : Bearer be987a62-f3f4-3947-a359- acdbac9719b5' 'https://localhost:8243/test/1.0/resource' { "data" : "sample JSON"} 41 OAuth2.0 4/6
  • 42. Grant Type password Endpoint /token indicando allAuthorization Server Base64(client_id, secret), username, password curl -k -d "grant_type=password&username=end-user&password=Password1$" -H "Authorization: Basic bFY4SDlxM0dPaWl4RnFlZjZZZTdvZV9USEFNYTp2V3ZfS21jbDlRQzU1ZDh1NDV0bENtVm9 NSFFh" https://localhost:8243/token {"access_token": "be987a62-f3f4-3947-a359-acdbac9719b5, "expires_in": 567, "refresh_token": "23939ba5-5b17-3f71-916c-8042da3f2c36, "scope": "default, "token_type": "Bearer} Accesso al Resource Server garantito grazie allaccess_token curl -k -X GET -H 'Accept: application/json' -H 'Authorization : Bearer be987a62-f3f4- 3947-a359-acdbac9719b5' 'https://localhost:8243/test/1.0/resource' { "data" : "sample JSON"} Stiamo autenticando contemporaneamente sia Client che Resource Owner in una sola chiamata 42 OAuth2.0 5/6
  • 43. Grant Type client_credentials Endpoint /token indicando allAuthorization Server Base64(client_id, secret) curl -k -d "grant_type=client_credentials" -H "Authorization: Basic bFY4SDlxM0dPaWl4RnFlZjZZZTdvZV9USEFNYTp2V3ZfS21jbDlRQzU1ZDh1NDV0bENtVm9 NSFFh" https://localhost:8243/token {"access_token": "f93a66a2-d51a-341e-830a-a190dd4b2258, "expires_in": 278, "scope": "am_application_scope default, "token_type": "Bearer} Stiamo autenticando solo il Client e NON il Resource Owner! Lo scope di questo access_token 竪 in genere differente dagli altri grant_type e non 竪 detto che garantisca laccesso a tutte le risorse presenti sul Resource Server Per ogni richiesta di token 竪 possibile specificare un particolare scope, che viene assegnato se e solo se chi richiede il token ne ha gli opportuni diritti Gli scope possono essere utili nel caso di fine grained authorization 43 OAuth2.0 6/6
  • 44. OpenID Connect 竪 un identity layer sviluppato sulle basi di OAuth2.0, di cui condivide gli endpoint /token, /authorize I Client non ricevono pi湛 semplici access_token bens狸 degli id_token, ovvero dei JWT con i claim relativi ad un Resource Owner id_token standard claims "at_hash": "nRQa2D-pBK3dbqrH0KaICw", "sub": "end-user@carbon.super", "aud": [ "lV8H9q3GOiixFqef6Ye7oe_THAMa" ], "azp": "lV8H9q3GOiixFqef6Ye7oe_THAMa", "auth_time": 1480476397, "iss": "https://localhost:9443/oauth2/token", "exp": 1480479997, "iat": 1480476397 44 OpenID Connect 1/3
  • 45. Lendpoint /token risponder quindi fornendo sia access_token che id_token { "access_token": "bd2fde09-1afd-3f35-a2f7-a1766312dedd", "expires_in": 3052, "id_token": "eyJ4NXQiOiJObUptT0dVeE16WmxZak0yWkRSaE5UWmxZVEExWXpkaFpUUmlPV0UwTldJMk0ySm1PVG MxWkEiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiblJRYTJELXBCSzNkYnFySDBLYUlDdyIsInN1YiI6ImVuZC11 c2VyQGNhcmJvbi5zdXBlciIsImF1ZCI6WyJsVjhIOXEzR09paXhGcWVmNlllN29lX1RIQU1hIl0sImF6cCI6Imx WOEg5cTNHT2lpeEZxZWY2WWU3b2VfVEhBTWEiLCJhdXRoX3RpbWUiOjE0ODA0NzYzOTcsImlzcyI6Imh0 dHBzOlwvXC8xOTIuMTY4LjEuNjo5NDQzXC9vYXV0aDJcL3Rva2VuIiwiZXhwIjoxNDgwNDgwMjQ0LCJpYXQi OjE0ODA0NzY2NDR9.e5573sl- szD4M3jX5SorGIYKNKNlEsmOpfM2qpVKGnzaRJyBOGEJt0gXbvAqWKlyOLrYP8rvDImQ9HlqbL60IbF0OwI0 z7LfJqWA2YcaQ5M3JWHQ3naM1uZi3mjWywnEcGzGUcftmCoJmgh4J48eZlDJpTQj2gW89nR_x1t-Xj4", "refresh_token": "2892d0b3-12ec-399c-b575-e7accc128486", "scope": "openid", "token_type": "Bearer } Valgono le considerazioni sul JWT fatte in precedenza, bisogna verificarne la signature 45 OpenID Connect 2/3
  • 46. Inoltre 竪 presente un endpoint /userinfo specifico per recuperare standard claims relativi ad un utente 竪 necessario invocare lendpoint con gli opportuni scope per ottenere i claim associati email - email, email_verified phone - phone_number, phone_number_verified profile - name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at address address per non incorrere in problematiche di privacy 竪 opportuno utilizzare solo gli scope effettivamente necessari 46 OpenID Connect 3/3
  • 47. OpenID Connect 竪 retrocompatibile OpenID Connect realizza una standardizzazione per laccesso alle informazioni sullidentit dellutente OAuth2 nasce come framework di autorizzazione, mentre OpenID Connect come framework di autenticazione OAuth2 lascia maggiore libert nellimplementazione della specifica 47 OAuth2.0 vs OpenID Connect 3/3
  • 48. In definitiva Utilizzare protocolli ed implementazioni standard Scegliere una determinata soluzione in base ai requisiti ed i rischi associati Valutare sempre i costi di gestione delle chiavi crittografiche Tenersi aggiornati costantemente, parte della crittografia dipende dalle capacit computazionali Guardare alla sicurezza a 360 gradi, in generale si riesce a definire sicuro un sistema, con un certo grado di rischio, non solo grazie alla tecnologia, ma anche grazie ai processi ed alle strutture organizzative a supporto Domande? 48 Conclusioni

Editor's Notes

  • #9: Agenzia del governo degli stati uniti
  • #10: Confidenzialit ed integrit
  • #11: Confidenzialit ed integrit
  • #32: Set-Cookie 竪 un HTTP Response Header Il server pu嘆 rimuovere un cookie utilizzano un Expire Date passato e sostituendo il cookie attuale
  • #41: https://localhost:8243/authorize?response_type=token&client_id=lV8H9q3GOiixFqef6Ye7oe_THAMa&redirect_uri=https%3A%2F%2Flocalhost%2Findex
  • #42: https://localhost:8243/authorize?response_type=code&client_id=lV8H9q3GOiixFqef6Ye7oe_THAMa&redirect_uri=https%3A%2F%2Flocalhost%2Findex
  • #45: At_hash access_token hash value Sub subject Identifier Aud Audience lV8H9q3GOiixFqef6Ye7oe_THAMa client_id Azp Authorized Party