Security WatchPassword e carte di credito - Parte 2

Jesper M. Johansson

Indice

Processo di pseudo accesso a più fattori
Problemi con componenti aggiuntivi del browser
L'autenticatore non deve mai cambiare
Passare a password meno sicure
Ignorare lo pseudo accesso a più fattori
Problemi con password compromesse
Alcuni vantaggi
Immagini utilizzate per ingannare gli utenti
Aprire o non aprire
Fornire comunicazioni protette
È una questione di privacy

Benvenuto nella seconda delle tre parti di questa serie. Lo scopo di questa serie di articoli è dare uno sguardo a come talvolta gli esperti informatici confondono gli utenti piuttosto che aiutarli ad affrontare i problemi relativi alla sicurezza. Nell'edizione di luglio 2008 di TechNet Magazine, ho parlato di alcuni consigli sulle questioni di sicurezza che risultano inesatti e impraticabili. Ho inoltre discusso dei flussi di lavoro relativi alle fasi di accesso che appaiono confusionari. (Qualora non si fosse letta la prima parte, essa è ancora disponibile a questo indirizzo

technet.microsoft.com/magazine/cc626076.). Mi sono soffermato su due delle cause che generano confusione negli utenti e che costituiscono minacce per la loro sicurezza informatica. Per prima cosa ho parlato di quei consigli che vengono spesso dati e che si farebbe bene a ignorare. In secondo luogo ho discusso quei flussi di lavoro relativi ai processi di accesso che risultano poco chiari.

In questa parte continuerò quella discussione, portando altri esempi reali tratti dal mondo della protezione degli utenti. L'ultima parte di questa serie, che conterrà una vera e propria "chiamata alle armi" rivolta ai professionisti mondiali della sicurezza, verrà pubblicata nel prossimo numero di TechNet Magazine.

Processo di pseudo accesso a più fattori

Nell'ottobre 2005, il Federal Financial Institutions Examination Council (organo con compiti simili alla CONSOB) ha pubblicato le linee guida sulle modalità di autenticazione utilizzate nei servizi di banking online (vedere www.ffiec.gov/press/pr101205.htm). Il tempo a disposizione per l'implementazione di quelle linee guida era stato fissato a 14 mesi e le istituzioni finanziarie americane si sono date subito da fare per cercare di mettersi in linea con quelle indicazioni.

La maggior parte delle istituzioni non fu in grado di rispettare quella scadenza. Quelle che invece riuscirono in qualche modo a osservare tali indicazioni, applicarono delle misure il cui unico effetto era quello di rispettare le nuove normative. In altre parole, applicarono delle misure che in nessun modo garantivano ai consumatori un maggiore livello di sicurezza (semplicemente delle "misure di facciata"). Tra gli esempi di soluzioni inutili più interessanti, ci sono sicuramente quelli che riguardano l'autenticazione, solo apparentemente, a più fattori.

Ad esempio, prendiamo la tecnologia che misura la velocità di digitazione della password da parte di un utente. Utilizzata in un sito Web, questa soluzione si presenta esattamente come una finestra di dialogo di accesso tradizionale. Tuttavia, questa finestra di dialogo è costituita da un oggetto Adobe Flash.

L'oggetto di Flash registra la velocità con la quale l'utente digita e altre caratteristiche, come ad esempio per quanto tempo è stato premuto un tasto o l'intervallo esatto intercorso fra la digitazione di un tasto e un altro. Questi dati vengono inoltrati al sito Web insieme alla password e confrontati con i valori in archivio. Se la velocità rientra entro certi limiti memorizzati e la password digitata è quella corretta, l'accesso viene eseguito. L'idea che sta alla base di questa pratica è permettere al sito di utilizzare un metodo di accesso pseudo biometrico, senza la necessità di installare componenti hardware di terze parti da parte dell'utente.

Prenderò appunto questo come esempio di pseudo autenticazione a più fattori. Non si tratta infatti di un vero accesso a più fattori. Per essere tale essa dovrebbe prevedere la misurazione di almeno due dei seguenti fattori standard:

• Qualcosa che l'utente possiede (ad esempio una smart card)
• Qualcosa che l'utente sa (ad esempio una password)
• Qualcosa che l'utente possiede naturalmente (ad esempio le impronte digitali)

Piuttosto che sfruttare fattori multipli durante l'accesso, metodi come quello descritto in precedenza registrano più caratteristiche che sono tuttavia derivate da un solo parametro: la password. E quindi utilizzano questi parametri aggiuntivi per cercare di definire una caratteristica innata dell'utente.

La tecnologia utilizzata per lo pseudo accesso a più fattori presenta molti difetti che. Se presi tutti insieme, tali fattori rendono la tecnologia rendono ampiamente inefficace contro i problemi che si pone di risolvere.

Problemi con componenti aggiuntivi del browser

I sistemi di pseudo accesso a più fattori sfruttano alcuni componenti aggiuntivi del browser per eseguire la complessa elaborazione richiesta dal lato client. Tutti i software, si sa, contengono dei bug e alcuni di questi possono esporre l'utente ad alcune vulnerabilità. Queste possono realmente costituire un problema quando il software è difficile da aggiornare e l'utente non è sicuro di avere installato un determinato aggiornamento.

I componenti aggiuntivi del browser presentano entrambi questi difetti: sono difficili da aggiornare e non comunicano all'utente se la versione installata è la più recente o meno. Di conseguenza, l'utente è costretto a esporre, forse inutilmente, determinate porzioni di software su Internet.

In alcuni casi, per mantenere il componente aggiuntivo aggiornato è necessario visitare regolarmente il sito Web del produttore. È scontato dire che questo non avviene per la maggior parte degli utenti. Qualsiasi sistema che, al fine di offrire funzionalità di sicurezza, espone altri software aggiuntivi dell'utente su Internet, dovrebbe essere maneggiato con molta attenzione.

L'autenticatore non deve mai cambiare

La caratteristica "che l'utente possiede naturalmente" presenta un tratto, anche un difetto se si vuole, che non ha impatto sugli altri due fattori. Mentre è possibile modificare una password (qualcosa che l'utente sa) e produrre nuovi dispositivi di sicurezza (qualcosa che l'utente possiede), il numero di autenticatori biometrici utilizzabile è decisamente limitato. Per le impronte digitali, ad esempio, generalmente esistono dieci possibili varianti. Inoltre, se capita di perdere uno di questi autenticatori, è generalmente impossibile sostituirlo.

Vediamo adesso come quanto appena detto si applica all'esempio dell'accesso con pseudo autenticazione a più fattori. I criteri di misurazione raccolti sfruttando altri fattori non possono essere facilmente sostituibili o modificabili. Sicuramente, dopo aver modificato la password, l'utente la digiterà in modo differente. Tuttavia, la maniera in cui normalmente preme i tasti rimarrà immutata. È proprio su questo che si basa la tecnica appena discussa. Se questi criteri di misurazioni potessero essere compromessi, allora sarebbe possibile sintetizzarli. Un utente malintenzionato potrebbe almeno essere in grado di acquisire queste caratteristiche e riprodurle.

Passare a password meno sicure

È sempre bene utilizzare password lunghe e cambiarle di frequente. Come anche discusso nella prima parte di questa serie, è consigliabile (contrariamente a quanto qualcuno potrebbe consigliare) registrare le proprie password, sia beninteso, in modo protetto. Tuttavia, dovere digitare una password manualmente potrebbe scoraggiare l'uso di queste pratiche. Una password lunga è infatti più difficile da digitare, mentre una che sia registrata risulta di gran lunga più utile quando è possibile copiarla e incollarla. Uno dei migliori modi per memorizzare cento o più password è sicuramente quello di utilizzare un software come Password Safe (disponibile su sourceforge.net/projects/passwordsafe). Con uno strumento come questo, è possibile generare password assolutamente casuali, memorizzarle in formato crittografato e incollarle direttamente nelle finestre di dialogo di accesso. Di fatto, con uno strumento del genere, non è neppure necessario che l'utente conosca la propria password.

Ma il guaio è proprio questo: è impossibile misurare la velocità di digitazione, a meno che non sia proprio l'utente a digitarla. E se è necessario immettere la password all'interno di un oggetto che misura la velocità di digitazione, la tecnica di gestione delle password appena descritta potrebbe risultare inadeguata. Digitare correttamente una password di 15 caratteri completamente casuale non è certo semplice. Di conseguenza, in casi come questi gli utenti scelgono generalmente di utilizzare una password più semplice. Una password completamente casuale di 15 caratteri è certamente più sicura di una più breve, se pur accoppiata a un sistema di pseudo autenticazione a più fattori.

A conti fatti, la pseudo autenticazione a più fattori, se usata da sola, induce gli utenti a utilizzare password meno sicure. Sfortunatamente, come si vedrà a breve, soddisfare gli utenti che utilizzano tecniche di gestione delle password annulla praticamente qualsiasi protezione offerta dai sistemi di pseudo autenticazione a più fattori.

Ignorare lo pseudo accesso a più fattori

Anche se un sito fornisce un sistema di pseudo accesso a più fattori, esso deve sicuramente supportare una modalità alternativa. Innanzi tutto perché pochi siti possono pretendere che tutti gli utenti dispongano di strumenti aggiuntivi per poter accedere al sito. Alcuni utenti (alcuni autori di TechNet Magazine, ad esempio) si rifiutano categoricamente di installare questo genere di software.

La velocità di digitazione può inoltre variare per svariati motivi e i siti devono certamente prevedere questa eventualità. Consideriamo ad esempio che un utente si sia slogato polso e di conseguenza la sua velocità di digitazione è temporaneamente alterata. Come potrà accedere al sito se questo analizza la sua velocità e pensa che sia tratti di una persona diversa? Se si trattasse di una lesione permanente, l'utente potrebbe certamente reimpostare i valori della velocità di digitazione. Tuttavia, nel caso di una lesione temporanea, l'utente non vorrà probabilmente reimpostare i valori memorizzati, presupponendo che la velocità di digitazione ritornerà alla normalità.

Infine, non tutti gli utenti sono in grado di utilizzare i sistemi di pseudo autenticazione a più fattori. Per fare un esempio, consideriamo un utente disabile che interagisce col computer attraverso un'interfaccia di riconoscimento vocale. L'utente potrebbe non essere in grado di immettere le informazioni di accesso nella finestra di dialogo, se questa non prevede la possibilità di immissione automatica. In casi come questi è molto probabile che per legge sia necessario offrire un sistema alternativo per garantire l'accesso agli utenti disabili.

Il modo più semplice per ovviare a questo genere di casistica è quello di supportare l'autenticazione standard basata su password.

Problemi con password compromesse

I sistemi di pseudo autenticazione a più fattori si prefiggono di risolvere i vari problemi legati all'autenticazione basata su password. Tuttavia, questi sistemi non sono in grado di fermare tutte le tecniche utilizzate per compromettere le password. Ci sono cinque metodi principali utilizzati per compromettere un sistema di autenticazione con password, dove per "compromesso" si intende che un utente malintenzionato ottiene e utilizza la password di un altro utente:

• Indovinare la password
• Utilizzare un keystroke logger
• Effettuare degli attacchi di phishing
• Chiedere all'utente
• Entrare in qualsiasi sistema che memorizza la password o un hash di essa

Quello di indovinare la password non è più un metodo di attacco particolarmente comune tra i pirati ed è stato surclassato dai keystroke logger e dagli attacchi di phishing. Questa tecnica è soltanto in parte efficacemente contrastata dalla pseudo autenticazione a più fattori. È poco probabile che cercando di indovinare la password si riesca a compromettere un sistema di pseudo autenticazione a più fattori, se non altro perché l'utente malintenzionato oltre alla password deve individuare anche la velocità di digitazione. Sebbene sia teoricamente possibile sintetizzare i criteri di misurazione della velocità di digitazione, questa tecnica viene raramente utilizzata. Infatti utilizzando un attacco di phishing o un keystroke logger è possibile intercettare i dati stessi. Inoltre, se il sistema fornisce anche un'interfaccia di accesso standard basata esclusivamente sulla password, l'utente malintenzionato può sfruttarla per indovinare la password.

E ancora, utilizzando password molto complesse si riduce la possibilità che vengano indovinate da utenti malintenzionati. Se è possibile insegnare agli utenti a utilizzare password complesse, magari anche con l'ausilio di strumenti di gestione, la pseudo autenticazione a più fattori risulta superflua. (Al contrario, password semplici, tipicamente utilizzate con i sistemi di pseudo autenticazione a più fattori, rendono il metodo di individuazione della password una tecnica facilmente praticabile). Quindi, affinché un sistema sia protetto da tecniche per l'individuazione di password, è fondamentale che questo non supporti l'autenticazione basata esclusivamente su password. E, come si diceva in precedenza, questo può essere possibile solamente di rado. In altre parole, se gli utenti utilizzano password più semplici in presenza di sistemi con pseudo autenticazione a più fattori, indovinare le password potrebbe ritornare ad essere un metodo di attacco facilmente praticabile; la pseudo autenticazione a più fattori ridurrebbe quindi il livello di protezione, piuttosto che aumentarlo. È necessario quindi approfondire questo aspetto.

La pseudo autenticazione a più fattori non offre protezione inoltre contro i keystroke logger. Sebbene io non sia a conoscenza di alcun keystroke logger attualmente in uso in grado di acquisire la velocità di digitazione, non ritengo che progettarne uno possa essere un'impresa eccessivamente difficile. Un keystroke logger può essere un particolare hardware posto tra la tastiera e il computer o un software che acquisisce i tasti digitati. In entrambi i casi, il logger ha pieno accesso a tutti i dati utilizzati dal sistema di pseudo autenticazione a più fattori.

Il keystroke logger può infatti accedere a un numero maggiore di dati in quanto i processi di autenticazione vengono eseguiti in modalità di utente. Senza una soluzione protetta che stia tra la tastiera e l'oggetto basato sul Web utilizzato per acquisire la password, non è possibile evitare questo tipo di attacco. Se le soluzioni di pseudo autenticazione a più fattori diventassero abbastanza comuni, sicuramente verrebbero creati keystroke logger del genere.

Analogamente, gli attacchi di phishing non vengono efficacemente contrastati dalla pseudo autenticazione a più fattori. Piuttosto che utilizzare semplicemente una schermata di accesso contraffatta, un utente malintenzionato potrebbe sfruttare un oggetto Flash per acquisire la password e identificare la velocità di digitazione.

Va precisato però che la pseudo autenticazione a più fattori può essere utile nei casi in cui la tecnica utilizzata da un utente malintenzionato mira soltanto a individuare la password. Ad esempio, la maniera più facile per ottenere una password da un utente è quella di chiedere all'utente stesso. Sembra strano, ma questa si è dimostrata essere una tecnica efficace. Molti sono i modi per chiedere una password: di persona, al telefono o infine attraverso messaggi di phishing.

Sicuramente, chiedere a un utente la sua velocità di digitazione sarebbe ben più complesso. Allo stesso modo, se il database delle password di un'azienda viene compromesso, l'utente malintenzionato avrà a disposizione soltanto le password. Ma ancora un volta questi tentativi di attacco potranno essere neutralizzati solo se il sistema non fornisce la possibilità di eseguire l'autenticazione solo con la password.

È doveroso notare inoltre che, se il database delle password è stato compromesso, l'utente malintenzionato ha probabilmente violato il cuore del sistema, in modo ben più grave di quanto sia possibile fare utilizzando una sola, o anche più, password di account utente standard. Quindi, non è affatto giusto cercare di sottovalutare ciò che un utente malintenzionato in possesso di un database di password è in grado di fare.

Alcuni vantaggi

A dire il vero, ci sono un paio di situazioni nelle quali la pseudo autenticazione a più fattori può essere utile (presupponendo che il sistema non fornisca l'opzione di accesso con la sola password). Ad esempio, può essere utilizzato per evitare lo scambio di password. Tuttavia, questo può risultare una limitazione per quei sistemi nei quali più utenti condividono gli account in maniera del tutto legittima, come ad esempio i conti bancari cointestati.

Inoltre, una finestra di dialogo di accesso interattiva e ben progettata (non l'accesso a un sito Web) potrebbe chiedere all'utente di eseguire ulteriori passaggi di autenticazione, nel caso in cui la velocità di digitazione non venga riconosciuta. In questo modo si può fornire un maggiore grado di protezione a un account compromesso in un ambiente estremamente delicato.

Immagini utilizzate per ingannare gli utenti

Uno dei modi migliori per confondere gli utenti è dare loro indicazioni inesatte riguardo la sicurezza. Il più comune è probabilmente quello di visualizzare l'immagine di un lucchetto in una pagina Web, come illustrato in Figura 1. In questa pagina viene persino visualizzata la parola "Secure" con in lucchetto.

Figura 1 Un esempio di uso improprio dell'icona lucchetto, una tendenza preoccupante (fare clic sull'immagine per una ingrandirla)

Come è probabilmente noto ai lettori, visualizzare semplicemente l'immagine di un lucchetto insieme alla parola "Secure" non rende la pagina sicura. Ma purtroppo questa pratica è fastidiosamente diffusa, anche nei siti Web più rispettabili e nel mirino di molti utenti malintenzionati. Il risultato è che molti utenti sono abituati a cercare questi simboli di garanzia della sicurezza nel testo della pagina Web, piuttosto che dove queste icone effettivamente rappresentano una garanzia, cioè nella barra degli indirizzi. (Il Wiki di Web Security Context di W3C contiene un articolo in merito, disponibile all'indirizzo w3.org/2006/WSC/wiki/PadlockIconMisuse)

È spiacevole dovere notare che tuttavia ci sono così tanti esempi dell'uso improprio dei simboli. Da alcune ricerche si evince che gli utenti non sono in grado di identificare i siti Web dannosi anche quando i certificati parlano chiaro (vedere www.usablesecurity.org/papers/jackson.pdf). È un po' come l'abilità di distinguere facilmente l'originale dal contraffatto, anche quando non si ha l'originale a portata di mano. Ma ciò richiede appunto abilità; la visualizzazione di false garanzie di protezione sulle pagine Web ostacola lo sviluppo di questa abilità, poiché gli utenti vengono esposti a informazioni fuorvianti.

Una variante particolarmente fastidiosa di questo tecnica è illustrata nella Figura 2. In questo caso, la pagina che visualizza le informazioni non è in realtà protetta. Se si guarda la barra degli indirizzi, è facile notare che il protocollo indicato è "http". Questo sito utilizza una tecnica di ottimizzazione molto comune: non codifica tutta la pagina che contiene il modulo di accesso, ma soltanto quest'ultimo. L'accesso è protetto, proprio come si dice nella pagina. Questo è vero se diamo per scontato che "protetto" sia sinonimo di "codificato". Tuttavia, e questo è di fondamentale importanza, l'utente non ha modo di verificare dove le credenziali verranno inviate prima di avere effettivamente effettuato l'accesso. Prima dell'invio dei dati, il sito non mostra all'utente nessun certificato di protezione. È un esercizio per aumentare la fiducia, un po' come lasciarsi cadere essendo certi che la persona dietro di noi ci prenderà. Da quando il modulo viene inviato, il danno potrebbe essere già stato fatto.

Figura 2 Simboli di protezione in una pagina non protetta (fare clic sull'immagine per ingrandirla)

Secure Sockets Layer (SSL), il protocollo che fornisce la protezione nel protocollo HTTPS, presenta un duplice scopo. Primo, autentica il server all'utente. Secondo, offre un meccanismo semplice per negoziare una chiave di crittografia che può essere utilizzata tra il client ed il server durante la sessione.

Quando invece è soltanto il modulo di inserimento ad essere codificato, il primo, e più importante, vantaggio appena citato non viene offerto. I siti che sfruttano questo tipo di ottimizzazione utilizzano SSL semplicemente per negoziare le chiavi. Di fatto, potrebbero ottenere questo risultato utilizzando semplicemente un protocollo di negoziazione standard, evitando così i costi e le spese generali per SSL.

Siti come quello illustrato nella Figura 2 non sono rari da trovare. Molti siti forniscono la protezione SSL soltanto per l'invio del modulo, ma non per la codifica del modulo stesso. Tuttavia, questo sito in particolare mostra un tratto ancora più fastidioso. Digitando https://www.<site>.com (notare l'indicatore di protezione https) nella barra degli indirizzi del browser, il sito reindirizzerà l'utente alla versione non SSL del sito! Anche se si cerca di consultare un certificato prima di inviare le credenziali, il sito continuerà a non mostrare alcuna informazione in merito.

Non tutti i siti sono così cattivi, ma ce ne sono molti in giro. E due delle più grandi aziende che forniscono carte di credito negli Stati Uniti sono fra questi. Di fatto, delle tre più grandi aziende che forniscono carte di credito da me usate, soltanto American Express fornisce un certificato sul modulo di accesso. American Express reindirizza persino le richieste HTTP verso HTTPS. Ottimo!

Farò adesso un'ultima considerazione su questo argomento. Ci si potrebbe chiedere perché un sito faccia una cosa del genere. Il motivo è semplicemente economico. Mostrare un certificato richiede la crittografia della pagina e questo implica un maggiore livello di elaborazione. Quindi più computer per elaborare lo stesso numero di richieste. E utilizzare più computer vuol dire aumentare i costi. Sfortunatamente, quando si tratta di scegliere fra protezione della privacy dei clienti e incremento dei profitti, molte organizzazioni optano per la seconda opzione.

Aprire o non aprire

Recentemente ho ricevuto un sorprendente messaggio di posta elettronica dalla mia azienda di assicurazione sanitaria. Chiunque abbia utilizzato un computer negli ultimi dieci anni sa che non si dovrebbero mai aprire allegati a messaggi di posta elettronica indesiderati. Dunque immaginate con quale incredulità ho ricevuto il messaggio nella Figura 3.

Figura 3 Messaggio di posta elettronica contenente un "allegato sicuro" (fare clic sull'immagine per ingrandirla)

Evidentemente avevo inviato una domanda tramite il sito Web della compagnia di assicurazione sanitaria (e l'avevo dimenticato quando il messaggio sospetto mi è arrivato). Questa è la risposta ricevuta. Inizialmente, ho pensato che fosse un tentativo di phishing molto ben costruito. Quando ho capito che si trattava di un messaggio legittimo, mi è venuta la pelle d'oca.

Mi si chiedeva di fare doppio clic sull'allegato per decodificare il messaggio. Gli esperti di sicurezza e gli amministratori di sistemi informatici hanno passato gli ultimi dieci anni cercando di insegnare agli utenti a NON fare doppio clic sugli allegati. E poi ecco che un'azienda (la compagnia con la quale ho un'assicurazione sanitaria, peraltro, non è la sola organizzazione ad utilizzare questa tecnica) che mi chiede di fare clic sull'allegato per garantire la mia protezione. Come dovrebbe comportarsi un utente in una situazione del genere? Cosa si insegna all'utente?

Successivamente, ho utilizzato la funzionalità di anteprima in Microsoft® Office Outlook® 2007 per visualizzarlo. Come si può vedere nella Figura 4, Outlook ha segnalato questo messaggio come possibile attacco e mi ha avvertito di non aprirlo!

Figura 4 Outlook 2007 considera pericoloso il documento protetto (fare clic sull'immagine per ingrandirla)

È triste e ironico al tempo stesso, che una compagnia assicurativa violi i controlli di protezione fondamentali utilizzati dal programma di posta elettronica più usato al mondo. Considerando che quest'azienda non si è neppure scomodata per controllare che la sua soluzione per la protezione fosse in linea con gli standard di Outlook, è legittimo domandarsi cos'altro quest'azienda faccia per proteggere le informazioni private degli utenti. Oppure, per essere più chiari, quali altre soluzioni impiega l'azienda per non essere accusata di non garantire la protezione della privacy dei propri clienti? Questo caso è simile a quanto descritto precedentemente per le istituzioni finanziarie. In casi del genere penso che la soluzione impiegata miri a evitare le accuse, piuttosto che a proteggere veramente i clienti.

Ho voluto controllare cosa l'allegato fosse realmente. È risultato essere un oggetto di controllo Activex®. Per vedere l'allegato, ho dovuto aprirlo in Internet Explorer® e installare l'oggetto. Ciò che mi è stato mostrato è la rassicurante schermata illustrata nella Figura 5. Come si può vedere, sono stati fatti grandi sforzi per mostrare il messaggio sotto forma di una busta; e ha anche un francobollo che garantisce l'affidabilità del messaggio.

Figura 5 Il documento protetto illustra una busta affrancata come "Affidabile" (fare clic sull'immagine per ingrandirla)

Questo tipo di tecnologia è preoccupante per molte ragioni. Primo, consolida un comportamento sbagliato spesso adottato dagli utenti: l'apertura di allegati indesiderati. Secondo, nel corpo del messaggio, si guida l'utente a configurare il sistema in modo che questo apra automaticamente gli allegati. Terzo, di fronte a messaggi contrastanti, quando il messaggio di posta elettronica dice di essere sicuro mentre Outlook sostiene il contrario, la situazione risulta già molto sospettosa. Infine, l'allegato contiene un messaggio inutile che comunica all'utente l'affidabilità della comunicazione. Se l'utente impara a fidarsi di questo tipo di messaggi, basterà poco per iniziare a fidarsi anche di messaggi dannosi con un layout molto simile.

Fornire comunicazioni protette

Il problema che questa tecnologia si prefigge di affrontare è molto importante. Comunicare con i clienti in modo sicuro è difficile. Tuttavia, questa soluzione risulta estremamente complessa. Probabilmente finirà per confondere l'utente e ottenere il risultato opposto a quello che ci si era prefissi: il sistema dell'utente verrà compromesso.

I siti Web progettati a regola d'arte utilizzano adesso un "centro messaggi". In siti del genere, quando l'azienda deve comunicare col cliente, invia un messaggio di posta elettronica che dice qualcosa del genere: "Hai ricevuto un messaggio nel tuo Centro Messaggi. Collegati al nostro sito Web, effettua l'accesso e fai clic sul collegamento al Centro messaggi per leggere il messaggio". Un'altra garanzia è costituita dall'utilizzo di Secure Multipurpose Internet Mail Extensions (S/MIME) per firmare tutti i messaggi di posta elettronica spediti all'utente, così da garantire l'autenticazione della fonte. È bene inoltre se il messaggio non contiene nel suo testo collegamenti del tipo "fare clic sul collegamento". L'utente dovrebbe digitare l'indirizzo del sito dell'azienda con le proprie mani, per assicurarsi di collegarsi al sito desiderato.

Utilizzando un centro messaggi e aggiungendo la firma digitale ai messaggi, un'azienda è a buon punto nella comunicazione sicura con i propri clienti. Tutto ciò che il cliente vede nel processo di comunicazione è autenticato e l'azienda non pubblicizza inefficaci soluzioni di protezione.

È una questione di privacy

Fino ad ora, nei primi due numeri di questa serie, ho parlato di come gli esperti di sicurezza indirizzano gli utenti verso la direzione sbagliata. Garantire la protezione è il nostro lavoro. Ma molte delle soluzioni implementate confondono gli utenti, insegnano loro a fare scelte sbagliate e comunicano una percezione errata della sicurezza. Non dovremmo ricoprire gli utenti con tutte queste informazioni contrastanti.

Come ho fatto notare precedentemente, gli utenti comuni intendono la protezione come la semplice protezione delle password o dei numeri di carta di credito. Desiderano che la tecnologia sia efficiente e affidabile. Sfortunatamente essi devono anche prendere delle decisioni ed è nostro compito assicurarci che siano informati sulle scelte giuste.

Nella parte finale di questa serie, discuterò come alcune delle tecnologie più importanti disponibili sul mercato non sono effettivamente all'altezza delle aspettative. Presenterò inoltre la mia chiamata alle armi. Date quindi un'occhiata alla colonna Security Watch sul numero di settembre 2008.

Jesper M. Johansson è Software Architect, si occupa dei problemi di protezione software e collabora con TechNet Magazine in qualità di redattore. Ha conseguito un Ph.D. in sistemi di gestione delle informazioni e vanta un'esperienza più che ventennale sul tema della sicurezza; è inoltre Microsoft Most Valuable Professional (MVP) per la protezione delle aziende. Il suo ultimo libro è Windows Server 2008 Security Resource Kit.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.