Come (a livello di programmazione o con altri mezzi) crittografare o proteggere i dati dei clienti

Question

Come (a livello di programmazione o con altri mezzi) crittografare o proteggere i dati dei clienti

#1 da (4 voti)

5

Sto lavorando a un progetto web e voglio (per quanto possibile) gestire i dati degli utenti in modo da ridurre i danni alla privacy degli utenti in caso di compromissione dei nostri server / database.

Ovviamente abbiamo solo i dati dell'utente necessari per il sito Web per fare il suo lavoro, ma a causa della natura del progetto abbiamo un bel po 'di informazioni sui nostri utenti (parte della funzionalità è applicarsi ai lavori e inviando il tuo cv con esso)

Abbiamo pensato di crittografare / decifrare i dati sensibili con una coppia di chiavi privata / pubblica di cui la chiave privata è crittografata con la password degli utenti, ma ha riscontrato alcuni problemi di sicurezza e implementazione con questo: P

la domanda è: in che modo implementa la privacy degli utenti e una protezione contro il furto di dati su server Web centralizzato con protocolli compatibili con browser mentre per funzionalità è necessario che gli utenti possano scambiare dati sensibili?

Per dare ulteriori informazioni: questo progetto non è ancora in fase di produzione, quindi c'è ancora tempo per sistemare le cose.

stiamo già facendo alcune cose di base come

che serve https
applicare https per i siti che potrebbero gestire dati sensibili
hashing salted password
un po 'di tempra del nostro server e dei nostri servizi
hard disk crittografati per impedire a qualcuno di leggere tutte le informazioni sul client dopo aver rubato i nostri server / hard disk

ma questo è tutto, c'è oltre alla password hash nessun meccanismo che fermerebbe / almeno renderà più difficile per qualcuno che è riuscito a entrare (parte del) server per ottenere tutti i dati su tutti i nostri utenti. Né vediamo un modo per crittografare i dati degli utenti per disabilitarci dalla loro lettura in quanto abbiamo bisogno dei dati (altrimenti non li avremmo raccolti) per una parte del sito web / la funzionalità che vogliamo che fornisca. Anche se per esempio abbiamo gestito (forse con qualche javascript) che tutti i dati sarebbero arrivati a noi crittografati (dal browser del cliente) e serviamo al client la sua privatekey crittografata con qualche passphrase (come ad esempio la sua password di accesso) non potremmo esaminare i file caricati dall'utente di scansione per virus e simili. D'altra parte una crittografia lato client almeno con il concetto browser / webserver lascia alcuni problemi di sicurezza almeno come la immaginiamo (sei il benvenuto a dimostrarmi che non sbaglio) e sembra piuttosto come reinventare la ruota, e forse come questo progetto non riguarda principalmente la privacy, ma piuttosto la privacy è una proprietà prefissabile per la quale potremmo non voler reinventare la ruota. Credo fermamente che non sono il primo webdeveloper a pensarci, vero? Quindi cosa hanno fatto altri progetti? Che cosa hai fatto per cercare di proteggere i dati degli utenti?

se rilevante utilizziamo django e postrgreSQL per la maggior parte delle cose e javascript per alcune interfacce utente

ps: questo articolo descrive altri motivi per cui siamo titubanti sulla crittografia lato client

client-side privacy consumer-protection

posta Freebejan 13.06.2014 - 10:18

fonte

1 risposta

Leggi altre domande sui tag client-side privacy consumer-protection

OpenSSL Heartbeat (Bug heartbleed) - a cosa serve il payload? [duplicare] Perché un utente malintenzionato tenta di indovinare nomi utente e-mail casuali su un dominio di piccole dimensioni?

score 4 · Answer 1

Un metodo standard utilizzato per qualcosa di simile è la crittografia a livello di applicazione.

Il tuo progetto consiste in un livello web (Django) e un livello di database (PostgreSQL). Se si implementa la crittografia in Django, è possibile scrivere blob crittografati nell'archivio dati di PostgreSQL. A proposito, non si tratta della "crittografia lato client" come descritto nell'articolo a cui ci si collega.

Il vantaggio di questo metodo consiste nel separare i dati crittografati dalle chiavi. Un utente malintenzionato che è in grado di eseguire il dump delle tabelle dal database può ottenere i dati crittografati, ma non le chiavi. Un utente malintenzionato che è in grado di compromettere la tua applicazione ed estrarre la chiave deve ancora ottenere che i dati utilizzino la chiave.

Lo svantaggio di questo metodo è che i dati crittografati non possono essere cercati o manipolati esclusivamente a livello di database. Se si tratta di password, va bene; non starai SELEZIONANDO tutte le password con determinati criteri, di solito ne tirerai solo uno e lo confronterai. Ma per altri tipi di dati che possono essere onerosi.

Aggiorna per indirizzare il commento di seguito nella lunghezza corretta:

Sì, se l'utente malintenzionato compromette l'applicazione, è possibile che compromettano la chiave e, eventualmente, sfruttino l'accesso al database dell'applicazione per sfruttare la chiave. Allora, perché è meglio?

Prima di tutto, rimuove alcuni comuni attacchi touchdown a singolo vettore. Ad esempio, se l'app Web soffre dell'iniezione SQL, un utente malintenzionato può in genere estrarre le tabelle complete dal database. Ma non possono estrarre la chiave dall'applicazione nello stesso modo, e quindi avranno bisogno di un altro attacco di successo separato per raggiungere il loro obiettivo.

L'attaccante può aspettare qualcosa di interessante, ma se compromette l'app, è probabile che possa intercettare gli input e le informazioni di compromissione presenti prima che vengano inviati al database; l'accesso alla chiave è irrilevante a quel punto. E questo richiede un compromesso e una pazienza a lungo termine, il che è meno preoccupante a meno che tu non sia un bersaglio nello spazio APT.

È possibile implementare controlli compensativi per limitare l'impatto del compromesso del livello applicazione. Ad esempio, se l'applicazione ha accesso solo a determinate stored procedure e non alla possibilità di eseguire SQL arbitrario sul database, anche se l'utente malintenzionato compromette l'applicazione e ottiene la chiave, potrebbe non essere in grado di sfruttarla per ottenere dati di massa . Qualsiasi iterazione per ottenere dati frammentari è molto più probabile che venga catturata da strumenti di registrazione, avviso o monitoraggio SQL.

E, anche se meno comune, l'archiviazione separata della chiave impedisce attacchi di backup che hanno accesso ai file di backup del database.

Non esiste una sicurezza perfetta, ma la difesa in profondità è un metodo collaudato per migliorare la sicurezza. Separare la chiave di crittografia dai dati crittografati in un'applicazione multilivello è un eccellente contributo alla difesa in profondità.