Uso de PasswordBox con WPF - MVVM

Question

He leído varios artículos sobre cómo usar las Propiedades adjuntas para vincular el valor de un PasswordBox en WPF. Sin embargo, cada artículo también hace referencia a la documentación de .NET que explica por qué PasswordBox no se hizo enlazable en primer lugar.

No me considero un experto en seguridad de ninguna manera, pero me imagino que alguien en Microsoft sabía lo que estaban haciendo, y no debería esforzarme al máximo para deshacerlo.

Entonces, en cambio, se me ocurrió mi propia solución.

public class LoginViewModel 
{ 
    // other properties here 

    public PasswordBox Password 
    { 
     get { return m_passwordBox; } 
    } 

    // Executed when the Login button is clicked. 
    private void LoginExecute() 
    { 
     var password = Password.SecurePassword; 

     // do more stuff... 
    } 
} 

Entonces, en mi XAML, sólo han prestado los PasswordBox mediante la unión del campo de contraseña a un ContentPresenter.

Así que mi pregunta es ... ¿hay algún problema al hacerlo de esta manera? Me doy cuenta de que estoy rompiendo el MVVM de alguna manera al permitir que los controles reales aparezcan en mi ViewModel, pero al menos esto parece más correcto que simplemente desproteger el campo de contraseña.

Si esto es, de hecho, un problema, ¿alguien ha presentado una solución que no implique el uso de Propiedades adjuntas y el almacenamiento de la contraseña en el modelo de vista?

Gracias! -J

Answer 1

¿Qué hay de malo en almacenar la contraseña en la VM al menos mientras es necesaria durante el inicio de sesión? Tiene razón en que, según el patrón de MVVM, la VM no debería tener una referencia a un control como PasswordBox.

En la vista, agregue un controlador al evento PasswordChanged. En el controlador, actualice una propiedad SecureString en la máquina virtual con SecurePassword de la contraseña.

Answer 2

Me gusta tu idea.

Sí, se están violando las mejores prácticas ViewModel aquí, pero

• mejores prácticas son "recomendaciones que funcionan bien en la mayoría de los casos" en lugar de reglas estrictas y
• escritura sencilla, de fácil lectura-, código que se puede mantener y evitar la complejidad innecesaria es también una de esas reglas de "mejores prácticas" (que podrían ser violadas levemente por la solución de "propiedad adjunta").

Ya sea rompiendo la barrera Vista/modelo de vista que aquí será un problema para usted o no depende de qué está utilizando ViewModels en el primer lugar (por ejemplo, la separación de las preocupaciones, las pruebas unitarias, reutilización), por lo que no puedo responder eso.

Answer 3

es solo una opinión espero que pueda ayudarlo.

1. Creo que la idea de no tomar Password como DP es que es fácilmente rastreado por un software externo como SNOOP.
2. La menor dependencia en View Model que tenga, mejor será su código. lo ayudará con las pruebas unitarias y la Actualización o los cambios (¿qué haría si en el futuro desea utilizar un cuadro de contraseña de un tercero?)
3. Deseche el estado "El código no sirve". Úselo con prudencia.

considerar esto en su código detrás:

void loginButton_Clicked(object s, EventArgs e) 
{ 
    myViewModel.Password = txPwdBox.Password; 
    myViewModel.Login(); 
} 

Answer 4

mis 2 centavos:

cifrar la contraseña en el modelo de vista, utilizar las propiedades adjuntas, y utilizar un ValueConverter para cifrar/descifrar el contraseña. con esto, incluso si alguien usa snoop, entonces todo lo que ven son los datos encriptados.

díganos qué funciona mejor con su situación