Hay ocasiones en que un atacante puede tener acceso para recuperar datos de su base de datos (por ejemplo, inyección de SQL) pero no tiene suficiente acceso para extraer la clave de cifrado de su web.config. En estas situaciones, esta práctica agregaría otra capa de defensa contra el craqueo de credenciales de usuario.
Definitivamente no es infalible, ya que un compromiso en el nivel del sistema operativo del servidor podría permitir al atacante extraer claves de cifrado junto con la base de datos del usuario. Un atacante también podría ejecutar comandos a través de la inyección SQL que proporciona acceso a los datos web.config.
Si vale la pena es una decisión de juicio que tendrás que hacer. Agregará cierta sobrecarga y complejidad a su proceso de autenticación para una leve mejora de la seguridad. Si su base de datos de credenciales está comprometida, podrá decirles a sus usuarios que no cree que sus contraseñas estuvieran expuestas, suponiendo que esté seguro de que la clave no fue robada, pero es probable que aún le dé instrucciones para crear una nueva. contraseñas para estar seguro.
Adobe cifró las contraseñas de sus clientes, y aunque millones de ellas se filtraron hace un año, todavía no se ha divulgado públicamente la clave de cifrado. Estas credenciales aún podrían considerarse protegidas si no fuera por las sugerencias de contraseña adjuntas que a menudo explicaban descaradamente qué contraseña probable se utilizó.