[30-03-2023]

Recupera queste informazioni dal corso di Mantova perché alcune cose vengono riprese pari pari.

Quando parliamo di protocolli di autenticazione ci sono delle primitive che possiamo vedere sotto un altro punto di vista:

• identificazione: mappare univocamente una informazione su una identità, magari un utente che deve accedere a delle risorse. Parte che viene prima della autenticazione. Processo per verificare esattamente chi dico di essere.
• autenticazione: processo a garantire che la fase di identificazione sia andata a buon fine essenzialmente. Spesso è molto accoppiata con identificazione.
• autorizzazione: distinguiamo da autenticazione, ed è un processo che determina a cosa può accedere una entità che si è già autentificata.

Solitamente si usa AuthN (autenticazione) per dire se un utente ha permesso di accedere al sistema oppure no. Per intendere autorizzazione si usa AuthZ. Abbiamo anche dei protocolli per rendere molto accoppiato autorizzazione e autenticazione → access control, authentication based.

Solitamente abbiamo a che fare con questi blocchi:

• utente che ha una credenziale
• può usare uno user agent, componente software intermedio, per autenticarsi. potrebbe essere più o meno elaborato ovviamente
• canale di comunicazione
• servizio di autenticazione (server): composto dal fronted (API con cui interagisco) ed un db (con le credenziali degli utenti). Vediamo come ci potrebbero essere anche informazioni differenti rispetto alle credenziali di un utente e il suo account presente sul server

Abbiamo anche protocolli tipo Single-Sign On, Identity Federation (OpenID), Authorization delegation (OAuth), … che hanno sempre gli stessi componenti ma sono un po’ diversi. Parliamo anche di fattore di autenticazione: elemento che l’utente potrebbe usare per andare a identificare la propria identità. Identifichiamo anche delle macro categorie. Immaginiamo che l’utente abbia degli strumenti che sono proprio anche dei componenti fisici per poter accedere ad accedere al servizio: token usb o radio che ci fanno accedere. Il più grande metodo è quello basato sul segreto, quindi: pin e password che conosco solamente l’utente. L’ultimo metodo è una cosa che caratterizza l’utente: la firma, per esempio, su cui la sicurezza si basa sulla replicazione della firma essenzialmente. Abbiamo anche aspetti di autenticazione di tipo biometrico. Questi sono comodi, ma in contesti di altra sicurezza è molto vicino alla situazione di identificazione e non potrebbe essere sicuro, anche perché non possiamo andare a modificare tali valori. La famosa multi factor authentication, ci permette di andare ad usare più strategie e si ottiene un livello di strategie più alto soprattutto se uso strategie differenti: qualcosa che possiedo e qualcosa che conosco. Attenzione che in base ai contesti i fattori di autenticazione hanno delle aree di attacco e dei vincoli, possono diventare dei informazioni di possesso, anziché di conoscenza, quindi cambia la caratterizzazione di un fattore in base a come lo andiamo materialmente a gestire.

Dove possiamo fallire? L’attaccante potrebbe andare a compromettere a livello software anche lo user agente, potrebbe compromettere il canale di comunicazione, potrebbe cercare di interagire col servizio di autenticazione, ha una superficie di attacco in realtà ampia e dipende da che cosa vuole provare a fare. Potrebbe violare il servizio di autenticazione per effettuare un data breach delle credenziali, per cui ruba lato server delle informazioni. In base a che cosa vogliamo difenderci dipende che cosa vogliamo andare a fare. Solitamente sono ortogonali le soluzioni di difesa e attacco, invece a volte sono accoppiate. A volte non possiamo pensare ad un protocollo di scambio di credenziali senza pensare a come le chiavi sono conservate all’interno del db del server. Gli attacchi si possono fare ad ampio spettro, ma spesso dobbiamo andare a pensare il sistema nel complesso. Non posso dire di usare un MAC e fregarmene di che cosa o nel db delle credenziali, perché ho tutti aspetti strettamente accoppiati.

Che protocolli ho per autenticarmi e scambiarmi le informazioni necessarie per fare ciò su un canale di comunicazione?

se voglio di autenticare delle persone, user authentication, ho una strategia che riguarda l’autenticare il fatto che il servizio stia parlando con un utente umano oppure no: reCAPTCHA essenzialmente. Devo andare essenzialmente a fare un touring test. Relaizzare captcha efficaci diventa sempre più complicato, ma solitamente sono sempre le stesse cose:

• riconoscimento di simboli
• riconoscimento di immagini (reCAPTCHA), uso cose del mondo reale per vedere di capire con chi sto parlando

Fatto ciò posso mandare direttamente la credenziale segreta sul canale di comunicazione. A volte questa secret credential potrebbe anche essere una stringa random, una API key, una stringa random. A volte questa credenziale è chiamato beerer token, perché un token di autenticazione per cui presentare il token stesso è sufficiente per autenticarsi. Se in qualsiasi modo l’attaccante viola il canale la sessione è compromessa e l’attaccante può effettuare un analisi della informazione e accedere alla credenziale e loggarsi al tuo posto essenzialmente, fino a che non revoche le informazioni

Introduciamo il concetto di one time credential: anche se l’avversario intercetta una credenziale non è possibile andarla ad usare successivamente. Perché questo invalida ogni credenziale appena la vede. Teoricamente potrebbe autenticarsi comunque prima attaccando online, ma se è passivo ha sicuramente perso il treno. Aumenta la dimensioni delle credenziali lato client e lato serve co questo sistema e diminuisce il numero di volte i cui possiamo loggarci.