Crittografia e protezione dei dati personali (e hacker)!

Question

Crittografia e protezione dei dati personali (e hacker)!

#1 da (2 voti)

4

Sto cercando di capire una strategia di crittografia decente per un'applicazione di piccole imprese. Il mio obiettivo principale è quello di espormi al più piccolo PI non criptato possibile.

Non ho idea se sto pensando troppo a questo e c'è un modo semplice, quindi ho pensato di chiedere. Mi piacerebbe anche sentire se qualcuno dei miei pensieri è completo di spazzatura.

Ho pensato finora a 2 strategie:

Quando un utente effettua l'accesso, gli viene richiesto di immettere una password di decrittografia principale. Questa password viene utilizzata per decrittografare la chiave privata e viene generata una stringa casuale & memorizzato in un cookie (o forse nella memoria locale + trasmesso con ogni richiesta di posta). La chiave privata viene nuovamente crittografata con la stringa casuale e ogni volta che viene richiesto un dato crittografato, la stringa del cookie viene utilizzata per decrittografare la chiave, quindi i dati.
- Svantaggio: come amministratore / hacker del server, potevo ovviamente intercettare la password principale e decifrare la chiave, quindi i dati.
- Vantaggio: abbastanza semplice.
La chiave pubblica è solo memorizzata sul server. Tra il server e il client c'è un proxy inverso che analizza il contenuto (simile a come funziona ESI). Questo server proxy conterrebbe la chiave privata e decrittografare i dati prima di servire al client. Le chiavi su questo server non sarebbero gestite dallo stesso amministratore.
- Svantaggio: come amministratore / hacker proxy, puoi ovviamente intercettare i dati mentre passano. Avresti anche l'accesso con chiave privata.
- Vantaggio: come amministratore / hacker proxy non avresti le credenziali per l'applicazione, quindi saresti in grado di annusare solo i dati richiesti dagli utenti finali.
- Vantaggio: in un ambiente aziendale, è probabile che questo server possa essere protetto molto più facilmente da fonti esterne. Nessuna connessione in entrata potrebbe essere consentita.

I seguenti sono trattati come dati:

Tutto il trasporto è protetto da SSL.
In tutti gli scenari avrei accesso ai dati così come sono stati inseriti. Questo potrebbe essere mitigato utilizzando la crittografia a chiave pubblica JS.
L'autentica autenticazione dell'applicazione è adatta allo scopo. OSSIA Ingegneria sociale, forza bruta ecc. Sono tutti scontati. Problemi / bug basati sul browser non sono scontati.
I dati crittografati devono essere accessibili da un team di persone autorizzate.
È necessario accedervi tramite un browser.
L'intero disco è crittografato a riposo, il che non è di beneficio, ad esempio, per violare la root tramite SSH.

Ho attualizzato quanto segue:

Decodifica JS: da quello che ho visto, questo significa che la chiave privata è stata mostrata all'utente finale.
Chiavi e ampli simmetrici; chiavi pub / priv non cifrate sul server, DB su un altro server. Non sono veramente sicuro del valore di questi. Come amministratore o come hacker, avrei tutto il necessario per decrittografare i dati MySQL se dovessi violare il server delle applicazioni.
Server di chiavi di terze parti: questo sembra passare inosservato a qualcun altro che è in grado di vedere il contenuto (anche se mi chiedo se c'è un processo a più fasi che potrebbe funzionare insieme).

encryption

posta user164613 26.11.2017 - 03:12

fonte

1 risposta

Leggi altre domande sui tag encryption

Prevenzione degli attacchi di riproduzione con JWT Esiste una differenza terminologica tra le parole "crittogramma" e "testo cifrato"?

score 2 · Answer 1

Le soluzioni che suggerisci possono essere tutte infrante, dato che spostano la fiducia solo da qualche altra parte. È necessaria una soluzione crittografica che garantisca quanto segue:

Il tuo server è in grado di accettare e trasmettere materiale crittografato agli utenti corretti.
L'utente ha accesso alla chiave di crittografia.
Il server non ha accesso alla chiave di crittografia.

Ciò richiede la crittografia JavaScript nel browser o un programma client separato. Ovviamente, esiste la possibilità per un amministratore malintenzionato di sostituire il JavaScript con una versione che invia la chiave o il testo in chiaro originale al server, ma questo sarà sempre un rischio.

A seconda del tipo di dati che vengono archiviati, esiste già una soluzione piuttosto semplice che viene utilizzata da molti siti Web di incolla come Zerobin e 0bin, oltre al popolare host di file Mega: crittografia lato client . JavaScript nel browser crea una chiave di crittografia simmetrica e la aggiunge come frammento (qualsiasi cosa oltre l'octothorpe) dell'URL. Il frammento è visibile solo per il browser, non per il server. JavaScript nel browser crittografa i dati utilizzando questo frammento e carica i dati sul server. Il risultato è che hai bisogno dell'URL completo per visualizzare la pagina e il server non è in grado di decodificare.

Un URL può quindi essere rappresentato come example.com/path#fragment . Il tuo ISP vede example.com , poiché questo è ciò che viene inviato al server DNS. Anche con TLS in uso, il dominio viene comunque inviato in chiaro a causa di SNI. /path è visibile solo al server al quale lo stai inviando, assumendo che tu stia utilizzando TLS. Questo è ciò che il server usa per determinare cosa inviare al client. L'ultima parte, #fragment , è visibile solo per il tuo browser.

Prendi questo URL di esempio da Zerobin:

zerobin.net/?5cd884d7e1409f31#25LMCTnmrN3H/BPcebRjH6Gl05Sklj91CssV45YwQ/o=
|   host  |    identifier    |            base64 encoded key              |

In questo esempio, il dominio è, ovviamente, l'indirizzo del server. L'identificatore è il percorso che specifica quale tipo di pasta crittografata viene richiesta. Quando la pagina viene recuperata, il frammento non viene mai inviato al server. Quando si preleva un file, tutto ciò che vede il server è questo (in questo esempio, utilizzando cURL anziché un browser Web):

GET /?5cd884d7e1409f31 HTTP/1.1
Host: zerobin.net
User-Agent: curl/7.56.1
Accept: */*

Questo dice al server di recuperare il post criptato e di servirlo, insieme al JavaScript richiesto per decodificarlo. Se la chiave non è corretta o la chiave non è presente, il codice sulla pagina non sarà in grado di decrittografarlo. Questo ha lo scopo di assicurare che il testo in chiaro sia visibile solo a chi ha l'URL. Spetta a loro decidere se l'URL debba essere distribuito o mantenuto relativamente segreto. Questa tecnica potrebbe essere facilmente modificata per utilizzare una password piuttosto che un frammento di URL, ma se il problema sta semplicemente riducendo PI, questo dovrebbe essere abbondante.

Ulteriori informazioni su questa specifica informazione si trovano nella pagina del progetto Zerobin .

Con un'ingegneria sufficiente, questo può essere fatto per immagazzinare molto più delle semplici paste di testo. Mega ad esempio supporta l'accesso allo storage come un filesystem. Esiste anche un'utilità che monta la directory utente online come un filesystem usando FUSE, consentendo l'interazione usando azioni generiche del filesystem, assicurando al contempo il server che non sa a cosa accede. La tua applicazione potrebbe essere fatta per farlo se questo soddisfa i tuoi requisiti.