Crittografia lato client con sostenibilità come servizio

He will always provide his key to decrypt data.

Bene, se si tratta di dati sensibili che vengono mantenuti crittografati, sarebbe opportuno evitare di trasmettere una chiave che sta trattenendo tramite la rete. Se intendi semplicemente crittografare la linea, allora sì, HTTPS lo farà, ma ciò non garantisce che solo lui possa vedere i dati, come tu già sai, ne hai il possesso.

Should i go for it or rely only on good https, password strength and server database encryption?

Https protegge i dati in transito. La crittografia a livello di database protegge i dati a riposo. Tuttavia, l'unica garanzia che tu o chiunque amministrando il server non è in grado di vedere i dati è che non hai mai le chiavi di decodifica in nessun punto del processo. Se l'utente ti invia la chiave, potresti essere malevolo e tenerlo per sempre.

Pertanto, per essere sicuro, l'utente deve tenere la chiave in mano e non deve mai vederlo.

Le tue opzioni e i tuoi requisiti non sembrano corrispondere. Se ti affidi a HTTPS, forza della password e crittografia del database del server, l'amministratore può, infatti, accedere ai dati decrittografati. SO , se il requisito 1 è effettivamente un requisito, questa opzione non è valida. Se, tuttavia, il requisito 1 è semplicemente un "bello da avere", allora questa opzione potrebbe funzionare.

Quindi, la domanda è: il requisito 1 è effettivamente un requisito? Se lo è, la tua unica vera opzione è la crittografia lato client. Per qualsiasi ragionevole garanzia di integrità, ciò richiede o un'applicazione client o un plug-in del browser senza meccanismi di aggiornamento automatico. I meccanismi basati su server sono semplicemente troppo facili da sovvertire per essere seri concorrenti.