EUCIP IT Administrator Modulo 5 - Sicurezza Informatica 3 - Autenticazione e controllo di accesso Alberto Bosio AICA © 2005

Autenticazione Per un qualsiasi soggetto, l'autenticazione rappresenta l'atto di dimostrare la propria identità. I metodi a disposizione ricadono all'interno di queste tre casistiche: Il soggetto possiede qualcosa: chiavi elettroniche, chiavi hardware o smart card; Il soggetto conosce qualcosa: password o PIN; Il soggetto ha una determinata caratteristica o comportamento: biometria. E' bene chiarire che, visto le differenze sostanziali esistenti fra i vari metodi, utilizzare l'uno o l'altro dovrebbe sempre derivare da un'attenta analisi del bene da proteggere. AICA © 2005

Problema IDENTIFICAZIONE INIZIALE: Attacchi di Social Engineering mirano a prendere l'identità di qualcun'altro. Metodo classico, più usato, più facile e con maggiori successi !!! AICA © 2005

Principali metodi Procedure di identificazione (lato client) Login/password testuali Chiavi hardware Smartcard, chiavi USB, ... Sistemi biomedici Metodi di autenticazione Password Two Factor Athentication Certificati digitali Certificati digitali e Password policy Autenticazione biometrica AICA © 2005

Password Sistema più diffuso Richiede un solo fattore di identificazione Poco costoso Sistema debole Password guesting Sniffing delle password AICA © 2005

inghilterra -> 1ngH1ltE99a Password username+password: metodo classico per autenticazione su elaboratori Cambiare la password con ragionevole frequenza Scegliere una password facile a ricordarsi, lunga a sufficienza (almeno 8 caratteri), non banale: Password casuale Inserire numeri e maiuscole in una parola o frase: inghilterra -> 1ngH1ltE99a AICA © 2005

Password Mai usare la stessa password per due diversi elaboratori o username Mai usare password = username In Unix/Linux usare shadow file e MD5 Usare regolarmente un Password Cracker Se il file di password (cifrate) viene rubato/copiato, cambiare immediatamente tutte le password AICA © 2005

OTP (One-Time Passwords) Idea originale: Bell Labs sistema S/KEY implementazione di pubblico dominio implementazioni commerciali con generatori automatici hardware (autenticatore) AICA © 2005

Come fornire password OTP agli utenti? per uso su postazioni “stupide” o insicure: password pre-calcolate e scritte su un foglio autenticatori hardware (criptocalcolatrici) per uso su postazioni sicure e intelligenti: programmi di calcolo eventualmente integrati col sw (telnet, ftp, ...) o hw (modem) di comunicazione AICA © 2005

Il sistema S/KEY RFC-1760 l’utente sceglie un segreto S (il seme) l’utente calcola N one-time password: P1 = h (S) P2 = h (P1) = h( h(S) ) . . . l’utente inizializza il server di autenticazione con l’ultima password (es. P100) AICA © 2005

Il sistema S/KEY il server chiede le password in ordine inverso: P99? X h (X) = P100 ? memorizza X in questo modo il server non deve conoscere il segreto del client RFC-1760 usa MD4 (possibili altre scelte) implementazione public-domain per Unix, MSDOS, Windows, MacOs AICA © 2005

Problemi delle OTP scomode da usare in assoluto scomode da usare per accesso a servizi multipli basati su password (es. POP con check periodico della posta) costose se basate su autenticatori hardware non possono essere usate da un processo ma solo da un umano AICA © 2005

Problemi degli autenticatori hardware denial-of-service: tentativi falliti appositamente per negare l’accesso social engineering: telefonata per denuciare smarrimento e chiedere l’inizializzazione di una nuova carta AICA © 2005

Two Factor Athentication Più robusto della semplice password L’utente deve conoscere il proprio PIN L’utente deve possedere un dispositivo di autenticazione Token, SmartCard SmartCard: Carta elettronica dotata di una ROM e di un processore In grado di memorizzare i dati anagrafici e le chiavi private AICA © 2005

SmartCard Token: una chiave elettronica SmartCard: un mini processore su di una carta elettronica (formato carta di credito) in grado di memorizzare una Chiave Privata in forma cifrata È necessario un PIN per decifrare la Chiave Privata che poi usa per cifrare i dati in ingresso Data un'Impronta genera una Firma Digitale Autentica usando challengeresponse (nonce) AICA © 2005

SmartCard Carta + PIN: due modi di autenticazione Sicuro quanto è sicuro l'elaboratore a cui si collega (esistono già attacchi che permettono di prendere possesso della SmartCard e farle firmare ciò che si vuole (un contratto, un bonifico ...), per debolezza degli applicativi e del Sistema Operativo dell'elaboratore; compariranno nei prossimi Virus per Windows? ) AICA © 2005

Certificati digitali Problemi legati alla sicurezza Il certificato è memorizzato su disco rigido AICA © 2005

Certificati digitali e Password policy Maggior livello di protezione quando vengono emmessi da una CA Verifica dell’identità dell’utente Gestione centralizzata dei certificati Regole per le password (almeno 10 caratteri) AICA © 2005

Autenticazione biometrica Riconoscimento di caratteristiche uniche dell’individuo: Retina Impronta digitale Voce Volto ... AICA © 2005

Autenticazione biometrica Simile a Token o SmartCard, ma invece di un oggetto viene verificato: L'impronta digitale L'iride I lineamenti del viso ... Si può associare ad un Token con PIN per ottenere tutti i 3 metodi di autenticazione Attenzione: è controverso quanto la biometria sia sicura se usata da sola AICA © 2005

Sistemi di autenticazione di rete Problematiche Il passaggio di credenziali via rete deve essere protetto Crittografato Credenziali one-time Challenge response Esempi: Unix : utilizzo di password cifrate (algoritmo crypt) registrate in /etc/passwd Max 8 caratteri Utilizzo shadow password (hash MD5) /etc/shadow AICA © 2005

Autenticazione in rete : Protocolli PAP Password Authentication Protocol Password in chiaro CHAP Challenge Handshake Authentication Protocol Sfida simmetrica EAP Extensible Authentication Protocol Aggancio a meccanismi esterni (sfide…) AICA © 2005

PAP Password Authentication Protocol RFC-1334 User-id e password inviate in chiaro Autenticazione solo all’attivazione del collegamento Pericoloso! AICA © 2005

CHAP RFC-1994 “PPP Challenge Handshake Authentication Protocol (CHAP)” Meccanismo a sfida simmetrico (basato sulla password) Sfida iniziale obbligatoria, possibile ripetere la richiesta (con sfida diversa) durante la comunicazione Chi supporta sia CHAP sia PAP, deve prima offrire CHAP Provider AICA © 2005

EAP RFC-2284 “PPP Extensible Authentication Protocol (EAP)” Framework flessibile di autenticazione a livello data-link Tipi di autenticazione predefiniti: MD5-challenge (simile a CHAP) OTP generic token card Altri tipi possono essere aggiunti: RFC-2716 “PPP EAP TLS authentication protocol” RFC-3579 “RADIUS support for EAP” AICA © 2005

OTP Le OTP (One time Password In Everything) sono delle parole chiave utilizzate ai fini di autenticazione che hanno validità per una sola specifica login Non esiste il problema che siano compromesse, in quanto come sono usate non sono più valide. Le OTP vengono generate a partire da una passphrase, un seed (seme), e un numero di sequenza che ad ogni login viene decrementato, fino a quando non arriverete a 0 e sarà quindi necessario generare un nuovo numero di sequenza. AICA © 2005

Autenticazione Tramite Token Security Token Service: servizio che rilascia i token (credenziali di autorizzazione ed autenticazione) sulla base delle informazioni (proof of identity) fornite dal Policy Decision Point. AICA © 2005

Autenticazione Tramite Token Il Consumer ottiene la risorsa, previa autenticazione tramite un terzo attore di cui entrambe le parti (Seller e Consumer) ripongono fiducia. Questo modello generale supporta diversi modelli più specifici: liste di controllo accessi (ACL), identity management, Etc… permette l'utilizzo di tecnologie esistenti i certificati a chiave pubblica X.509, ticket Kerberos condivisi password digests. AICA © 2005

Autenticazione per applicazioni distribuite RPC: Remote Procedure Call Nasce su UNIX, un processo in esecuzione su un host può chiedere l’esecuzione di una procedura da parte di un processo eseguito su un altro host I servizi di rete sono visti come una collezione di uno o più programmi remoti Ciascun programma remoto implementa una o più procedure remote Le chiamate e i paramtrei sono specificate nei protocolli AICA © 2005

Remote Procedure Call Esempio : Sistema RPC in ambiente SUN Il client invia un messaggio di richiesta Call message : sono inclusi i parametri della procedura Il client aspetta (bloccato) la risposta del server Reply message : sono inclusi i risultati della procedura L’autenticazione è mutua: Il mess. del client contiene : Credenziale, verificatore Il mess. del server contiene : Verificatore di risposta AICA © 2005

Remote Procedure Call Ogni campo è costituito da: Flavor : contiene valori (NULL, UNIX, SHORT o DES) Body : fino a 400 byte di informazioni di autenticazione flavor body AICA © 2005

Remote Procedure Call UNIX: client : credenziale: Identificatore della transazione Nome della workstation UID GID Verificatore: NULL server : convalida le credenziali, risponde con NULL o SHORT Verficatore : SHORT : fornisce al client un codice per una successica autenticazione AICA © 2005

Remote Procedure Call Problemi: Schema di autenticazione DES: Non esite controllo sulle credenziali del client ! Schema di autenticazione DES: Sulle macchine deve essere attivo il demone keyserv (sia client che server) L’utente deve avere una coppia di chiavi La pubblica è disponibile sul server di amministrazione della rete Consente l’autenticazione mutua del client e del server Un campo verificatore contiene un timestamp cifrato dal client e decifrato dal server AICA © 2005

Single Sign on Problema: Architettura Single Sign-On (SSO) Rete eterogenea (windows, unix, machintosh, ...) richiede l’utilizzo di molteplici login e password per i diversi sistemi Necessità continua di autenticarsi su differenti servizi Architettura Single Sign-On (SSO) Consente all’utente di autenticarsi un’unica volta per poi accedere a tutti i servizi cui l’utente è accreditato AICA © 2005

Kerberos Sviluppato da IBM e MIT nel 1983 Realizza un meccanismo SSO Il cane mitologico kerberos aveva 3 teste Autenticazione Autorizzazione Accounting Standardizzato in RFC 1510 AICA © 2005

Kerberos Usa un sistema di autenticazione di tipo trusted third party I soggetti (principal) sono Utenti Servizi I soggetti si autenticano tra loro tramite un server centrale KDC (Key Distribution Center) AICA © 2005

Kerberos Un principal è un’entità alla quale un autenticatore kerberos può assegnare dei ticket Ogni principal è identificato da un nome univoco Costituito da tre sezioni Primary/instance@realm AICA © 2005

Kerberos Dove: Primary : identifica il principal Nel caso di un utente il primary è lo username dell’utente stesso Instance : completa il primary (può essere NULL) stefano@realm stefano/autore@realm Realm : indica l’ambiente (rete o dominio) gestito dal KDC Si usa il nome del dominio in caratteri maiusculi alberto@KERBEROS.ESEMPIO.ORG AICA © 2005

Kerberos : funzionamento Un principal (un utente) invia una richiesta di autenticazione al KDC Il KDC crea ul TGT (Ticket Granting Ticket) e lo invia al principal Cifrato con la chiave pubblica del principal Se il principal vuole autenticarsi presso un altro principal (server) invia il TGT al KDC Il KDC risponde (al principal) con credenziali valide per l’autenticazione a quel server Cifrate con la chiave del richiedente Ticket + chiave temporanea (chiave di sessione) Il principal trasmette un ticket al server Identità + authenticator (timestamp e chiave di sessione) AICA © 2005

Kerberos : funzionamento Il server ottiene dal KDC la chiave di sessione per quel ticket e la verifica L’autenticazione può anche essere mutua (two-way) Il server si identifica a sua volta al client AICA © 2005

Kerberos : struttura Due servizi indipendenti Authentication Server (AS) : gestisce il database delle chiavi Fornisce il TGT Ticket Granting Server (TGS) : verifica i TGT rispondendo con chiavi di sessione AICA © 2005

Kerberos : struttura AICA © 2005

Kerberos Può essere utlizzato per autenticazioni tra realm diverse Ogni realm ha un KDC server Autentica i propri principal Esistono chiavi inter-realm tra i server KDC Il KDC del realm A diviene un principal per il KDC del realm B e viceversa AICA © 2005

Controllo D'accesso DAC (Discretionary Access Control) : controllo di accesso discrezionale. Concessione e revoca dei diritti di accesso a discrezione degli utenti Utenti Gruppi di utenti Esiste un super utente (amministratore) che può modificare i permessi dei files senza sottostare a vincoli AICA © 2005

Controllo D'accesso MAC (Mandatory Access Control) : controllo di accesso obbligatorio. Sistemi ad alta sicurezza Amministratore che definisce l’accesso a seconda del tipo risorsa e del livello di sicurezza desiderato. RBAC (Role-based Access Control) : controllo di accesso basato sui ruoli. Simile al MAC, ma l’accesso dipende dal ruolo dell’utente in quanto facente parte di un organizzazione. È l’organizzazione non l’individuo a possedere la risorsa. AICA © 2005

Controllo D'accesso Controllare l'accesso alle risorse (lettura di dati, scrittura, esecuzione di un programma, utilizzo di una struttura hardware ...) mediante la definizione di privilegi. Metodo più semplice ACL (Access Control List) che definiscono quali sono le azioni che possono essere condotte su ogni risorsa da parte di un utente. Problemi : Ogni azienda possiede policy di sicurezza proprie spesso supportate da tecnologie differenti. La gestione dei diritti di autorizzazione estesa su più sistemi e tecnologie. WS-Security definisce un layer di astrazione che permette a infrastrutture differenti di "cooperare in piena fiducia". AICA © 2005

Database e Controllo D'accesso MySQL RDBMS (Relational Database Management System) Il controllo degli accessi avviene tramite grant table Tabelle di sistema che mantengono informazioni sugli utenti TABELLA INFORMAZIONI User Utenti registrati Db Db ai quali può accedere un utente Host Host dai quli ci si può connettere Tables_priv Priviliegi a livello tabella Colums_priv Priviliegi a livello colonna AICA © 2005

Database e Controllo D'accesso MySQL I privilegi sono concessi e/o revocati tramite i comandi Grant Revoke Modificando a mano (con i comandi SQL) le grant table Occorre ricaricare le tabelle con i comandi mysqladmin reload, mysqladmin flushprivileges AICA © 2005

Database e Controllo D'accesso SQL server Necessaria autenticazione attraverso il SO su cui è installato SQL server Due modalità di autenticazione Windows Authntication Mode : gli utenti locali non forniscono user e pass in quanto sono già autenticati da windows Occorre solo specificare i privilegi delgi utenti Mixed Mode : creo un account di login, salvati nella tabella syslogins AICA © 2005

Database e Controllo D'accesso SQL server Privilegi basati sui ruoli Un ruolo è una collezione di privilegi Assegnare all’utente un ruolo implica assegnare tutti i privilegi assegnati a quel ruolo Tre categorie di ruoli Public role : stabilisce i permessi di default Non può essere eliminato Fixed server roles : ruoli predefiniti trasversali ai vari database Non sono modificabili e non èà possibile aggiungerne di nuovi Fixed database roles : validi all’interno del contesto di un singolo database Ruoli predefiniti non modificabili, concessi agli account utente AICA © 2005

Database e Controllo D'accesso SQL server User defined database roles : è possibile creare nuovi ruoli Validi sui singoli database Application roles : ruoli per l’accesso ai dati dipendednti dalle applicazioni Si creano i ruoli e i permessi associati all’applicazione L’applicazione attiverà sp_setapprole per ottenere i permessi Non posso attribuirli al singolo utente In SQL server oltre a grant e revoke esiste anche il privelgio deny Nega un accesso anche se esiste un grant che lo consentirebbe AICA © 2005