Crittografia dei dati: gli sviluppatori di terminologia critica devono conoscere

Poiché il mondo diventa sempre più guidato dai dati, la gestione sicura dei dati degli utenti è più critica che mai.

Come sviluppatori, il nostro lavoro è già abbastanza difficile: occuparci di sistemi estremamente complessi e fragili con più punti di errore mentre traduciamo desideri umani svolazzanti in interfacce utente e backend. Da aggiungere al compito c'è una considerazione emergente ed essenziale: la sicurezza dei dati. E per una buona ragione: noi come clienti ci arrabbiamo se i nostri dati vengono utilizzati in modo improprio (quindi è giusto offrire ai nostri utenti un'esperienza sicura e piacevole) e i governi e le imprese lo richiedono per la conformità.

La sicurezza dei dati come passaparola

Ciò che rende la sicurezza più difficile è che ha diversi livelli e diventa la responsabilità-di-tutti-è-responsabilità-di-nessuno. In un moderno team cloud, più team controllano direttamente l'ingresso/uscita dei dati: sviluppatori, amministratori di database, amministratori di sistema (persone DevOps, se preferisci), utenti di back-office privilegiati e così via. Questi ruoli/team possono chiudere rapidamente gli occhi e pensare alla sicurezza dei dati come al problema degli altri. Tuttavia, la realtà è che hanno i loro mondi di cui occuparsi poiché un amministratore di database non può controllare il lato della sicurezza dell'app, una persona DevOps non può assolutamente fare nulla per l'accesso al back office e così via.

Sviluppatori e sicurezza dei dati

Detto questo, gli sviluppatori hanno la più ampia superficie di accesso quando si tratta di dati: costruiscono ogni parte dell'app; si collegano a vari servizi di backend; i gettoni di accesso al traghetto avanti e indietro; hanno l'intero cluster di database da cui leggere/scrivere al loro comando; le app che scrivono hanno accesso indiscusso a tutte le parti del sistema (ad esempio, un'app Django in produzione ha tutti i privilegi per scaricare o cancellare l'intera collezione S3 degli ultimi dieci anni), e così via. Di conseguenza, la più alta possibilità di negligenza o supervisione in termini di sicurezza esiste a livello di codice sorgente ed è responsabilità diretta dello sviluppatore.

Ora, la sicurezza dei dati è una tana del coniglio senza fondo, e non c'è modo che io possa nemmeno scalfire la superficie in un singolo post. Tuttavia, voglio trattare la terminologia essenziale che gli sviluppatori devono conoscere per proteggere le loro app. Pensalo come App Data Security 101.

Iniziamo!

Hashing

Se vuoi una definizione altamente rigorosa, c'è sempre Wikipedia, ma in termini semplici, l'hashing è il processo di conversione dei dati in un'altra forma, dove le informazioni sono illeggibili. Ad esempio, utilizzando il noto (e molto insicuro) processo di codifica Base64, la stringa "Il mio segreto è al sicuro con te?" può essere convertito ("hash") in "SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/". Se inizi a scrivere il tuo diario personale in formato Base64, ad esempio, non c'è modo che la tua famiglia possa leggere i tuoi segreti (a meno che non sappiano come decodificare da Base64)!

Questa idea di codificare i dati viene utilizzata durante la memorizzazione di password, numeri di carta di credito, ecc., Nelle app Web (in realtà, dovrebbe essere utilizzata in tutti i tipi di app). L'idea, ovviamente, è che in caso di violazione dei dati, l'attaccante non dovrebbe essere in grado di utilizzare le password, i numeri di carta di credito, ecc., per causare danni reali. Per eseguire questo hashing vengono utilizzati algoritmi altamente robusti e sofisticati; qualcosa come Base64 sarà uno scherzo e verrà rotto all'istante da qualsiasi aggressore.

L'hashing delle password utilizza una tecnica crittografica nota come hashing unidirezionale, il che significa che mentre è possibile codificare i dati, non è possibile decodificarli. Allora come fa l'app a sapere che è la tua password quando accedi? Bene, usa lo stesso processo e confronta il modulo criptato di ciò che hai appena inserito come password con il modulo criptato memorizzato nel database; se corrispondono, puoi accedere!

Mentre siamo in tema di hash, ecco qualcosa di interessante. Se scarichi software o file da Internet, ti potrebbe essere stato detto di verificare i file prima di utilizzarli. Ad esempio, se desideri scaricare l'ISO di Ubuntu Linux, la pagina di download ti mostrerà un'opzione per verificare il tuo download; se fai clic su di esso, si aprirà un popup:

Il popup ti dice di eseguire un comando, che essenzialmente eseguirà l'hashing dell'intero file appena scaricato e confronterà il risultato con la stringa hash che vedi nella pagina di download: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5 . Questa conversione viene eseguita utilizzando l'algoritmo SHA256, la cui menzione puoi vedere nelle parti finali del comando: shasum -a 256 --check .

L'idea è che se l'hash prodotto attraverso il tuo controllo è diverso, significa che qualcuno si è intromesso nel tuo download e ti ha fornito un file compromesso.

Alcuni nomi familiari che sentirai nel dominio dell'hashing delle password sono MD5 (non sicuro e ora defunto), SHA-1 e SHA-2 (famiglie di algoritmi, di cui SHA-256 è membro, così come SHA-512), SCRYPT, BCRYPT, ecc.

salatura

Tutti i tipi di sicurezza sono un gioco del gatto col topo: il ladro apprende il sistema attuale e inventa un nuovo crack, che viene notato, e i produttori di serrature migliorano il loro gioco, e così via. La crittografia non fa eccezione. Sebbene riconvertire gli hash in password sia diventato impossibile, gli aggressori nel tempo hanno sviluppato tecniche sofisticate che combinano congetture intelligenti con pura potenza di calcolo; di conseguenza, nove volte su dieci, possono prevedere la password corretta, dato solo l'hash.

Di conseguenza, si è sviluppata la tecnica della salatura. Significa solo che il calcolo dell'hash di una password (o di qualsiasi dato) verrà eseguito in base a una combinazione di due cose: i dati stessi e una nuova stringa casuale che l'attaccante non può indovinare. Quindi, con il salting, se vogliamo eseguire l'hash della password superman009 , selezioneremo prima una stringa casuale come "salt", ad esempio bCQC6Z2LlbAsqj77 e quindi eseguiremo il calcolo dell'hash su superman009-bCQC6Z2LlbAsqj77 . L'hash risultante devierà dalle consuete strutture prodotte dall'algoritmo, riducendo notevolmente le possibilità di reverse engineering intelligente o congetture.

Sia l'hashing che il salting sono domini incredibilmente complicati e vengono costantemente evoluti. Quindi, come sviluppatore di applicazioni, non tratteremmo mai direttamente con loro. Ma ci sarebbe di grande aiuto se li conoscessimo e potessimo prendere decisioni migliori. Ad esempio, se mantieni un vecchio framework PHP e ti capita di vedere che utilizza hash MD5 per le password, sai che è ora di inserire un'altra libreria di password nel processo di creazione dell'account utente.

chiavi

Ti imbatterai spesso nel termine "chiavi" nel contesto della crittografia. Finora ci siamo occupati dell'hashing delle password o della crittografia unidirezionale, in cui convertiamo i dati in modo irreversibile e distruggiamo la forma originale. Questa è una cattiva idea per l'uso pratico quotidiano: un documento scritto e inviato via email in modo così sicuro da non poter mai essere letto non è di alcuna utilità! Pertanto, vogliamo crittografare i dati in modo tale che le informazioni siano aperte con il mittente e il destinatario, ma mentre vengono trasferite o archiviate, dovrebbero essere illeggibili.

Per questo esiste in crittografia il concetto di “chiave”. È esattamente come sembra: la chiave di una serratura. La persona che possiede le informazioni le cripta usando un segreto chiamato chiave. A meno che il destinatario/aggressore non abbia questa chiave, è impossibile decodificare i dati, non importa quanto sofisticati possano essere i loro algoritmi.

Tasti rotanti

Sebbene le chiavi rendano possibile e affidabile la crittografia, comportano i rischi delle password: una volta che qualcuno conosce la chiave, l'intero gioco è finito. Immagina uno scenario in cui qualcuno hackera una parte di un servizio come GitHub (anche se per pochi secondi) e può entrare in possesso di codice vecchio di 20 anni. All'interno del codice, trovano anche le chiavi crittografiche utilizzate per crittografare i dati dell'azienda (pratica orribile per memorizzare le chiavi insieme al codice sorgente, ma rimarrai sorpreso dalla frequenza con cui ciò accade!). Se l'azienda non si è preoccupata di cambiare le sue chiavi (proprio come le password), la stessa chiave può essere utilizzata per provocare il caos.

Di conseguenza, la pratica di cambiare frequentemente le chiavi si è evoluta. Questa è chiamata rotazione delle chiavi e, se utilizzi un provider PaaS cloud rispettabile, dovrebbe essere disponibile come servizio automatizzato.

Ad esempio, AWS ha un servizio dedicato per questo chiamato AWS Key Management Service (KMS). Un servizio automatizzato ti evita il fastidio di cambiare e distribuire le chiavi tra tutti i server ed è un gioco da ragazzi in questi giorni quando si tratta di grandi implementazioni.

Crittografia a chiave pubblica

Se tutto il discorso precedente sulla crittografia e le chiavi ti fa pensare che sia molto ingombrante, hai ragione. Mantenere le chiavi al sicuro e passarle in modo che solo il destinatario possa vedere i dati si imbatte in problemi logistici che non avrebbero consentito alle comunicazioni sicure di oggi di prosperare. Ma tutto grazie alla crittografia a chiave pubblica, possiamo comunicare o fare acquisti online in tutta sicurezza.

Questo tipo di crittografia è stato un importante passo avanti matematico ed è l'unico motivo per cui Internet non sta cadendo a pezzi nella paura e nella sfiducia. I dettagli dell'algoritmo sono intricati e altamente matematici, quindi posso spiegarlo solo concettualmente qui.

La crittografia a chiave pubblica si basa sull'uso di due chiavi per elaborare le informazioni. Una delle chiavi si chiama Private Key e dovrebbe rimanere privata con te e non essere mai condivisa con nessuno; l'altro si chiama Public Key (da cui deriva il nome del metodo) e dovrebbe essere pubblicato pubblicamente. Se ti sto inviando dati, devo prima ottenere la tua chiave pubblica, crittografare i dati e inviarteli; alla fine, puoi decifrare i dati usando la tua chiave privata e la combinazione di chiavi pubbliche. Se non riveli accidentalmente la tua chiave privata, posso inviarti dati crittografati che solo tu puoi aprire.

La bellezza del sistema è che non ho bisogno di conoscere la tua chiave privata e chiunque intercetti il ​​messaggio non può fare nulla per leggerlo anche se ha la tua chiave pubblica. Se ti stai chiedendo come sia possibile, la risposta più breve e non tecnica deriva dalle proprietà della moltiplicazione dei numeri primi:

È difficile per i computer fattorizzare grandi numeri primi. Quindi, se la chiave originale è molto grande, puoi essere certo che il messaggio non può essere decifrato nemmeno tra migliaia di anni.

Sicurezza del livello di trasporto (TLS)

Ora sai come funziona la crittografia a chiave pubblica. Questo meccanismo (conoscere la chiave pubblica del destinatario e inviare loro i dati crittografati utilizzando quella) è ciò che sta dietro a tutta la popolarità di HTTPS ed è ciò che fa sì che Chrome dica "Questo sito è sicuro". Quello che sta succedendo è che il server e il browser stanno crittografando il traffico HTTP (ricorda, le pagine web sono stringhe di testo molto lunghe che i browser possono interpretare) con le chiavi pubbliche dell'altro, risultando in Secure HTTP (HTTPS).

Credito immagine: Mozilla È interessante notare che la crittografia non avviene sul Transport Layer in quanto tale; il modello OSI non dice nulla sulla crittografia dei dati. È solo che i dati vengono crittografati dall'applicazione (in questo caso, il browser) prima di essere trasferiti al Transport Layer, che in seguito li rilascia a destinazione, dove viene decrittografato. Tuttavia, il processo coinvolge il livello di trasporto e, alla fine, tutto si traduce in un trasporto sicuro dei dati, quindi il termine generico "sicurezza del livello di trasporto" è rimasto invariato.

In alcuni casi potresti persino imbatterti nel termine Secure Socket Layer (SSL). È lo stesso concetto di TLS, tranne per il fatto che SSL è nato molto prima e ora è tramontato a favore di TLS.

Crittografia completa del disco

A volte le esigenze di sicurezza sono così intense che nulla può essere lasciato al caso. Ad esempio, i server governativi in ​​cui sono archiviati tutti i dati biometrici di un paese non possono essere forniti ed eseguiti come normali server di applicazioni poiché il rischio è troppo alto. Non è sufficiente per queste esigenze che i dati vengano crittografati solo quando vengono trasferiti; deve essere crittografato anche quando è a riposo. Per questo, viene utilizzata la crittografia dell'intero disco per crittografare l'intero disco rigido per garantire la sicurezza dei dati anche in caso di violazione fisica.

È importante notare che la crittografia completa del disco deve essere eseguita a livello di hardware. Questo perché se crittografiamo l'intero disco, anche il sistema operativo viene crittografato e non può essere eseguito all'avvio della macchina. Quindi, l'hardware deve capire che il contenuto del disco è crittografato e deve eseguire la decrittografia al volo mentre passa i blocchi del disco richiesti al sistema operativo. A causa di questo lavoro extra, la crittografia completa del disco si traduce in letture/scritture più lente, che devono essere tenute a mente dagli sviluppatori di tali sistemi.

Crittografia end-to-end

Con i continui incubi sulla privacy e la sicurezza dei grandi social network in questi giorni, nessuno ignora il termine "crittografia end-to-end", anche se non hanno nulla a che fare con la creazione o la manutenzione di app.

Abbiamo visto in precedenza come la crittografia completa del disco fornisce la strategia definitiva a prova di proiettile, ma per l'utente quotidiano non è conveniente. Voglio dire, immagina che Facebook voglia che i dati del telefono che genera e archivia nel tuo telefono siano al sicuro, ma non può avere accesso alla crittografia dell'intero telefono e bloccare tutto il resto nel processo.

Per questo motivo, queste aziende hanno avviato la crittografia end-to-end, il che significa che i dati vengono crittografati quando vengono creati, archiviati o trasferiti dall'app. In altre parole, anche quando i dati raggiungono il destinatario, sono completamente crittografati ed è accessibile solo dal telefono del destinatario.

Si noti che la crittografia End-to-End (E2E) non offre garanzie matematiche come la crittografia a chiave pubblica; è solo una crittografia standard in cui la chiave viene archiviata con l'azienda e i tuoi messaggi sono al sicuro come decide l'azienda.

Conclusione

Probabilmente hai già sentito parlare della maggior parte di questi termini. Forse anche tutti. In tal caso, ti incoraggerei a rivisitare la tua comprensione di questi concetti, oltre a valutare quanto seriamente li prendi. Ricorda, la sicurezza dei dati delle app è una guerra che devi vincere ogni volta (e non solo una volta), poiché anche una singola violazione è sufficiente per distruggere interi settori, carriere e persino vite!