Nulla è inutile e non ci sono proiettili d'argento. Tutto dipende.
C'era una barra laterale sull'utilizzo della crittografia del disco. Questo è proteggere da una superficie di attacco diversa, quindi lasciala ignorare.
La domanda chiede se abbia senso crittografare i dati che si trovano in un database, supponendo che debba essere un testo in chiaro per un client web. Le scelte presentate consistono nell'utilizzare un token master (esterno al database) per decrittografare il cryptotext memorizzato, o per usare un token fornito dall'utente, con l'osservazione che questa è una cattiva idea e non funzionerebbe per la collaborazione.
Se la preoccupazione è che qualcuno possa violare la riservatezza del server web, ad esempio per passare in rassegna il token master memorizzato e il database, in realtà non si è fortunati. La mitigazione qui è che spesso la violazione del database e la violazione delle configurazioni web sono diverse, e l'una senza l'altra non è utile. Quindi è protettivo, ad esempio, nel classico esempio di un attacco sql injection che scarica il DB.
A quel punto, usare un token fornito dall'utente è molto utile, e non lo definirei una cattiva idea. Si noti che in teoria questo può essere ancora utile nelle app collaborative: il crittotesto memorizzato può essere crittografato utilizzando un codice di flusso la cui chiave è crittografata (ad esempio tramite una PKI) contro le chiavi di più persone. Ora, la riservatezza del server non è un problema (supponendo che non abbiano accesso al runtime) - nessuna raccolta di informazioni sul server può trasformare il cryptotext in testo normale senza i token dell'utente.
Tuttavia, se l'integrità del server è in questione, questa soluzione non riesce. Il testo in chiaro è nella memoria del server, quindi il suo gioco su ... il programma può essere riconfigurato per mantenere il testo in chiaro ovunque desiderato, o anche per cambiare la messaggistica tra i client. Ecco dove entra in gioco la terza soluzione. Se si dispone di codice in esecuzione sul computer client che esegue la decrittografia delle informazioni trasmesse e la crittografia di qualsiasi risposta, si torna in acqua sicura. (Anche se, naturalmente, ora è giù per l'opsec dei client finali, ma è sempre così.)
Quindi valuta i rischi e i costi dei vari casi di perdita di integrità sul server e fai la tua scelta.
Barra laterale: se davvero ti interessa questa roba, smetti di usare le password. Se non lo fai, IMHO un token master va bene.