Devo crittografare i dati sul mio server come ulteriore livello di protezione?

Question

Devo crittografare i dati sul mio server come ulteriore livello di protezione?

#1 da (4 voti)

0

Creerò un'applicazione client-server che memorizza le informazioni finanziarie sensibili di un utente sul server. Vorrei crittografare questi dati in modo che anche se un hacker ottiene l'accesso al server non è in grado di leggere le informazioni finanziarie dell'utente. I dati verranno decrittografati dal client con la password dell'utente.

Per ulteriori difficoltà, a un utente può essere concesso l'accesso ai dati di un altro utente.

È fattibile? In tal caso, esiste una guida in linea che fornisce un esempio dei tipi di crittografia da utilizzare?

Ad esempio, penso che ogni utente debba avere una chiave privata derivata dalla sua password e una chiave pubblica corrispondente che viene utilizzata per crittografare i suoi dati sul server. Questa chiave pubblica è anche memorizzata sul server, in modo che se Alice volesse dare a Bob l'accesso ai suoi dati, lei annullerebbe la crittografia dei suoi dati usando la sua chiave privata, quindi la ricodificherà usando sia la chiave pubblica che quella di Bob. Un problema con questo approccio è che se un hacker ottiene l'accesso ai dati crittografati, potrebbe utilizzare la "forza bruta" provando ogni combinazione di, diciamo, 8 caratteri come password per vedere se tale combinazione non codifica i dati. Pertanto, desidero rendere il processo di decrittazione così lento che non è pratico utilizzare la forza bruta. Esiste un algoritmo di chiave pubblica-privata?

Modifica: Ok, dopo un po 'di ricerche ho scoperto che ci sono un sacco di algoritmi di hash (come PBKDF2) progettati per essere lenti perché prendono un parametro di iterazione che può essere grande quanto vuoi.

cryptography encryption

posta Mark 20.07.2012 - 07:22

fonte

1 risposta

Leggi altre domande sui tag cryptography encryption

Utilizzo del desktop remoto Che cos'è un "uovo del cuculo"? [chiuso]

score 4 · Answer 1

Qui vedo molti difetti:

Se un account è comprimato, vengono rivelati i dettagli di ogni persona che sono protetti contro la loro chiave privata. Ciò mette la sicurezza degli utenti nelle mani di altri utenti , che è probabilmente la peggiore situazione in cui trovarsi.
Gli utenti scelgono password terribili, che nessuna funzione di derivazione della password può salvarle da. Anche se stai utilizzando un fattore di lavoro in PBKDF2 o bcrypt che garantisce che un utente malintenzionato non possa calcolare più di un hash al secondo, supporterà password deboli come "letmein1" e "a1b2c3" dopo meno di un minuto.
Non è possibile crittografare dati di lunghezza arbitraria con RSA (chiave pubblica / privata), quindi è necessario crittografare i dati con un codice a blocchi, utilizzando una chiave surrogata generata a caso, quindi crittografare quella chiave con le chiavi pubbliche degli utenti .
Il tuo protocollo non fornisce informazioni di autenticità. Un utente malintenzionato potrebbe utilizzare la chiave pubblica di un utente per crittografare una serie di false informazioni finanziarie, quindi inserirla nuovamente nel database. Dovresti contrastarlo firmando i dati con la chiave privata dell'utente, che aggiunge complessità extra quando permetti ad altri utenti di accedere ai dati.
Stai crittografando e decodificando molto i dati, quindi ti rendi più suscettibile agli attacchi da canale laterale come DPA e attacchi temporali . Dovrai tenerne conto e prendere contromisure.
Poiché le informazioni sono finanziarie, dovrai ospitare il tuo server in una struttura con una certa sicurezza fisica.
Avrai bisogno di usare una strong sicurezza di trasporto. Non puoi semplicemente utilizzare alcun vecchio certificato SSL: probabilmente avrai bisogno di qualcosa come un certificato EV con AES a 256 bit.
In genere è una cattiva pratica archiviare informazioni finanziarie in un database di qualsiasi tipo. Una soluzione più adatta è un HSM .
Non sono sicuro della situazione legale nel tuo paese, ma potresti essere obbligato ad aderire a PCI-DSS , la legge sulla protezione dei dati o qualsiasi altro numero di regolamenti. La maggior parte di questi richiede audit, che non sono economici e non sono facili da superare.

In tutta onestà, questo intero schema sembra un incidente che aspetta di accadere, specialmente dal momento che sei un principiante con cripto. Il mio consiglio è non archiviare informazioni finanziarie riservate a meno che tu non sia un processore di pagamenti o una banca e abbia una strong esperienza in sicurezza . La regola numero 1 di sicurezza è "la sicurezza è difficile". Sbagliare mette in pericolo i tuoi clienti e ti prepara per una serie di costose azioni legali. Se sei un'azienda che cerca di vendere oggetti o fornisce un servizio a pagamento, utilizza una società di elaborazione dei pagamenti che già aderisce a procedure e standard di sicurezza rigorosi.