ESP - Lezione del 23 Ventoso 216

 :: Lezione del 23 Ventoso 216 ::

... altrimenti noto come 13 marzo 2008

Torna alla pagina di ESP

Autenticazione

L'autenticazione in Apache in genere avviene semplicemente tramite una coppia login - password, memorizzata ed inviata in chiaro. Il file .htaccess che si può creare in ogni dir servita da Apache specifica gli utenti e i loro privilegi.

Si può anche decidere di crittare le password, per dare quel tocco di sicurezza in più che non guasta mai. A questo scopo Apache utilizza il sistema digest, ovvero un hash MD5 di nome utente, dominio e password, più un certo numero detto nonce che il server passa al client, e viene usato per rendere ancora più univoche le stringhe MD5. Viene passata al server la stringa risultata da questa funzione:

 MD5(MD5(<password>)+":"+<nonce>+":"+MD5(<method>+":"+<uri>))

L'unico problema è che non tutti i browser supportano il digest di Apache, quindi non è utilizzato in generale.

Nota: MD5 è una funzione di hash crittografico, che offre ben poche possibilità che due stringhe in input producano lo stesso hash.

Token Hardware

Si tratta di un aggeggio fisico, nato come evoluzione del sistema One Time Password. Questo aggeggio viene sincronizzato con un server, e in base al timestamp viene generato, a partire da un PIN e da un seme ignoto all'utilizzatore ma noto al server, una certa password. Il server la genera per conto suo: se coincidono, siamo tutti felici e contenti.

Identify Friend Or Foe = IFF

IFF (Ingoio Frutti Fallici) è un sistema di Challenge Response, nato all'inizio per scopi militari: identificare come nemici o amici gli aerei che viaggiavano nello spazio aereo americano al di sopra di una certa quota. Anzi, il sistema Challenge Response è stato modellato sull'IFF.

Viene fatta una certa domanda, e se l'aereo è amico, sa rispondere nel modo giusto. Per aggiungere un layer di sicurezza si crittano entrambi i flussi di informazioni. Le domande avvengono sui 1030 Mhz, le risposte sui 1090 Mhz.

Ma c'è il problema del Man in the Middle. Supponiamo che l'aereo A sia amico, e il B nemico. A invia una domanda a B. B, invece di rispondere, replica la stessa domanda ad A. A, al ricevere la domanda, invierà la risposta. B riceve la risposta, e quindi sa che cosa rispondere ad A per spacciarsi come amico:) Per questo occorre che ci si autentichi in qualche modo, incorporando ID dell'aereo e cose simili, per evitare casini.

SINGLE SIGN ON

Internet è fatta di tanti servizi sparsi qua e là, sistemi distribuiti a più non posso. Ogni servizio richiede in genere che uno si iscriva e che poi ad ogni utilizzo si autentichi. Capita quindi di dover iscriversi a decine di cose diverse, con decine di account e password diverse. Questo significa 2 cose:

• i miei dati sono noti a tanti siti diversi;
• ho tante password in giro, il che vuol dire che per non dimenticarle le faccio tutte uguali, con gli ovvi problemi di sicurezza che ciò comporta.

Allora si è pensato bene di inventare sistemi Single Sign On, in cui i servizi distribuiti cooperano e si rifanno tutti ad una singola credenziale.

Deve quindi esserci un dominio principale, che è quello dove effettivamente io mi registro, e i domini secondari devono ripescare le mie info da quello principale. Quindi, la mia login viene effettuata solo sul dominio principale. È poi il dominio principale a comunicare ai secondari che l'autenticazione è riuscita.

Ci sono due modi di implementare questo sistema: farlo centralizzato o creare una federation.

SSO centralizzato

Un'entità ha tutti i miei dati, e va quindi ben protetta. I secondari si rivolgono a lei e si scambiano info sull'autenticazione tramite protocolli come SAML (Security Assertion Markup Language) e SOAP (un protocollo per scambiarsi messaggi in XML, usando in genere HTTP come trasporto, ma anche SMTP, volendo).

SAML contiene delle asserzioni, cioè delle affermazioni che possono essere:

• di autenticazione: identifica un utente;
• di attributi: trasportano caratteristiche di un utente, eg il suo numero di carta di credito;
• di permessi: dicono che cosa un utente può fare.

Di per sé SAML non autentica niente, serve solo per trasportare info su di un utente.

Microsoft .NET Passport

Microsoft ha inventato il sistema Passport, che è un SSO centralizzato, e qui vediamo un po' come funziona.

La registrazione avviene al server centrale Passport. Ogni utente da questa registrazione riceve un PUID, cioè un Password User ID. I siti esterni che si rifanno a Passport non ricevono info di autenticazione da parte del server Passport centrale, ma solo messaggi che dicono "Ok, l'auth è andata a buon fine".

La registrazione si cerca di fare che sia il più sicura possibile. Si utilizza il CAPTCHA, ovvero una forma di Challenge Response per umani. Il CAPTCHA lo conoscete tutti: spesso sarà capitato di doversi iscrivere ad un sito e di dover inserire le lettere tutte storte e deformate che appaiono. In pratica si tratta di un test di Turing, ma all'incontrario: il test di Turing serviva per distinguere le macchine dagli umani, qui serve per distinguere gli umani dalle macchine. Sono immagini fatte in modo tale che solo un uomo possa distinguerle, così da evitare registrazioni automatiche. In realtà poi diversi di questi CAPTCHA sono stati crackati, ma è un'altra storia. Infine, si invia un'email per la conferma della registrazione.

Quando entro su di un sito partecipante, iscritto a Passport, questo sito mi rinvia appunto alla pagina di login di Passport. Se tutto va bene, Passport invierà a me 3 cookie criptati, i quali conterranno:

• il mio PUID e il timestamp (perché dopo un po' la mia auth scadrà);
• le mie info di profilo;
• i siti che ho precendentemente visitato!

La storia dei siti precedentemente visitati è stata giustificata dicendo che magari un certo sito non vuole che un utente abbia visitato precedentemente la concorrenza.

Tanto per fare un po' di storia, Passport è stato abbandonato a favore di Windows Live ID, e quest'ultimo non è più spacciato per SSO ma è offerto come un sistema di autenticazione tra gli altri. Passport aveva delle falle di sicurezza che permettevano di rubare un'identità tramite un semplice browser (!!). Inoltre, come al solito con Microsoft, la prima versione della licenza permetteva a Microsoft di disporre dei dati personali degli utenti. La faccenda dei siti precedentemente visitati, a mio, avviso, si spiega facendo riferimento al mercato fiorente che riguarda le abitudini degli internauti. Per le aziende che operano su Internet è di fondamentale importanza sapere esattamente che gusti ho, per potermi venire incontro meglio. Questo è ciò a cui le varie Licenze di servizi di posta etc. si riferiscono quando parlano di utilizzo da parte di società dei nostri dati a fini commerciali etc. etc.

Ma torniamo a noi. Questi tre cookie infami vengono crittati, e siccome vengono memorizzati sul computer dell'utente, il sito affiliato può recuperarli se gli servono.

Siccome i cookie sono sì crittati, ma il canale di trasporto su cui viaggiano no, in genere si usa SSL (Secure Socket Layer) per queste comunicazioni. Ma c'è dell'altro. L'autenticazione di primo livello è composta semplicemete da una coppia login - password. Quella di secondo livello invece tira in ballo un PIN, che in modo simile ai PIN dei cellulari posso sbagliare al max 5 volte di fila. Se sbaglio 5 volte, allora mi vengono fatte 3 domande tra le 10 che ho creato in fase di registrazione. E adesso potete dare un nuovo significato alla parola paranoia.

Ovviamente, siccome tutto è centralizzato, Passport ha un single point of failure. Ecco qualche interessante metodo per aggirare tutto questo bailamme.

Attacco passivo: io, Bad Guy, creo un sito che assomiglia in tutto e per tutto a quello di Passport, ma magari con un indirizzo lievemente diverso (eg Pasport con una s sola). L'utente poco avveduto si registrerà presso di me:)

Attacco attivo:: il cattivone si inserisce nel canale di comunicazione tra utente e sito affiliato a password, e crea una copia per sé delle info che l'utente invia a password.

Attacco DNS:: inquino i record DNS del mio utente, così che quando viene indirizzato a www.passport.com, l'IP è quello del mio server cattivone, il quale offre la stessa interfaccia.

SSO Federation

Per evitare la centralizzazione, si è pensato di dividere i dati sensibili di un utente in più domini. Ciascun dominio possiede una mia identità parziale, mentre l'unione di tutte le mie identità parziali dà luogo alla mia identità di rete. Tutti questi domini devono però essere collegati tra di loro in una sorta di Federazione Interstellare.

Una di queste federazioni è Liberty Alliance, la quale ha creato un circle of trust tra chi aderisce. Si possono creare diversi circoli, e questi possono essere messi in comunicazione tra di loro, così che le mie auth viaggino un po' dappertutto.

Torna alla pagina di ESP