Crittografia sicura e reversibile per l'archivio dati locale

Naviga le tue risposte
4

Sto lavorando a un software per archiviare e gestire record per un gruppo giovanile. Hanno scoperto che gran parte del tempo che passano per la tenuta dei registri e l'amministrazione viene assorbito dalla scansione alla ricerca di varie condizioni, come "è più vecchio di X anni e ha la qualifica Y" o "è stato un membro per X anni" e ha fatto Y evento più di due volte ", o" ha fatto eventi X, Y e Z e quindi ha bisogno del premio A ". Come programmatore, ho riconosciuto che questo genere di cose poteva essere facilmente gestito da un computer, risparmiando così ore di lavoro, quindi sto costruendo un'applicazione per prendermene cura.

Fino ad ora, i loro registri sono stati tenuti su carta o in fogli di calcolo Excel, quindi si potrebbe sostenere che non ho bisogno di crittografare nulla perché non erano crittografati prima, ma non mi sento del tutto a mio agio con la scrittura di un programma che memorizza informazioni su bambini minorenni (di età compresa tra i 14 ei 18 anni) senza avere un modo per controllare chi può ottenere tali informazioni.

Non ho mai fatto veramente la crittografia prima, quindi non sono sicuro da dove cominciare qui. Ho implementato numerosi schemi di gestione delle password, quindi ho familiarità con alcuni dei principi, ma utilizza nonces e metodi di crittografia unidirezionale come gli hash, nessuno dei quali può essere utilizzato qui perché devo essere in grado di ottenere i dati di nuovo indietro. Il meglio che posso pensare è usare una password (più "salata") in testo semplice come chiave per crittografare in qualche schema a due vie, ma poi memorizzare solo l'hash di di quella password per verificare all'accesso. La password verrà quindi archiviata in memoria mentre il programma è in esecuzione, tuttavia, e vorrei ridurre la quantità di tempo in cui la password è ovunque diversa dalla memoria dell'utente.

Comprendo che mettere questi dati in un luogo diverso da un server che posso controllare aumenta il rischio, ma ho bisogno che questi dati siano accessibili offline. Qualcuno può spiegare un modo solido per archiviare questi dati?

    
posta anaximander 20.04.2013 - 16:14
fonte

2 risposte

1

Puoi ricorrere a un database MySQL, per sfruttare il suo supporto per la crittografia .

Quindi hai due opzioni (in realtà puoi utilizzarle entrambe):

1) Alcuni dati possono essere lasciati in testo semplice, ma resi anonimi - cioè, non c'è modo di sapere a chi si riferiscono i dati.   2) Altri dati sono crittografati, utilizzando un algoritmo simmetrico. La chiave per farlo sarà casuale e crittografata usando la password dell'utente. In questo modo, diversi utenti possono accedere agli stessi dati 

User    Password   CryptoKey
alice   <hash1>    <encrypt(pwd1, RANDOM)>
bob     <hash2>    <encrypt(pwd2, RANDOM)>

Per autenticare, Alice invia la sua password, che viene controllata con l'hash memorizzato. Se è valido, la chiave RANDOM viene estratta e archiviata nella memoria del server per la durata della sessione.

I campi Testo e BLOB possono quindi essere crittografati (con o senza salatura). Brevi campi o campi con cardinalità bassa sono meglio salati, altrimenti il contenuto può essere facilmente indovinato: ad esempio un campo che contiene 'Maschio' o 'Femmina', dopo la crittografia non salda potrebbe contenere 'e3290d6cd47a701168b962aa0c6b249e' o 'd87d344d4808900421c93de58dd7557a' - ma questo è ancora solo due valori, che è una potenziale vulnerabilità.

Cambiare la password di Alice non è un granché; naturalmente, se RANDOM viene esposto, questo è un grosso problema. Le comunicazioni con il front-end dovrebbero passare attraverso SSL / TLS e contenere dati RANDOM decrittografati (ma crittografati con SSL), proteggendo così la sicurezza di RANDOM, che non lascia mai il server.

Inutile dire che l'accesso fisico alla memoria del server comprometterà tutto, dal momento che sarebbe facile eseguire un attacco man-in-the-middle e indurre un utente valido a rivelare la sua password, da cui è possibile ottenere RANDOM e l'archivio dati decrittografato.

Opzionalmente, puoi crittografare anche la connessione al database , ma sembra un po 'eccessivo (probabilmente saranno locali comunque) e comunque non ti proteggerà dal server che viene sfruttato.

I dati possono essere sincronizzati tra un database MySQL locale e remoto senza conoscere la password, scaricando un dump del database (che è fattibile se la dimensione dei dati è piccola, ricorda che i dati crittografati non sono comprimibili ) o mantenendo un registro degli aggiornamenti, che è molto più difficile (pensa 'Alice sul suo laptop modifica un record mentre Bob sul suo desktop cancella quello stesso record, e Charlie inserisce un nuovo record con una nuova chiave primaria ... ').

Francamente, la soluzione migliore che ho trovato in questi casi è quella di posizionare tutto su un server affidabile con un piano di backup appropriato e fare in modo che i client si connettano al server. Di solito è più veloce ed economico fornire ai client non connessi con connettività Internet piuttosto che progettare il database per l'utilizzo offline, la sincronizzazione e la risoluzione dei conflitti. Le copie Sola lettura potrebbero essere distribuite, ovviamente. Solitamente il server remoto può essere configurato per inviare e-mail ed eseguire lavori cron e informare i clienti di qualsiasi evento (ad es. "Janie ha conseguito il premio A2").

Esponendo solo un'interfaccia REST, è possibile sfruttare diversi framework applicativi e avere anche un'applicazione lato server più semplice e testabile (i punti di ingresso e i percorsi del flusso di lavoro sono pochi in base alla progettazione e possono essere enumerati), il che riduce sensibilmente il rischio di exploit del server.

Un'altra possibilità

Dato che il database master risiede su un server centrale e una copia delle stesse vite locali, è possibile mantenere l'applicazione e il database su una chiave USB esterna crittografata. Il database stesso non ha crittografia; potresti utilizzare SQLite localmente. Se utilizzi MySQL, puoi eseguirlo tramite App per dispositivi portatili o qualcosa di simile.

Quindi, il flusso di lavoro sarebbe: l'utente inserisce la chiave USB, che richiede un PIN o anche un impronta digitale . Una volta sbloccato, può eseguire l'applicazione, che se necessario (ad esempio MySQL, PostgreSQL, ...) attiverà il server e si connetterà ad esso; o accederà direttamente ai dati (SQLite). Al termine, il server (se presente) viene arrestato, la chiave viene espulsa e i dati su di esso sono a prova di ogni ragionevole minaccia.

Tornando all'intervallo di connettività, l'utente attiva nuovamente l'applicazione e la sincronizza con il server centrale.

Questa soluzione ha il vantaggio che la sicurezza è un plug-in con un costo noto. Gli utenti possono decidere di non pagare quel costo, ma è la loro decisione , non il tuo .

    
risposta data 20.04.2013 - 18:41
fonte
3

Cifra i dati con un algoritmo strong come AES . Utilizza pbkdf2 o bcrypt per ricavare la chiave di crittografia da una password.

Hai bisogno di un modo per propagare e aggiornare i dati, a meno che la soluzione non sia pensata per un solo computer (Se è così, basta usare fogli di calcolo Excel, perché preoccuparsi di scrivere un'applicazione?). Chiedere al client di connettersi al server per aggiornare il database e / o scaricare nuovi dati dal database. Chiedere all'autenticità del client di utilizzare certificati e proteggere la connessione su SSL / TLS.

    
risposta data 20.04.2013 - 17:13
fonte

Leggi altre domande sui tag

Creazione e distribuzione di certificati autofirmati per uno scenario su due macchine In quali modi un javascript che effettua una richiesta HEAD su più domini può essere una minaccia?