Как Microsoft Remote Desktop Manager шифрует пароли?


9

При хранении паролей подключения MS RDP предоставляет возможность хранить пароль в виде открытого текста или шифровать его.

Результирующий узел в файле выглядит так

<logonCredentials inherit="None">
   <userName>USER</userName>
   <domain>DOMAIN</domain>
   <password storeAsClearText="False">AQAdERjHoAwE/Cl+sBAAAA(...)zh</password>
</logonCredentials>

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

Я догадываюсь "не так много", но я не смог найти точно, как генерируется эта зашифрованная цепочка.

Есть идеи? Спасибо!


1
Определите «легко угадать», я думаю, это будет зависеть от машины, это будет самый безопасный способ сделать что-то подобное. Конечно, при наличии достаточного количества времени можно почти полностью перебить силу, все зависит от того, насколько хорош пароль и, конечно, что именно используется. Я сделал поиск в Google .... ** Похоже, что общий совет - зашифровать сам файл конфигурации. ** Я предлагаю вам это сделать.
Ramhound

Какой смысл защищать пароль, если ваши пользователи все равно могут подключиться?
Шадок

@ Ramhound Я хотел бы, чтобы вы отправили свой комментарий в качестве ответа, я бы проголосовал.
Лук

Ответы:


7

Я не знаю, как это делает RemoteDesktopManager, но я предполагаю, что он будет таким же, как он хранит его в файле .RDP .

CryptProtectData, который (с настройками, которые они использовали для RDP) разрешает только расшифровку строки на том же компьютере, что и тот, который ее зашифровал, потому что он использует уникальный идентификатор установки Windows как часть процессов шифрования ( флаг CRYPTPROTECT_LOCAL_MACHINE). Так что да, злоумышленник может расшифровать ваш пароль, но он может сделать это только на машине, на которой хранится пароль, он не может выполнить «автономную» атаку.


Обратите внимание, что это все для .RDPфайлов. У меня нет возможности узнать, выполняет ли Remote Desktop Manager то же самое.


1
после небольшой игры с файлом кажется, что шифрование зависит от компьютера. Вы, наверное, правы (и это также означает, что файл не может быть передан, если пароли не в открытом виде)
Лук,

1

Фактически, RDP от RDPMan отличает только способ хранения хеша: первый сохраняет его в шестнадцатеричном формате, а второй выполняет кодирование Base64. Поэтому после декодирования Base64 с помощью утилиты RDP Password Hasher получите оригинальный пароль. Но это может провернуть только работая от имени пользователя, который создал пароль.


-2

MS RDP подвержен атакам «человек посередине», а также от червей. Поэтому шифрование транспортного уровня может быть добавлено, чтобы смягчить это.

Вот список всего коммерческого программного обеспечения RDP. Хотя шифрование показано как частное и не указано явно.

Читайте здесь для дальнейшего объяснения http://blogs.msdn.com/b/rds/archive/2008/07/21/configuring-terminal-servers-for-server-authentication-to-prevent-man-in-the-middle -attacks.aspx

Прочтите здесь, чтобы узнать об обновлениях безопасности для MS-серверов, которые применяются для шифрования на транспортном уровне и уровне приложений, а также шифрования и аутентификации RDP. http://technet.microsoft.com/en-us/library/dd582586.aspx

и дополнительная информация: http://social.technet.microsoft.com/forums/en-US/winserverTS/thread/8b9a13a4-6d0a-496d-b331-b1fbe9ebcb28/ Обратите внимание, что сценарии .ica для инициализации Citrix RDP включают запись для удаления файл сценария .ica, который содержит хост-домен при входе в систему. Это дополнительная функция безопасности. "RemoveICAFile = да"

Файлы сценариев .rdp по формату похожи на сценарии ica, но могут исключать эту строку. Возможно "RemoveRDPile = yes" может работать ??

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


Это не совсем правда. Любое неправильно защищенное соединение может стать жертвой атаки MITM.
Бурги

Этот недавний отчет опровергает ваше мнение и поддерживает мое мнение с 2012 года plugins.openvas.org/nasl.php?oid=902658 Пожалуйста, исправьте его.
Тони Стюарт Sunnyskyguy EE75
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.