Ci sono momenti in cui un utente malintenzionato potrebbe avere accesso per recuperare dati dal database (ad esempio SQL Injection) ma non ha accesso sufficiente per estrarre la chiave di crittografia dal web.config. In queste situazioni questa pratica aggiungerebbe un altro livello di difesa contro il cracking delle credenziali dell'utente.
Sicuramente non è infallibile poiché un compromesso a livello di server operativo potrebbe consentire all'aggressore di estrarre le chiavi di crittografia insieme al database degli utenti. Un utente malintenzionato potrebbe anche essere in grado di eseguire comandi tramite SQL injection che forniscono accesso ai dati web.config.
Se vale la pena è una sentenza che dovrai fare. Aggiungerà un sovraccarico e una complessità al processo di autenticazione per un leggero miglioramento della sicurezza. Se il tuo database delle credenziali è compromesso, sarai in grado di dire ai tuoi utenti che non ritieni che le loro password siano state esposte - supponendo che tu sappia per certo che la chiave non è stata rubata - ma probabilmente continuerai a chiedere loro di creare nuove password sicure.
Adobe ha crittografato le password dei clienti e, mentre milioni di loro sono trapelate un anno fa, non è ancora stata resa pubblica la chiave di crittografia. Queste credenziali potrebbero comunque essere considerate protette se non fosse per i suggerimenti associati alla password che spesso spiegano in modo esplicito quale sia la probabile password utilizzata.