Использование PasswordBox с WPF - MVVM

Я прочитал несколько статей о том, как использовать Attached Properties для привязки к значению PasswordBox в WPF. Тем не менее, каждая статья также ссылается на документацию .NET, в которой объясняется, почему PasswordBox не был создан в первую очередь.Использование PasswordBox с WPF - MVVM

Я не считаю себя экспертом по безопасности любым способом, но я полагаю, что кто-то из Microsoft знал, что они делают, и я не должен прилагать усилия, пытаясь его отменить.

Итак, вместо этого я придумал свое решение.

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... 
    } 
}

Тогда в моем XAML, я просто визуализировать PasswordBox связыванием поле Пароль к ContentPresenter.

Так что мой вопрос ... есть ли проблема с этим? Я понимаю, что я как бы разбиваю MVVM таким образом, позволяя реальным элементам управления отображаться в моей модели ViewModel, но по крайней мере это кажется более правильным, чем просто снятие пароля.

Если это, по сути, проблема, может ли кто-нибудь придумать решение, которое не связано с использованием Attached Properties и сохранением пароля в ViewModel?

Спасибо! -J

источник

2010-08-09 jeremyalan

В чем проблема с приложенным имуществом? Является ли это, что тип свойства является строкой? Почему бы не сделать SecureString? –

Как я уже сказал выше, казалось, что причина была в том, что это не был DependencyProperty, поэтому найти работу вокруг, казалось, был неправильным подходом. Полагаю, я мог бы просто «привязать» к свойству SecurePassword. – jeremyalan

Проблема, когда свойство Password является связующим: это значение легко отслеживается внешним программным обеспечением. таких как SNOOP. как легко украсть ваш пароль. – ktutnik

Что не так с сохранением пароля в виртуальной машине, по крайней мере, когда это необходимо во время входа в систему? Вы правы, что в соответствии с шаблоном MVVM виртуальная машина не должна иметь ссылку на элемент управления, такой как PasswordBox.

В представлении добавьте обработчик события PasswordChanged. В обработчике обновите свойство SecureString в виртуальной машине с помощью SecurePassword в пароле.

источник

2010-08-09 22:19:20

Как уже упоминалось выше, я не эксперт по вопросам безопасности, я просто стараюсь следовать рекомендациям, изложенным в документации. Но существуют ли какие-либо риски, связанные с сохранением ссылки в памяти на SecureString, в отличие от строки? Похоже, если это не проблема, тогда привязка непосредственно к ней будет частью структуры. – jeremyalan

Причина, по которой свойство PasswordBox для паролей не является DP, объясняется здесь кем-то из Microsoft: http://social.msdn.microsoft.com/forums/en-US/wpf/thread/7ca97b60-2d8e-4a27-8c5b- b8d5d7370a5e /. Я предполагаю, что новое свойство SecurePassword не является DP, потому что они боятся, что он будет привязан в памяти, если кто-то привяжется к нему и забывает его очистить после входа в систему. Но это только догадка. –

Спасибо за ответ. Есть ли способ «очистки» после входа в систему, поэтому я могу гарантировать, что значение не будет сидеть в памяти после исчезновения страницы входа в систему? – jeremyalan

Мне нравится ваша идея.

Да, вы нарушаете ViewModel лучшие практики здесь, но

лучшие практики «рекомендации, которые хорошо работают в большинстве случаев», а не строгих правил и
пишущие простой, легкий для чтения, поддерживаемый код и избежание ненужной сложности также является одним из тех правил «лучшей практики» (которые могут быть слегка нарушены «обходным путем»).

ли ломать барьер View/ViewModel здесь будет проблемой для вас или нет, зависит от почему вы используете ViewModels в первую очередь (например, разделение задач, модульное тестирование, переиспользуемости), поэтому я не могу ответить на это.

источник

2010-08-09 22:30:43 Heinzi

Это только мнение, которое может вам помочь.

Я думаю, что идея not tomake Password как DP легко отслеживается внешним программным обеспечением, таким как SNOOP.
Наименьшая зависимость от модели просмотра у вас есть, тем лучше ваш код. это поможет вам в модульном тестировании и обновлении или изменениях (что бы вы сделали, если в будущем вы захотите использовать поле для пароля третьей стороны?)
Отбросить состояние «Код за бесполезным» используйте его с умом.

Рассмотрим это в коде позади:

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

источник

2010-08-10 04:58:53 ktutnik

Я забыл .. вы должны использовать подход «Вид-Первый» для этого. – ktutnik

мои 2 цента:

зашифровать пароль в модели представления, использовать вложенные свойства, а также использовать ValueConverter для шифрования/расшифровки пароль. с этим, даже если кто-то использует snoop, тогда все, что они видят, - это зашифрованные данные.

дайте нам знать, что лучше всего работает с вашей ситуацией

источник

2010-09-02 03:31:17

Использование PasswordBox с WPF - MVVM

ответ

Смежные вопросы