Оставить пароль в окне управления паролем WPF

Я думаю, что это должен быть быстрый вопрос, и я надеюсь, что это хорошее место, чтобы задать его.

Изменить: возможно, это сделает обсуждение, предложения и ответы немного более острыми: учитывая, что у меня есть ситуация, когда у меня нет другого выбора, кроме как передать пароль в виде простого текста элементу ввода на веб-странице html, что является самым безопасный способ, которым я могу обрабатывать этот пароль, также учитывая, что я использую поле пароля wpf для получения его от пользователя, я использую .SecurePassword для извлечения пароля из поля пароля и использую функцию, описанную ниже, чтобы передать эту безопасную строку в input, а затем сразу же отправить форму на сервер.

Я написал небольшое приложение WPF, которое автоматизирует процесс для нашего офиса. В рамках этого приложения идентификатор пользователя и пароль передаются стороннему поставщику. Это приложение остается открытым на рабочем столе пользователя, поэтому этот процесс можно выполнять несколько раз в течение дня.

Поскольку я написал приложение сейчас, пароль вводится пользователем в поле пароля wpf один раз, и доступ к свойству пароля осуществляется только тогда, когда он нужен сайту поставщика. Я ни в коем случае не передаю пароль другому свойству или текстовой строковой переменной.

Мой вопрос связан с безопасностью этого подхода. Я не эксперт по ИТ-безопасности, и мы, честно говоря, не ожидаем каких-либо проблем с этим из-за его внутренней реализации, но я хотел посмотреть, как поле пароля хранит этот пароль.

Насколько я понимаю, в этом сценарии единственный раз, когда пароль живет в памяти в виде обычного текста, это момент, когда он передается из нашего приложения в приложение внешнего поставщика, что является более или менее неизбежным риском. Внешний поставщик не предоставил нам API, поэтому лучшее, что мы можем сделать, — это сайт поставщика input element.value = passwordbox.password.

Может ли кто-нибудь выделить потенциальные риски этого подхода, возможно, альтернативный метод, если он существует, или аргументы в пользу его безопасности, если они существуют.

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

Заранее спасибо за вашу помощь!

РЕДАКТИРОВАТЬ: Все еще работаю над этим, но я получил хорошие отзывы, которые я принял во внимание. Я адаптировал подход со страницы, опубликованной Mare Infinitus, http://blogs.msdn.com/b/fpintos/archive/2009/06/12/how-to-properly-convert-securestring.-to-string.aspx

Вот что у меня есть сейчас:

Пользователь вводит свой пароль в поле пароля WPF. У меня есть следующая функция:

Private Function ConvertToUnsecureString(ByVal SecurePassword As SecureString) As String

    If SecurePassword Is Nothing Then Throw New ArgumentNullException("SecurePassword")

    Dim unmanagedString As IntPtr = IntPtr.Zero
    Try
        unmanagedString = Marshal.SecureStringToGlobalAllocUnicode(SecurePassword)
        Return Marshal.PtrToStringUni(unmanagedString)
    Catch ex As Exception
    Finally
        Marshal.ZeroFreeGlobalAllocUnicode(unmanagedString)
    End Try

End Function

Используя эту функцию, я передаю пароль элементу ввода следующим образом:

InputEl.value = ConvertToUnsecureString(Me.PasswordBox.SecurePassword)

На данный момент это кажется настолько хорошим, насколько это возможно, но меня все еще интересуют дальнейшие стратегии/идеи, которые могут быть более безопасными.


person MattB    schedule 20.05.2014    source источник
comment
Если вы заботитесь о безопасности, вы спрашиваете пароль, когда он вам нужен. Вы используете PasswordBox и рекомендации по работе с этими паролями. Если вы этого не сделаете, то вас действительно не волнует безопасность, и вы должны перестать беспокоиться о ней или притворяться, что она безопасна. Да, и большинство проблем безопасности являются внутренними для организаций.   -  person    schedule 20.05.2014
comment
Приложение работает внутри вашей демилитаризованной зоны?   -  person Gayot Fow    schedule 20.05.2014
comment
@Will Это... вот почему я использую окно пароля. Я, конечно, могу сбросить пароль и запрашивать его каждый раз, когда это требуется, но, насколько я понимаю, функционально это не будет сильно отличаться от подхода, который я уже использую. Если вы видите, как можно улучшить этот подход, я хотел бы услышать конкретные возражения и рекомендации.   -  person MattB    schedule 20.05.2014
comment
@GayotFow Я полагаю, что он будет работать в демилитаризованной зоне. Используемые учетные данные пользователя используются для доступа к веб-сайту с приложением, созданным внешним поставщиком с использованием SSL, и действительны только для этого сайта, но я не могу гарантировать, что пользователи не используют повторно комбинацию идентификатора пользователя и пароля, которая также используется для более чувствительные системы в нашей внутренней сети. Однако эта часть не в моих руках, я просто хочу внести свой вклад, когда дело доходит до того, чтобы не создавать новых дыр в безопасности.   -  person MattB    schedule 20.05.2014
comment
Все становится очень сложно, если вы хотите сохранить этот пароль.   -  person Mare Infinitus    schedule 20.05.2014
comment
@MareInfinitus Мне действительно не нужно. У меня сложилось впечатление, основанное на всем, что я прочитал, что запрос пользователя на ввод пароля с помощью поля пароля каждый раз, когда загружается приложение внешнего поставщика, будет не менее безопасным, чем подход, который я использую в настоящее время. Я полагаю, что хотел бы знать, как оставить его в поле пароля и получить его, когда это необходимо, менее безопасно, но только ради моего собственного назидания, а не потому, что я пытаюсь спорить об этом. Это было бы удобнее для пользователей, но это тоже небольшая жертва.   -  person MattB    schedule 20.05.2014
comment
Возможно, вам будет полезна следующая ссылка: blogs.msdn.com/b/fpintos/archive/2009/06/12/   -  person Mare Infinitus    schedule 20.05.2014
comment
@MareInfinitus и все на самом деле, основываясь на некоторых других приложениях, которые я вижу внутри, этот подход уже намного более безопасен по сравнению с ним. Я бы предпочел не распространяться об этом дальше и не хочу использовать этот факт в качестве оправдания своей небрежности в своем собственном подходе.   -  person MattB    schedule 20.05.2014
comment
@MareInfinitus На самом деле это очень полезно. Как раз искал что-то подобное, спасибо! Насколько я понимаю, элемент управления полем пароля обрабатывает пароль как безопасную строку. Я все еще прав в этом понимании?   -  person MattB    schedule 20.05.2014
comment
Можете ли вы просто использовать их учетные данные домена?   -  person Gray    schedule 20.05.2014
comment
@Gray К сожалению, нет, другой домен, другие учетные данные пользователя. Это приложение предоставлено сторонним поставщиком.   -  person MattB    schedule 20.05.2014


Ответы (2)


Если вам действительно нужно передать пароль в виде открытого текста, постарайтесь раскрыть его как можно короче.

В этом может помочь следующая ссылка: Правильно преобразовать безопасную строку в строку

Там действительно больше по теме, единственная самая полезная ссылка для меня была:

Как использовать защищенную строку

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

Но также проверьте следующие ссылки:

API ProtectedData, CryptprotectData

Статья Codeproject о шифровании

person Mare Infinitus    schedule 20.05.2014
comment
Конечно, преобразование SecureString в String противоречит цели SecureString.. - person Ryan Emerle; 21.05.2014
comment
@RyanEmerle У вас есть другое предложение? Единственным вариантом передачи пароля поставщику является использование простой текстовой строки, но как бы вы предложили мне минимизировать или устранить риск раскрытия информации при передаче его элементу HTML? - person MattB; 21.05.2014
comment
На мой взгляд, цель SecureString полностью не уничтожена. Определенно есть случаи, когда вам нужен простой текст. Вам остается только позаботиться о том, чтобы он раскрылся за максимально короткое время. Мне пришлось сделать это однажды для входа в систему, когда API требовал паролей в виде простого текста через эфир, как можно было обрабатывать tbat на стороне клиента? - person Mare Infinitus; 21.05.2014
comment
Как только SecureString преобразуется в string, эта новая строка сохраняется в куче до тех пор, пока она не будет собрана сборщиком мусора. Итак, если ваша цель состоит в том, чтобы предотвратить восстановление строки из памяти или дампа памяти, то вы победили цель использования SecureString. - person Ryan Emerle; 21.05.2014
comment
@MattB - то, что вы делаете, по своей сути небезопасно. Если вы беспокоитесь о безопасности, найдите другой способ интеграции со сторонней организацией. Используйте безопасный протокол аутентификации или примите тот факт, что если кто-то достаточно решителен, он сможет восстановить пароль. Если вы не будете осторожны, даже если вы реализуете безопасное решение, оно, скорее всего, не является безопасным, как вы думаете, и все, что у вас есть, — это ложное чувство безопасности. - person Ryan Emerle; 21.05.2014
comment
@RyanEmerle Насколько я понимаю ZeroFreeGlobalAllocUnicode, он обнуляет эту память и удаляет ее из кучи. Я бы согласился, что это экспонируется на долю секунды. Я бы хотел найти лучший способ интеграции со сторонними организациями, но они вне нашего контроля. Из-за характера нашего бизнеса мы ДОЛЖНЫ работать с ними, и это то, что они нам предоставили, у нас нет других вариантов. Тем не менее, я не вижу причин отбрасывать всякую осторожность на ветер, я стараюсь извлечь максимум из нежелательной ситуации, ни больше, ни меньше. - person MattB; 21.05.2014
comment
@MattB Нет, ZeroFreeGlobalAllocUnicode очищает память, выделенную для строки unmanaged. Как только это будет управляемая строка, вы окажетесь во власти сборщика мусора. Вы можете легко проверить это, создав дамп памяти с SecureString, а затем тот, который был скопирован в управляемую строку (даже с ZeroFreeGlobalAllocUnicode). Я благодарю вас за попытку найти безопасное решение. Я просто предостерегаю вас от ложного чувства безопасности. - person Ryan Emerle; 21.05.2014
comment
@RyanEmerle Подойдет, и спасибо за информацию. Я проверю это, чтобы быть уверенным. Мне нравится понимать, как объекты и методы, которые я использую, работают внутри и снаружи, как для написания хорошего кода, так и для того, чтобы я мог компетентно и уверенно отвечать на вопросы заинтересованных сторон. Я согласен, что это не совсем желательно или безопасно, и что всегда будет окно возможности, но я пытаюсь свести его к минимуму, насколько это возможно. Как я уже говорил, мы ДОЛЖНЫ (как в нормативном смысле) работать с этой организацией. Я просто пытаюсь сделать все возможное. - person MattB; 21.05.2014
comment
@RyanEmerle Если у вас есть время, проверьте источник, на который есть ссылка в ответе. Он показывает, как использовать наименьшее время, которое может быть использовано для раскрытия пароля. Если вы можете изменить API, сделайте это. Если нет, извлеките из этого максимум пользы. В моем случае HP не захотела ничего менять, несмотря на то, что я хотел использовать более безопасный способ и описал, как этого можно добиться. Они заставили меня использовать небезопасный способ, поэтому я должен был сделать его как можно менее небезопасным. - person Mare Infinitus; 22.05.2014
comment
@MareInfinitus Вам необходимо понимать время жизни управляемой строки, полученное в результате преобразования из SecureString. Память, выделенная для этой управляемой строки, не очищается после завершения выполнения этого метода. Он останется в куче, пока не запустится сборщик мусора. Даже в этом случае память в куче не будет очищена. Это ложное чувство безопасности, о котором я говорил. - person Ryan Emerle; 22.05.2014
comment
От автора этого блога: в комментариях - person Ryan Emerle; 22.05.2014
comment
Как я писал выше: если у вас есть шанс пойти безопасным путем, сделайте это. Если нет, то какие варианты у вас есть? Ничего не делая? Мне не хватает деловой ценности в этом. - person Mare Infinitus; 22.05.2014
comment
@MattB Пожалуйста, взгляните на обновленный ответ. Добавил единственную самую полезную ссылку (для меня) по этой теме. Я четко излагаю недостатки и способы их устранения. - person Mare Infinitus; 22.05.2014

Давай прямо из документации

PasswordBox.Password Свойство

Когда вы получаете значение свойства Password, вы предоставляете пароль в виде обычного текста в памяти. Чтобы избежать этой потенциальной угрозы безопасности, используйте свойство SecurePassword, чтобы получить пароль в виде SecureString.

PasswordBox.SecurePassword Свойство

person paparazzo    schedule 20.05.2014
comment
Я делаю это сейчас, но чтобы получить пароль в приложении поставщика, мне все еще нужно передать его в виде обычного текста, поэтому он преобразуется с помощью методов, описанных на этой странице: blogs.msdn.com/b/fpintos/archive/ 2009/06/12/ Судя по обстоятельствам, это лучшее, что можно сделать, за возможным исключением запроса пароля каждый раз, когда выполняется задача, для которой предназначено приложение. Я мог бы это сделать, просто я не видел никакого объяснения, почему оставлять его в поле пароля плохо. - person MattB; 20.05.2014
comment
Вы действительно этим сейчас занимаетесь? поэтому лучшее, что мы можем сделать, это элемент ввода на сайте поставщика element.value = passwordbox.password Я не читаю это как SecurePassword. - person paparazzo; 20.05.2014
comment
Извините, я имел в виду сейчас как сейчас, когда я принял во внимание предложения Mare Infinitus выше. Теперь у меня есть подпрограмма, которая преобразует защищенные строки в обычный текст во время их передачи. Я обновлю вопрос выше, так как я не думаю, что это будет один правильный ответ, чтобы предоставить немного больше информации о подходе, который я использую сейчас. - person MattB; 21.05.2014
comment
Итак, вы делаете то, что я предложил, но вы делаете это на основе сообщения от кого-то другого, опубликованного днем ​​​​позже? - person paparazzo; 23.05.2014
comment
Это был комментарий к исходному вопросу, опубликованному Mare Infinitus: Возможно, вам будет полезна следующая ссылка: blogs.msdn.com/b/fpintos/archive/2009/06/12/… — Mare Infinitus 2 дня назад - person MattB; 23.05.2014