La crittografia a chiave pubblica è la scelta corretta?

Stai parlando di generare una chiave pubblica / privata per ciascun utente. Questo è eccessivo. Invece, assicurati di utilizzare un certificato SSL firmato con TLS 1.2 (o successivo) per le comunicazioni tra l'app e il tuo server. Per comprendere meglio il processo, leggi Come funziona SSL / TLS?

Per tenere separati i dati, è qui che entra in gioco qualcosa come una sessione (la maggior parte dei linguaggi di programmazione Web supporta un tipo di gestione delle sessioni). Le sessioni memorizzano i dati sul server e quindi forniscono all'utente un hash casuale di qualche tipo. Mentre c'è sempre la possibilità di avvelenare una sessione (dove ottengo l'hash di qualcun altro), le probabilità sono generalmente basse. Non sono più alti del tentativo di scambiare chiavi pubbliche / private (che dovranno essere fatte prima di inviare qualsiasi dato).

Una volta che hai una sessione, puoi memorizzare qualcosa come un ID utente all'interno (l'utente non può accedere direttamente a questo e non vederlo mai). Quindi, quando l'utente richiede un record, verifichi se quell'utente può accedere a quel record e consentire / rifiutare di conseguenza.

Come menzionato nella risposta di @machavity, l'utilizzo di una chiave privata pubblica per ogni utente qui non è una buona soluzione.

• Data will always be input into the app and viewed via the website, so only users of the website will need a public and private key as only they need to view the information (could use hybrid, but messages will be short)
• Encrypt the data server-side using the public key of the correct user authorised to view the information

Che cosa succede se gli utenti vogliono condividere dati tra loro?

• The encrypted data will be stored in the database

Mentre è possibile eseguire query per gli utenti individualmente, cosa succede se si desidera eseguire alcune query sui dati di più utenti? Dì di provare a trovare modelli o cose

Ecco cosa dovresti prendere in considerazione:

• Chiede agli utenti di creare account sia sull'app che sul sito web. In questo modo, avrai un'identità unica di ciascun utente
• Utilizza i meccanismi di controllo dell'accesso per garantire che una determinata identità possa accedere solo ai dati a cui hanno accesso
• Considerando che i dati sono sensibili, implementa le comunicazioni TLS tra la tua app e il sito web.
• Lascia i dati nel database così com'è. Ovviamente con le eccezioni delle password!

(Suppongo che tu abbia già crittografato la connessione con HTTPS che dovresti fare.)

È normale lasciare i dati nel database non crittografati. Questo è necessario per consentire l'interrogazione del database in un formato batch. (Voglio vedere tutti in un particolare codice postale, o vedere chi ha un particolare indirizzo email, quali nomi utente sono presi, ecc.) Il controllo degli accessi è possibile in entrambi i modi.

Se l'interrogazione in formato batch non è richiesta, la crittografia (cioè il contenuto del messaggio) può essere una buona funzionalità di sicurezza. Questa è solitamente una seconda linea di difesa nel caso in cui il server sia compromesso.

Un problema con la crittografia memorizzata è come memorizzare la chiave di crittografia. Se l'applicazione client non è abbastanza intelligente / affidabile da gestire il file chiave, deve essere memorizzata sul server. Ma se memorizzi la chiave sul server e i dati crittografati, un hacker potrebbe teoricamente arrivare a entrambi.

(La tua password di accesso utente dovrebbe essere hash naturalmente, non crittografata.)

Anche con questi problemi, dovresti crittografare qualsiasi informazione particolarmente sensibile, come password ad altri servizi, SSN, documenti super-secret, ecc. nel caso in cui il tuo server sia compromesso a causa di qualche altro difetto.

(Anche i numeri delle carte di credito dovrebbero essere crittografati, ma per evitare problemi PCI DSS lo si dovrebbe esternalizzare al gateway di elaborazione.)

Un'opzione consiste nell'avere una chiave di crittografia master singola e archiviarla al di fuori del database. In questo modo se un hacker utilizza SQLi per ottenere dati crittografati nel database, non avrà ancora accesso alla chiave perché si trova all'esterno del database. Tuttavia per altre violazioni oltre a SQLi probabilmente sarebbe in grado di trovare il file chiave abbastanza facilmente.

Se ti senti ambizioso, puoi ricavare le chiavi dalle password dell'utente come questa . Questo probabilmente non sarebbe compatibile con la funzione di reimpostazione automatica della password però.

Ma come ho detto è più comune lasciare i dati non crittografati. In particolare se i dati non sono eccessivamente sensibili o se è necessario utilizzare una query batch del database per accedervi.