1

OAuthorize yourself 2.0

Dalla crittografia ai protocolli web

Ciro Bologna Security Architect presso QUI! Group S.p.A.

2

Agenda parte 1

• Crittografia– Introduzione– Symmetric Key– Asymmetric Key– Key Exchange – Key Derivation Function – Key Management– Hash Function– MAC Function

3

• Alice vuole inviare un messaggio a Bob• Alice vorrebbe che Eve non capisca il messaggio

Secure Channel

msg msg

$#/

Introduzione 1/3

4

Confidenzialità• Il messaggio è leggibile solo dai destinatari

Integrità• Il messaggio originale è inalterato durante la trasmissione da mittente a

destinatarioDisponibilità• Il messaggio è fruibile per gli scopi cui è stato creato

Identità• Attraverso un processo (autenticazione) si è garantiti che mittente e

destinatario siano chi dicono di essereNon ripudiabilità• Il mittente non può negare di aver trasmesso il messaggio

Introduzione 2/3

5

Introduzione 3/3

Ciphers

Classical

Substitution

Monoalphabetic Polyalphabetic

Transpositional

Modern

Symmetric

Block Cipher Stream Cipher

Aymmetric

6

Symmetric Key 1/3• Algoritmo noto pubblicamente, la sicurezza dipende dalla chiave• Stessa chiave condivisa tra Alice e Bob (Ka=Kb=K)

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?

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 dell’algoritmo (es. random IV)

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

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!

Insecure Channel

Sign Message

Verify Digest

Message TrustedMessage

Message+Digest Message+Digest

Digest

Digest

Digest

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?

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 un’analisi dei rischi, la memorizzazione potrebbe avvenire in locazioni/dispositivi dedicati con adeguate proprietà di– Tamper Resistance– Tamper Evidence– Tamper Responsivess

13

Key Exchange 1/2

• Es. Algoritmo Diffie Hellman tra Alice e Bob

Insecure Channel

Compute ComputeSegreto

random a

SegretoRandom b

Valore Apubblico

Valore Bpubblico

p, g Valori Noti a Tutti

p, g, A, B ???

Compute ComputeaBp

bAp

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!– L’idea di fondo è che Eve non abbia la capacità

computazionale necessaria a calcolarli– Manca l’autenticazione! E’ possibile un attacco

man in the middle

15

Key Derivation Function 1/2

• Derivazione di una o più chiavi segrete a partire da un segreto dell’utente come ad esempio una password (es. Apple passcode)

• Sono computazionalmente costose per rendere il cracking della chiave più difficile

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

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

18

Hash Function

• Funzioni che hanno le seguenti proprietà– Deterministiche– Non invertibili– Output a lunghezza fissa indipendentemente dall’input– Un piccolo cambio nell’input produce un output

totalmente diverso– Resistenza alle collisioni

• Garantiscono Integrità se applicate ad un messaggio? No!

19

MAC Function

• Combinazione di crittografia simmetrica e funzioni di Hash

• E’ possibile ora garantire l’Integrità• Porre sempre attenzione allo scambio della

chiave!

MAC

MAC

20

Agenda parte 2

• Autenticazione ed Autorizzazione– Certificate– HTTPS– Password– 2FactorsAuthentication– Cookie – Access Token JWT– OAuth2– OpenID Connect

21

Certificates 1/3• Public Key Infrastructure

– Sistema gerarchico per l’emissione dei certificati– Le Certification Authority (CA) nascono con l’obiettivo di garantire l’Identità 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, Subject’s public key info– Issuer Unique Identifier, Subject Unique Identifier– Extension (Key Usage)– Signature (algorithm, parameters, encrypted hash)

22

Certificates 2/3• Es. Catena dei certificati

La root CA firma con la sua chiave privata il certificato della intermediate CA

L’intermediate CA firma con la sua chiave privata il certificato associato allo

specifico dominioIl certificato del dominio può essere

verificato con la chiave pubblica dellaintermediate 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/

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

25

HTTPS 2/3

• PKI e CA rendono possibile l’applicazione 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?

26

HTTPS 3/3

• L’implementazione del protocollo non è immune da falle di sicurezza– Utilizzare ultima versione del protocollo TLS v1.2– Forzare l’utilizzo di cifrari aggiornati– Non consentire downgrade dei cifrari in fase di handshake

• Valutazione Certificate Pinning– https://www.owasp.org/index.php/

Certificate_and_Public_Key_Pinning– Prestare attenzione alla certificate rotation– Utile per mobile app

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$”

28

Password 2/2• Punti di Attenzione

– Infrastruttura • SSL Offloading• Web Server/Reverse Proxy• Application Server

– File di Log– Procedure di recovery password

• Mail dell’utente• 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

29

2FactorsAuthentication 1/2

• Per Strong Authentication, si intende l’applicazione 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

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

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

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

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 un’autenticazione 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’

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

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

Header Body JWS - con chiave simmetrica

36

JWT 2/3

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!

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 l’accesso 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

l’accesso in caso di access token valido– Client: un applicazione che vuole accedere alle risorse protette con

l’autorizzazione del Resource Owner– Authorization Server: il server che rilascia gli access token ai client dopo una

corretta autenticazione ed autorizzazione del Resource Owner

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

OAuth2.0 2/6

40

• Grant Type implicit– Endpoint /authorize indicando all’Authorization Server client_id e redirect_uri– Redirect alla pagina di login dell’Authorization Server dove il Resource Owner si

autentica prima e poi autorizza il Client ad accedere ad i suoi dati– Redirect al redirect_uri mostrando l’access_token

• https://localhost/index#access_token=7fbd257e-6184-3a33-873a-1b690058292c&token_type=Bearer&expires_in=2807

– Accesso al Resource Server garantito grazie all’access_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"}

OAuth2.0 3/6

41

• Grant Type authorization_code– Endpoint /authorize indicando all’Authorization Server client_id e redirect_uri– Redirect alla pagina di login dell’Authorization Server dove il Resource Owner si autentica

prima e poi autorizza il Client ad accedere ad i suoi dati– Redirect al redirect_uri mostrando l’authorization_code

• https://localhost/index?code=44d5aaf4-2012-326c-86fb-2c29f2f8c23e– Endpoint /token indicando all’Authorization 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 all’access_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"}

OAuth2.0 4/6

42

• Grant Type password– Endpoint /token indicando all’Authorization Server Base64(client_id, secret), username,

password• curl -k -d "grant_type=password&username=end-user&password=Password1$" -H "Authorization:

Basic bFY4SDlxM0dPaWl4RnFlZjZZZTdvZV9USEFNYTp2V3ZfS21jbDlRQzU1ZDh1NDV0bENtVm9NSFFh" 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 all’access_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

OAuth2.0 5/6

43

• Grant Type client_credentials– Endpoint /token indicando all’Authorization Server Base64(client_id, secret)

• curl -k -d "grant_type=client_credentials" -H "Authorization: Basic bFY4SDlxM0dPaWl4RnFlZjZZZTdvZV9USEFNYTp2V3ZfS21jbDlRQzU1ZDh1NDV0bENtVm9NSFFh" 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 l’accesso 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

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

OpenID Connect 1/3

45

• L’endpoint /token risponderà quindi fornendo sia access_token che id_token{ "access_token": "bd2fde09-1afd-3f35-a2f7-a1766312dedd", "expires_in": 3052, "id_token": "eyJ4NXQiOiJObUptT0dVeE16WmxZak0yWkRSaE5UWmxZVEExWXpkaFpUUmlPV0UwTldJMk0ySm1PVGMxWkEiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiblJRYTJELXBCSzNkYnFySDBLYUlDdyIsInN1YiI6ImVuZC11c2VyQGNhcmJvbi5zdXBlciIsImF1ZCI6WyJsVjhIOXEzR09paXhGcWVmNlllN29lX1RIQU1hIl0sImF6cCI6ImxWOEg5cTNHT2lpeEZxZWY2WWU3b2VfVEhBTWEiLCJhdXRoX3RpbWUiOjE0ODA0NzYzOTcsImlzcyI6Imh0dHBzOlwvXC8xOTIuMTY4LjEuNjo5NDQzXC9vYXV0aDJcL3Rva2VuIiwiZXhwIjoxNDgwNDgwMjQ0LCJpYXQiOjE0ODA0NzY2NDR9.e5573sl-szD4M3jX5SorGIYKNKNlEsmOpfM2qpVKGnzaRJyBOGEJt0gXbvAqWKlyOLrYP8rvDImQ9HlqbL60IbF0OwI0z7LfJqWA2YcaQ5M3JWHQ3naM1uZi3mjWywnEcGzGUcftmCoJmgh4J48eZlDJpTQj2gW89nR_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

OpenID Connect 2/3

46

• Inoltre è presente un endpoint /userinfo specifico per recuperare standard claims relativi ad un utente– è necessario invocare l’endpoint 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

OpenID Connect 3/3

47

• OpenID Connect è retrocompatibile• OpenID Connect realizza una standardizzazione

per l’accesso alle informazioni sull’identità dell’utente

• OAuth2 nasce come framework di autorizzazione, mentre OpenID Connect come framework di autenticazione

• OAuth2 lascia maggiore libertà nell’implementazione della specifica

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?

Conclusioni