¿La clase ProtectedData sigue siendo un método aceptable para almacenar contraseñas?

5

Estoy escribiendo un software que tendrá que almacenar una contraseña de usuario para permitir la autenticación con un servicio de terceros. Desafortunadamente, este servicio actualmente requiere el uso de una contraseña en lugar de algún otro método. Una característica / ventaja clave de este software será la eliminación de un aviso de inicio de sesión (después de la primera autenticación), por lo que es imprescindible que almacenemos la contraseña.

Tengo la intención de usar .NET ProtectedData clase para esta operación.

Básicamente estoy preguntando: ¿es esto aceptable en 2015? ¿Existe un método mejor y más seguro para almacenar estos datos?

Más detalles según lo solicitado: el software es del lado del cliente, diseñado para ejecutarse en el contexto de los usuarios en los escritorios de Windows. Estas máquinas generalmente van a ser máquinas "administradas" (es decir, bajo el control de un departamento de TI), pero me baso en la presunción de que este software podría ser instalado en cualquier cliente, por cualquier usuario.

Por lo tanto, esencialmente debo suponer que en cualquier momento una máquina podría perderse / ser robada. Dicho esto, si una cuenta de usuario se ve comprometida, eso ya es más perjudicial que un posible compromiso de esta contraseña.

    
pregunta Dan 25.03.2015 - 16:58
fuente

1 respuesta

4

Sí, este es uno de los casos de uso para los que se diseñó expresamente la Información Protegida (y la DPAPI subyacente), y generalmente es probablemente el mejor mecanismo a su disposición.

Una cosa que agregaría es que es mejor configurar DataProtectionScope en CurrentUser, que ofrecerá una mayor protección, ya que los datos no están disponibles para otros usuarios y se procesan en la máquina como cuando el alcance se establece en LocalMachine.

    
respondido por el Xander 25.03.2015 - 18:17
fuente

Lea otras preguntas en las etiquetas