Usabilità e sicurezza
Immaginate queste due entità, sicurezza e usabilità, distribuite sui due piatti di una bilancia. L'introduzione di misure di sicurezza può alle volte diminuire l'usabilità, o meglio l'Interazione Uomo-Macchina (Human Computer Interaction), dei sistemi o delle applicazioni. Bisogna fare attenzione quindi a bilanciare opportunamente le due entità. Le migliori soluzioni di sicurezza infatti sono quelle trasparenti agli utenti che non li obbligano a distogliere la loro attenzione dai compiti principali.
L'esempio classico è quello delle password.
E' indubbio che le password migliori siano quelle più complesse da scoprire con tecniche di brute forcing, attacco del dizionario, rainbow-table. etc. Ma se sono troppo complesse il nostro povero utente sarà costretto a scriverle da qualche parte e allora la sicurezza si andrà a far benedire. Già con le passphrase ci avviciniamo ad una soluzione sicura ma più "usabile" per gli utenti. Le passphrase infatti sono frasi di senso compiuto, prese magari da libri, film o altro, che risultino di facile memorizzazione e che comunque abbiano una lunghezza sufficiente per proteggersi dagli attacchi più comuni.
Caso opposto è invece il browser Internet Explorer 7. Se il server ha un certificato non trustato dal browser, IE7 adotta una politica completamente diversa: una bella schermata "terroristica" con tanto di barra della URL del browser rossa se poi si decide di procedere.
L'ultimo esempio è quello del "SU" Linux o dell'UAC Microsoft.
Uno dei principi della sicurezza informatica è quello del "minimo privilegio". Un'applicazione deve eseguire il proprio codice con il minor privilegio possibile.
Le applicazioni, che sono in esecuzione in una sessione utente di un applicazione interattiva o di un servizio o demone, avranno quindi i diritti dell'utenza che ha attivato tale sessione.
E' quindi buona norma aprire sessioni con utenti non privilegiati e solo quando si debbano eseguire applicazioni particolari con maggiori privilegi, inserire le credenziali di un super utente o dell'amministratore, innalzando quindi il privilegio del processo associato all'applicazione.
In questo modo quindi la sessione ha quasi sempre i diritti dell'utente che l'ha attivata, tranne quando è strettamente necessario eseguire applicazioni particolari, rispettando quindi il principio del minimo privilegio.
Anche in questo caso si è aumentato il livello di sicurezza diminuendo però l'usabilità. Per quello che riguarda Microsoft, in Windows XP o Windows 2000 a differenza di VISTA che invece implementa lo UAC, l'usabilità era massima perché l'utente era quasi sempre amministratore. Ma la sicurezza purtroppo era minima!
Adesso anche l'utente dovrà fare i conti con un livello di sicurezza più alto che però gli porterà un po' più di noie per questi bei pop-up.
In Linux, come dice Joel Spolsky, un sistema fatto dai programmatori per i programmatori, poco male se bisogna scrivere 4 caratteri in più per eseguire un comando da shell :-)
Questi pochi esempi ci danno quindi la percezione di come sia difficile implementare soluzioni di sicurezza che mantengano anche alto il livello di usabilità dei sistemi o delle applicazioni. Alle volte ci sono dei vincoli tecnici derivanti dai meccanismi sottostanti. Vedasi la rigidità delle PKI rispetto al trusting delle catene dei certificati.
Di esempi ce ne sono ancora tanti e il post sta diventando troppo lungo, ma se vi interessa l'argomento vi consiglio questo libro. Gli autori sono di tutto rispetto sia nel campo dell'HCI che della sicurezza informatica:
L'esempio classico è quello delle password.
E' indubbio che le password migliori siano quelle più complesse da scoprire con tecniche di brute forcing, attacco del dizionario, rainbow-table. etc. Ma se sono troppo complesse il nostro povero utente sarà costretto a scriverle da qualche parte e allora la sicurezza si andrà a far benedire. Già con le passphrase ci avviciniamo ad una soluzione sicura ma più "usabile" per gli utenti. Le passphrase infatti sono frasi di senso compiuto, prese magari da libri, film o altro, che risultino di facile memorizzazione e che comunque abbiano una lunghezza sufficiente per proteggersi dagli attacchi più comuni.
Un altro esempio è quello dei certificati pubblico-privati per gestire transazioni bancarie
Le prime soluzioni di autenticazione forte basate su PKI, prevedevano l'installazione di applicazioni proxy sul proprio computer oppure altre soluzioni bizzarre, che obbligavano a consultare il proprio conto solo dalla propria macchina. Con notevoli difficoltà di installazione e configurazione di questi "accrocchi". All'atto della configurazione, sulla macchina si memorizzava il certificato pubblico, con relativa chiave privata, che autenticava di fatto il client con il server nella transazione bancaria.
Con l'introduzione di meccanismi di autenticazione basati invece su One Time Password e Token per la loro generazione, la sicurezza dei conti on-line è divenuta per fortuna più usabile e con un alto livello di sicurezza.
Le prime soluzioni di autenticazione forte basate su PKI, prevedevano l'installazione di applicazioni proxy sul proprio computer oppure altre soluzioni bizzarre, che obbligavano a consultare il proprio conto solo dalla propria macchina. Con notevoli difficoltà di installazione e configurazione di questi "accrocchi". All'atto della configurazione, sulla macchina si memorizzava il certificato pubblico, con relativa chiave privata, che autenticava di fatto il client con il server nella transazione bancaria.
Con l'introduzione di meccanismi di autenticazione basati invece su One Time Password e Token per la loro generazione, la sicurezza dei conti on-line è divenuta per fortuna più usabile e con un alto livello di sicurezza.
Questa soluzione a mio parere è come sicurezza allo stesso livello del certificato pubblico e chiave privata installata sulla propria macchina. Del resto se un certificato privato risiede su un disco rigido, non è che la sicurezza sia elevatissima! Di solito, per gestire soluzioni di autenticazione forte con PKI, si preferiscono come supporti di memorizzazione token sicuri quali chiavi USB certificate, smartcard o anche HSM .
Prendiamo adesso il caso della navigazione web su protocollo HTTPS.Quando un browser Web si connette ad un server con protocollo HTTPS, nella fase di handshaking del protocollo come prima, e di solito unica autenticazione, c'è quella del server verso il client.
Il client cioè deve potersi fidare del server a cui si connette.
all'interno del browser stesso. Se esiste, allora procede (a meno che il sito a cui ci si connette non preveda anche l'autenticazione del Il server come prima cosa invia il proprio certificato pubblico al client. Il client verifica che tale certificato sia stato emesso da una CA attendibile e per la quale vi sia un certificato rootclient) con la negoziazione della chiave simmetrica per la cifratura del canale. Altrimenti, come estrema ratio, il browser delega all'utente il trusting del certificato server con una serie di pop-up che visualizzano le caratteristiche del certificato e chiedono all'utente se questo sia valido o meno.
Il client cioè deve potersi fidare del server a cui si connette.
all'interno del browser stesso. Se esiste, allora procede (a meno che il sito a cui ci si connette non preveda anche l'autenticazione del Il server come prima cosa invia il proprio certificato pubblico al client. Il client verifica che tale certificato sia stato emesso da una CA attendibile e per la quale vi sia un certificato rootclient) con la negoziazione della chiave simmetrica per la cifratura del canale. Altrimenti, come estrema ratio, il browser delega all'utente il trusting del certificato server con una serie di pop-up che visualizzano le caratteristiche del certificato e chiedono all'utente se questo sia valido o meno.
Quanti utenti sono in grado di capire se il certificato è effettivamente di un'autorità valida? Pochi! Ecco quindi una soluzione abbastanza usabile (di solito l'utente preme "Sì" non comprendendo bene le cause di questa sua decisione) ma scarsamente sicura.
Caso opposto è invece il browser Internet Explorer 7. Se il server ha un certificato non trustato dal browser, IE7 adotta una politica completamente diversa: una bella schermata "terroristica" con tanto di barra della URL del browser rossa se poi si decide di procedere.
Esempio di soluzione indubbiamente più sicura (almeno dal punto di vista preventivo) ma scarsamente usabile.
Uno dei principi della sicurezza informatica è quello del "minimo privilegio". Un'applicazione deve eseguire il proprio codice con il minor privilegio possibile.
Le applicazioni, che sono in esecuzione in una sessione utente di un applicazione interattiva o di un servizio o demone, avranno quindi i diritti dell'utenza che ha attivato tale sessione.
E' quindi buona norma aprire sessioni con utenti non privilegiati e solo quando si debbano eseguire applicazioni particolari con maggiori privilegi, inserire le credenziali di un super utente o dell'amministratore, innalzando quindi il privilegio del processo associato all'applicazione.
Con "SU" (nei sistemi linux) anteposto alla riga di comando da eseguire, bisogna inserire le credenziali di un super utente per eseguire l'applicazione presente nella riga stessa. Applicazione che richiede particolari privilegi.
Simile meccanismo viene adottato da "SUDO" che, invece di richiedere le credenziali di un superutente, richiede la password dell'utente loggato. L'utenza viene abilitata a particolari operazioni privilegiate attraverso un file di configurazione che definisce i "Sudoers", ovvero le utenze abilitate ad eseguire operazioni privilegiate (definendo anche quali). Il vantaggio del SUDO rispetto al SU è che l'utente non deve conoscere le credenziali di una superutenza. Basta che l'Amministratore di sistema configuri opportunamente il file di configurazione di SUDO.
Del tutto simile è l'UAC, User Account Control, di Microsoft.
In questo modo quindi la sessione ha quasi sempre i diritti dell'utente che l'ha attivata, tranne quando è strettamente necessario eseguire applicazioni particolari, rispettando quindi il principio del minimo privilegio.
Sicuramente questa soluzione non fa altro che aumentare la sicurezza del sistema, ma provate ad immaginare quanto possa essere contenta la "Zia Pina" che ad ogni tot di tempo dovrà inserire una password per far partire la sua applicazione preferita!
Anche in questo caso si è aumentato il livello di sicurezza diminuendo però l'usabilità. Per quello che riguarda Microsoft, in Windows XP o Windows 2000 a differenza di VISTA che invece implementa lo UAC, l'usabilità era massima perché l'utente era quasi sempre amministratore. Ma la sicurezza purtroppo era minima!
Adesso anche l'utente dovrà fare i conti con un livello di sicurezza più alto che però gli porterà un po' più di noie per questi bei pop-up.
In Linux, come dice Joel Spolsky, un sistema fatto dai programmatori per i programmatori, poco male se bisogna scrivere 4 caratteri in più per eseguire un comando da shell :-)
Questi pochi esempi ci danno quindi la percezione di come sia difficile implementare soluzioni di sicurezza che mantengano anche alto il livello di usabilità dei sistemi o delle applicazioni. Alle volte ci sono dei vincoli tecnici derivanti dai meccanismi sottostanti. Vedasi la rigidità delle PKI rispetto al trusting delle catene dei certificati.
Di esempi ce ne sono ancora tanti e il post sta diventando troppo lungo, ma se vi interessa l'argomento vi consiglio questo libro. Gli autori sono di tutto rispetto sia nel campo dell'HCI che della sicurezza informatica:
Commenti
Posta un commento