{"id":149,"date":"2011-03-08T11:03:07","date_gmt":"2011-03-08T10:03:07","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/crittografia-per-il-web\/"},"modified":"2011-03-08T11:03:07","modified_gmt":"2011-03-08T10:03:07","slug":"crittografia-per-il-web","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/crittografia-per-il-web\/","title":{"rendered":"Crittografia per il Web"},"content":{"rendered":"

[Il titolo originale tradotto risulterebbe: “Crittografia per il web: polpettoni salati e altri piatti gustosi”. Hash \u00e8 un polpettone di carne macinata tipico degli Stati Uniti, ndt<\/em>]<\/p>\n

Uno dei pi\u00f9 potenti strumenti per la sicurezza a disposizione dei web developer \u00e8 la crittografia, sostanzialmente un processo per cui le informazioni importanti vengono tradotte in rumore casuale<\/a>, non leggibile se non dove esplicitamente deliberato. Fino a poco tempo fa, molti governi regolavano i software di crittografia in maniera molto rigida. Ma la crittografia \u00e8 semplicemente matematica applicata ed \u00e8 stato provato che \u00e8 impossibile da occultare. Uno sviluppatore web che lavora su un netbook un po’ scarso nella sua cantina ha ora accesso a dei sistemi di crittografia che i governi di qualche decennio fa potevano solo sognare.<\/p>\n

Si \u00e8 tentati a credere che una semplice applicazione web non necessiti di sicurezza a livello di quella industriale perch\u00e9 non conterr\u00e0 alcuna informazione che valga la pena rubare, come i numeri delle carte di credito, ma sfortunatamente, la tendenza delle persone al riutilizzo delle stesse password su diversi sistemi implica che la compromissione di quello pi\u00f9 debole tra questi sistemi possa spesso dare accesso agli altri. Nel 2009, come tutti sanno, un hacker ha ottenuto l’accesso<\/a> ad un numero di sistemi interni a Twitter compromettendo l’account e-mail di un singolo assistente amministrativo.<\/p>\n

Proprio come ogni artigiano deve conoscere gli arnesi e i materiali per raggiungere l’eccellenza, cos\u00ec \u00e8 importante che i web developer comprendano quali tipi di crittografia funzionano in uno specifico contesto, anche se non \u00e8 necessario comprenderne i dettagli della matematica che vi \u00e8 coinvolta. La crittografia applicata male non d\u00e0 alcun beneficio e pu\u00f2 anche essere pericoloso perch\u00e9 crea un falso senso di sicurezza.<\/p>\n

Ci sono diversi tipi di sistemi crittografici, ma sono tre le categorie che solitamente vengono associate alle applicazioni web.<\/p>\n

\n

Funzioni one-way<\/h2>\n

Non si pu\u00f2 partire da una salsiccia e lavorare all’indietro per produrre gli ingredienti base che la compongono. Allo stesso modo, un hash crittografico \u00e8 progettato per prendere in ingresso dei dati e farli a brandelli, cos\u00ec che quello che esce al termine del processo di crittografia sia irriconoscibile, in maniera irreversibile. Descritto cos\u00ec, non sembra un’operazione particolarmente difficile n\u00e9 utile, ma gli hash ben progettati hanno due propriet\u00e0 che li rendono sia complessi sia utili.<\/p>\n

Primo: un piccolo cambiamento nell’input dovrebbe creare un drastico cambiamento nell’output. In altre parole, cambiare un carattere nei dati sottoposti a hash produrr\u00e0 un cambiamento molto pi\u00f9 grande di un singolo carattere nell’output. Solitamente, gli hash producono un output di lunghezza fissa (e relativamente breve), indipendentemente dalla dimensione dell’input. Questo significa che pi\u00f9 input in teoria potrebbero produrre lo stesso risultato, rendendo impossibile sapere quale fosse il dato originale se un \u201cattacker\u201d avesse solo il risultato dello hash con cui lavorare.<\/p>\n

Secondo: un hash produce sempre lo stesso output a fronte dello stesso input. L’applicazione pi\u00f9 ovvia per gli hash \u00e8 lo storage delle password. Un’applicazione web non deve per forza conoscere la password dell’utente: deve solo verificare che la persona che richiede l’accesso conosca la password. Se facciamo lo hash delle password allo stesso modo al momento della creazione dell’account e al login, dobbiamo memorizzare e confrontare solo il risultato dell’operazione di hash per sapere se gli originali coincidono. Poi, anche se il database degli utenti viene esposto<\/a>, l’\u201cattacker\u201d non ha nulla di tremendamente utile con cui lavorare. Perlomeno, questo \u00e8 il buon senso comune.<\/p>\n

In realt\u00e0, non \u00e8 cos\u00ec semplice. Per prima cosa, non tutti gli algoritmi di hashing sono uguali. Ad esempio, l’algoritmo MD5, una volta molto diffuso, \u00e8 ora noto per essere crittograficamente debole<\/a> in generale (sebbene si possa ancora usare per le password). In secondo luogo, sappiamo che molte persone scelgono la stessa password comune<\/a>. Questo implica che se un attacker conosce il valore hash di \u201c123456\u201d prodotto da alcuni algoritmi popolari, potr\u00e0 facilmente riconoscerlo all’interno di un database. Elenchi di hash pre-calcolati sono molto diffusi e conosciuti nell’industria della sicurezza come rainbow tables<\/a>.<\/p>\n

Per contrastare questa debolezza, si pu\u00f2 \u201csalare il polpettone\u201d [hash significa anche polpettone, ndt<\/em>]. Date le due propriet\u00e0 dei buoni algoritmi di hash elencate sopra, possiamo semplicemente appendere un po’ di dati alla password dell’utente e memorizzare lo hash di quel testo combinato con gli altri dati piuttosto che la password stessa. Questo creer\u00e0 un risultato completamente differente ma pur sempre verificabile in maniera semplice.<\/p>\n

Confrontate quanto segue:<\/p>\n

sha1('password')\n=> 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8\n\nsha1('x5T1password')\n=> e1f9530af9bde38db0eef386c4d22ec2ba10d2fe<\/code><\/pre>\n
In questo esempio, aggiungere quattro caratteri a caso all’inizio della parola fa cambiare il 95% dell’output risultate. L’algoritmo SHA-1, sviluppato dalla US National Security Agency, \u00e8 attualmente la funzione hash migliore che si abbia a disposizione e gode di un vaso supporto nei pi\u00f9 diffusi linguaggi di programmazione.<\/p>\n<\/div>\n
\n
Cifratura simmetrica<\/h2>\n
Ovviamente, le funzioni one-way hanno un uso piuttosto ristretto. In molti casi, l’informazione \u00e8 cifrata solo per assicurare che non possa essere letta al di fuori del contesto desiderato. Ma all’interno del contesto, ad esempio in una console amministrativa, la cifratura deve poter essere reversibile.<\/p>\n
Tuttavia, la prima domanda che uno sviluppatore di applicazioni dovrebbe sempre porsi \u00e8: \u201cHo veramente<\/em> bisogno di raccogliere e salvare questa informazione?\u201d Immagazzinare solo i dati strettamente necessari solitamente contribuisce a migliorare l’esperienza utente, a semplificare lo sviluppo ed \u00e8 naturalmente pi\u00f9 sicura. Dopo tutto, i dati che non esistono non possono essere rubati o utilizzati.<\/p>\n
Ma assumendo che le informazioni sensibili siano realmente cruciali per il funzionamento dell’applicazione, dobbiamo prendere in considerazione come gestirli in maniera sicura. La cifratura reversibile si suddivide in due categorie: nella prima, una sola \u201cchiave segreta\u201d viene usata sia per cifrare che per decodificare i dati. Una chiave \u00e8 una specie di password, ma dal momento che \u00e8 pi\u00f9 probabile che le chiavi vengano usate dai programmi piuttosto che dalle persone, possono (e dovrebbero) essere molto lunghe e totalmente a caso.<\/p>\n
Con i moderni algoritmi, la cifratura simmetrica ha il vantaggio di essere estremamente veloce. Il potente algoritmo AES (noto anche come cifrario di Rijndael) \u00e8 stato progettato specificatamente per la velocit\u00e0 ed \u00e8 molto ben supportato, con implementazioni sia nei database server che negli application framework. La cifratura e la decifratura dei dati in MySQL, ad esempio, \u00e8 cos\u00ec semplice:<\/p>\n
INSERT INTO people (pet_name) \n  VALUES (AES_ENCRYPT('Schmoopie','my-secret-key'));\n\nSELECT AES_DECRYPT(pet_name, 'my-secret-key') AS pet_name\n  FROM people;<\/code><\/pre>\n
Questo non protegge l’informazione dall’esposizione se un utente malintenzionato riesce ad accedere all’applicazione web, dal momento che sa come decifrare i dati. Tuttavia, protegge dall’apertura accidentale in altri contesti, come i files di backup o un attacco al database stesso.<\/p>\n
La cifratura simmetrica funziona bene quando abbiamo bisogno solo di accedere all’informazione in un singolo contesto. Tuttavia, tutta la sua forza risiede nella segretezza della chiave, che pu\u00f2 assumere i contorni di una sfida quando vogliamo spostare i dati da un posto ad un altro. Se dobbiamo condividere la chiave, specialmente con pi\u00f9 destinatari, questa non sar\u00e0 pi\u00f9 segreta.<\/p>\n<\/div>\n
\n
Cifratura asimmetrica<\/h2>\n
Per venire incontro a questa necessit\u00e0, gli algoritmi asimmetrici fanno affidamento su una coppia di chiavi collegate che vengono generate con delle specifiche propriet\u00e0. Quando una chiave cifra un pezzo di informazione, solo la chiave corrispondente all’interno della coppia potr\u00e0 decifrarla. Questo tipo di cifratura viene anche chiamata crittografia a chiave pubblica<\/a> perch\u00e9 spesso (ma non sempre) una chiave viene resa pubblica, mentre l’altra viene tenuta privata.<\/p>\n
La matematica<\/a> che rende possibile questo accoppiamento \u00e8 interessante, ma quello che devono capire gli sviluppatori web \u00e8 quando utilizzarla e che protezione d\u00e0. Comunemente, si incontra questa tecnologia nelle connessioni SSL (ora chiamate TLS<\/a>). Un web server manda la sua chiave pubblica al browser web, che la usa per cifrare i dati che solo il server potr\u00e0 decifrare. Pu\u00f2 anche essere usata per mandare delle e-mail cifrate<\/a>.<\/p>\n
In confronto alle funzioni simmetriche, quelle asimmetriche sono lente e richiedono chiavi che sono molto pi\u00f9 lunghe per essere efficaci. Nelle connessioni TLS, il browser ed il server usano solo la crittografia a chiave pubblica per stabilire una chiave simmetrica temporanea che possono usare per cifrare la comunicazione che seguir\u00e0.<\/p>\n
Comunque, queste funzioni rivestono un ruolo cruciale nell’esperienza web moderna, permettendoci di proteggere i dati in transito tra un’applicazione ed i suoi utenti. La prevalenza di WiFi libero rende tutto ci\u00f2 un problema molto reale. Su una rete WiFi libera, gli utenti possono mandare qualunque cosa stiano facendo lungo un raggio considerevole a 360\u00b0. Senza cifratura, i dati possono essere facilmente osservati da chiunque abbia un laptop. Due incidenti \u201cad alto profilo\u201d hanno messo in evidenza questo rischio nel 2010: nel primo, Google entr\u00f2 in conflitto<\/a> con le autorit\u00e0 garanti della privacy perch\u00e9 aveva accidentalmente raccolto e memorizzato i dati non protetti di traffico WiFi con le sue auto Street View.<\/p>\n
Quello che Google ha fatto in maniera accidentale, altri potrebbero farlo di proposito. Pi\u00f9 avanti sempre nel 2010, il plugin Firesheep<\/a> ha ottenuto titoli in prima pagina<\/a> mostrando quando fosse semplice (e dannoso) intercettare le reti non protette.<\/p>\n
\u00a0<\/p>\n
Come minimo, le applicazioni web dovrebbero richiedere connessioni TLS quando trasmettono le informazioni di login. Usarle per tutto il traffico sarebbe ancora meglio.<\/p>\n<\/div>\n
\n
Comprendere il rischio<\/h2>\n
Dal momento che ormai moltissime persone usano i computer, tutte queste tecnologie non potranno che diventare sempre pi\u00f9 importanti per gli sviluppatori web. Gli scorsi anni hanno mostrato che il rischio non \u00e8 teorico<\/a>. Non \u00e8 sufficiente dire \u201cLa mia applicazione non ha un profilo tanto alto da poter essere un obiettivo\u201d, perch\u00e9 gli attacchi molto spesso sono automatizzati, non guardano gli obiettivi. Allo stesso tempo, dobbiamo comprendere ed educare gli altri riguardo i rischi specifici e come utilizziamo la tecnologia per minimizzarli. Senza tale educazione, i clienti potrebbero considerare un sito o un’applicazione \u201csicuri\u201d semplicemente perch\u00e9 accettano connessioni HTTPS, non capendo perch\u00e9 non sono in grado di mandare a loro un’e-mail con la password in chiaro.<\/p>\n
La sicurezza non sar\u00e0 mai assoluta, ma se la si usa in maniera appropriata, la moderna crittografia ci fornisce i mezzi per eliminare i rischi maggiori. Sta a noi metterla in campo.<\/p>\n
Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Uno dei pi\u00f9 potenti tool di sicurezza a disposizione dei web developer \u00e8 la crittografia, sostanzialmente un processo per cui dell’informazione significativa viene trasformata in rumore casuale, non leggibile se non dove si vuole che ci\u00f2 avvenga. Un web developer che lavora su un portatile scarso nella sua cantina adesso ha accesso a dei sistemi di cifratura che i pi\u00f9 potenti governi potevano solo desiderare qualche decennio fa. Ed ignorare la crittografia non \u00e8 una mossa furba: potreste pensare che la vostra applicazione web abbia un profilo troppo basso per poter destare l’interesse degli hacker, ma gli attacchi sono frequentemente automatizzati, senza un obiettivo preciso e la compromissione di un sistema pi\u00f9 debole pu\u00f2 spesso dare accesso a sistemi meglio protetti se le persone usano le stesse password su pi\u00f9 siti. Vi presentiamo le tre grandi categorie si sistemi di crittografia che solitamente vengono collegati alle applicazioni web cos\u00ec che possiate cominciare a studiare una strategia per rendere il vostro sito sicuro.<\/p>\n","protected":false},"author":818,"featured_media":7000610,"comment_status":"open","ping_status":"open","template":"","categories":[270,39,251],"tags":[],"coauthors":[284],"class_list":["post-149","article","type-article","status-publish","has-post-thumbnail","hentry","category-il-server-side","category-numero-25-8-marzo-2011","category-scripting"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/149","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=149"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000610"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=149"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}