remote password что это
Протокол безопасного удаленного пароля
Как и все протоколы PAKE, перехватчик или человек посередине не могут получить достаточно информации, чтобы иметь возможность угадать пароль грубой силой или применить атаку по словарю без дальнейшего взаимодействия со сторонами для каждого предположения. Кроме того, будучи расширенным протоколом PAKE, сервер не хранит данные, эквивалентные паролю. [2] Это означает, что злоумышленник, который крадет данные сервера, не может маскироваться под клиента, если сначала он не выполнит поиск пароля методом грубой силы.
С точки зрения непрофессионала, во время аутентификации SRP (или любого другого протокола PAKE) одна сторона («клиент» или «пользователь») демонстрирует другой стороне («серверу»), что они знают пароль, без отправки самого пароля или каких-либо другая информация, из которой можно получить пароль. Пароль никогда не покидает клиента и неизвестен серверу.
Кроме того, серверу также необходимо знать пароль (но не сам пароль), чтобы установить безопасное соединение. Это означает, что сервер также аутентифицируется для клиента, что предотвращает фишинг, не полагаясь на то, что пользователь анализирует сложные URL-адреса.
СОДЕРЖАНИЕ
Обзор [ править ]
Протокол [ править ]
В этом описании протокола версии 6 используются следующие обозначения:
Все остальные переменные определяются в их терминах.
Затем, чтобы выполнить подтверждение пароля позже, используется следующий протокол обмена:
Для успешного олицетворения этого метода требуется угадать больше общего состояния, чем просто ключ. Хотя большая часть дополнительного состояния является общедоступным, во входные данные хэш-функции можно безопасно добавлять личную информацию, например закрытый ключ сервера. [ требуется разъяснение ]
В качестве альтернативы, при проверке только паролем вычисление K можно пропустить, а общий S проверить с помощью:
При использовании SRP для согласования общего ключа K, который будет использоваться сразу после согласования, этапы проверки M 1 и M 2 могут быть пропущены. Сервер отклонит самый первый запрос от клиента, который он не может расшифровать. Пропуск этапов проверки может быть опасным. [ необходима цитата ]
Обе стороны также используют следующие гарантии:
Как и все протоколы PAKE, перехватчик или человек посередине не могут получить достаточно информации, чтобы иметь возможность угадать пароль грубой силой или применить атаку по словарю без дальнейшего взаимодействия со сторонами для каждого предположения. Кроме того, будучи расширенным протоколом PAKE, сервер не хранит данные, эквивалентные паролю. Это означает, что злоумышленник, который крадет данные сервера, не может маскироваться под клиента, если сначала не выполнит поиск пароля методом грубой силы.
С точки зрения непрофессионала, во время аутентификации SRP (или любого другого протокола PAKE) одна сторона («клиент» или «пользователь») демонстрирует другой стороне («серверу»), что они знают пароль, без отправки самого пароля или каких-либо другая информация, из которой можно получить пароль. Пароль никогда не покидает клиента и неизвестен серверу.
Кроме того, серверу также необходимо знать пароль (но не сам пароль), чтобы установить безопасное соединение. Это означает, что сервер также аутентифицируется для клиента, что предотвращает фишинг, не полагаясь на то, что пользователь анализирует сложные URL-адреса.
Новые альтернативные алгоритмы включают AuCPace и OPAQUE.
СОДЕРЖАНИЕ
Обзор
Протокол
В этом описании протокола версии 6 используются следующие обозначения:
Все остальные переменные определяются в их терминах.
Затем, чтобы выполнить подтверждение пароля позже, используется следующий протокол обмена:
Для успешного олицетворения этого метода требуется угадать больше общего состояния, чем просто ключ. Хотя большая часть дополнительного состояния является общедоступным, во входные данные хэш-функции можно безопасно добавлять личную информацию, например закрытый ключ сервера.
В качестве альтернативы, при проверке только паролем вычисление K можно пропустить, а общий S проверить с помощью:
При использовании SRP для согласования общего ключа K, который будет использоваться сразу после согласования, этапы проверки M 1 и M 2 могут быть пропущены. Сервер отклонит самый первый запрос от клиента, который он не может расшифровать. Пропуск этапов проверки может быть опасным.
Обе стороны также используют следующие гарантии:
SRP-6: аутентификация без передачи пароля
Как и было обещано в соседней теме, где рассказывался велосипед, выкладываю описание алгоритма SRP RFC2945 — способе регистрации и аутентификации пользователей безопасным образом по небезопасному каналу. Вот только в процессе подготовки статьи я обнаружил более свежую версию протокола, SRP-6, вместе с реализацией, в связи с чем решил выбросить свои архаичные наработки по SRP-3, и просто дать ссылки на имплементацию новой версии.
Secure Remote Password (SRP) протокол описывает установление безопасного соединения, используя для аутентификации пару логина и пароля, при которой пароль используется только на этапе регистрации и аутентификации и только на стороне клиента. Благодаря использованию схемы близкой к Диффи-Хеллману, SRP обеспечивает безопасную аутентификацию пользователя по паролю без необходимости передачи этого пароля, и даже имея полную запись обмена по каналу мы не получаем информации достаточной, для аутентификации данным пользователем. Так же, если сервер будет скомпрометирован и утечёт «в народ» вся база логинов со стороны сервера, злоумышленник не сможет аутентифицироваться ни одним из пользователей.x
Для реализации входа, можно использовать классическую форму логин+пароль, на onSubmit которой повешен аутентификатор.
В случае отсутствия на стороне клиента яваскрипта, форма отправится «как есть», что передаст по небезопасному каналу пароль, но позволит аутентифицироваться даже с «тупых» клиентов (путем симуляции всех действий «пользователя» на сервере).
В случае присутствия JS, аутентификация реализуется путем отправки двух спец-форм используя AJAX методики, производя вычисления между ними.
Впрочем, если сайт не требуется чтобы работал без JS (например, fallback вообще не возможен, слишком сложен, «не тянем» по времени и силам разработчиков), то мне кажется более разумным реализация такой схемы: поля вообще не находятся в форме, после выхода из поля логина поле пароля блокируется на некоторое время, и рисуется рядом ajax спиннер. После получения с сервера соли для юзернейма, поле пароля разблокируется и можно ввести туда пароль.
Смысл в разделении необходим для того, чтобы дать JS время на вычисления. Всё-таки там довольно много математики с большими числами. Когда я исследовал этот вопрос на SRP-3 используя SHA1 (лет пять эдак назад), использовать 512битные ключи оказалось слишком медленным — до 30 секунд на вычисления для подтверждения пароля. При этом весь UI браузера [особенно IE6 ;)] блокируется на всё время вычисления. Решением может быть вычисления используя континуации (запуск вычисления кусочками через setTimeout(), сохраняя контекст между вызовами) или вынося вычисления во flash / java. Причем java предпочтительнее с точки зрения скорости вычисления, а flash — с точки зрения вероятности доступности у пользователя.
Важный момент — сервер может отвечать солью на любой заданный ему username, чтобы не давать информации о существовании указанного пользователя у него в базе, но тогда соль для несуществующих пользователей должна вычислять по какому-либо алгоритму, на базе username, причем данный алгоритм должен быть сохранен в тайне, или быть неповторяемым без каких-либо секретных сведений на стороне сервера. Проще говоря, необходимо чтобы соль, базирующуюся на username было невозможно отличить от полностью рандомной соли реальных пользователей.
Еще очень важно понимать, что алгоритм никак не защищает от фишинга. Поддельный сайт вполне может выдать идентично выглядящую страницу, на которой будут так же расположенные поля логина и пароля, вплоть до симуляции вычислений вычисляя, например, сумму ряда чисел от 1 до 1e12 через однострочник, на самом деле передавая на сервер злоумышленника пароль «как есть». Именно поэтому мне кажется использование подписанного Java аутентификатора более привлекательным — при подделке надо будет симулировать еще и подпись на ява-апплете авторизаторе… Что, в общем-то, используя человеческую лень и невнимательность по-прежнему возможно.
Способы смены пароля учётной записи пользователя в RDP-сессии
При использовании удалённого подключения к операционным системам Microsoft Windows/Windows Server по протоколу RDP в некоторых случаях может возникать потребность в смене пароля учётной записи пользователя. При этом инициатором смены пароля в разных ситуациях может выступать как сам пользователь, так и администратор Windows-системы. В некоторых сценариях может получиться так, что, казалось бы, несложная задача смены пароля может стать не такой уж и простой. Поэтому в данной записи я попробую собрать информацию о самых разнообразных способах смены пароля учётной записи пользователя в RDP-сессии.
В случае, если пользователю Windows необходимо самостоятельно изменить пароль своей учётной записи, то в стандартной Windows-сессии пользователем может использоваться всем известное сочетание «горячих» клавиш Ctrl-Alt-Del. Это сочетание клавиш вызывает специальный экран Безопасности Windows (Windows Security), с которого доступна функция изменения пароля :
Если же речь заходит об использовании горячих клавиш в RDP-сессиях, то стоит заметить то, что во избежание перехвата некоторых сочетаний клавиш локальной клиентской системой (системой, с которой запускается RDP-клиент), перенаправление сочетаний клавиш Windows должно быть явно разрешено в свойствах RDP-клиента. Например в клиенте mstsc.exe, встроенном в Windows, данную опцию можно включить на закладке управления локальными ресурсам.
В стандартной первичной RDP-сессии для вызова специального экрана Безопасности Windows с функцией изменения пароля используется сочетание клавиш: Ctrl—Alt—End
В случае использования вложенных RDP-сессий (второго и последующего уровней), то есть когда из одной RDP-сессии открывается другая RDP-сессия, стандартное сочетание клавиш работать не будет. В разных источниках в интернете можно найти информацию об использовании более сложных сочетаний клавиш, таких как Ctrl—Alt—Shift-End или Shift-Ctrl-Alt-End. Однако мои эксперименты с Windows 10/Windows Server 2012 R2 показали, что данные сочетания клавиш попросту не работают (возможно они работали в ранних версиях ОС Windows). В этом случае на выручку нам может прийти следующий способ.
В составе Windows имеется приложение «Экранная клавиатура» (On-Screen Keyboard), расположенное по умолчанию в %SystemRoot%\System32\osk.exe. Используя это приложение, мы можем решить проблему использования «горячих» клавиш во вложенных RDP-сессиях.
Находясь во вложенной RDP-сессии, вызовем окно запуска приложений. Вызвать его можно разными способами, например, через контекстное меню по кнопке Windows, или через Диспетчер задач (Task Manager):
Либо можно использовать сочетание клавиш Win-R.
В окне запуска приложений выполним запуск исполняемого файла osk.exe
После того, как откроется приложение «Экранная клавиатура», нажмём на физической клавиатуре сочетание клавиш Ctrl—Alt, так, чтобы это отобразилось на экранной клавиатуре и затем, удерживая это сочетание клавиш, на экранной клавиатуре мышкой нажмём кнопку Del.
Таким образом мы отправим в удалённую RDP-сессию сочетание клавиш Ctrl-Alt-Del, в следствие чего откроется специальный экран Безопасности Windows с функцией изменений пароля пользователя.
Способ №3 – Ярлык на VBS-скрипт или Powershell
Вызов экрана Безопасности Windows можно выполнить не только интерактивными способами, но и программными, например, с помощью скриптов.
Разместим скрипт в месте, доступном на чтение (но не для редактирования) для всех пользователей удалённого рабочего стола, например в каталоге %SystemRoot% ( C:\Windows ). А ярлык на запуск скрипта можно разместить в любом доступном пользователям месте, например, в каталоге общего профиля %SystemDrive%\Users\Public\Desktop\
При запуске данного ярлыка у пользователя будет открываться экран Безопасности Windows с возможностью изменения пароля.
Для любителей PowerShell приведённый VBS-скрипт можно заменить PS-скриптом следующего вида:
Либо запускать из ярлыка команду вида:
Однако стоит отметить тот факт, что запуск варианта с PowerShell будет происходить медленней, чем варианта с VBS-скриптом.
Описанные здесь способы с запуском ярлыка, ссылающегося на скрипт, может попросту не сработать, так как в некоторых окружениях серверов служб удалённых рабочих столов может быть заблокирована возможность выполнения скриптов. В таком случае, можно воспользоваться следующим способом.
Способ №4 – Ярлык оболочки Windows Explorer
Если говорить о создании ярлыка запуска экрана Безопасности Windows, то имеется ещё один вариант создания такого ярлыка. Создаётся ярлык со ссылкой на расширение оболочки Windows Explorer следующего вида:
Опять же, при запуске такого ярлыка у пользователя будет открываться экран Безопасности Windows с возможностью изменения пароля. Этот способ одинаково хорошо работает на Windows 10 и на Windows Server 2012 R2.
Способ №5 – Панель управления Windows (локальные учётные записи)
Данный способ относится лишь к локальным учётным записям пользователей. Изменить пароль учётной записи рядового локального пользователя можно через Панель управления Windows. В Windows 10 из раздела Панели управления «Учётные записи пользователей» доступен вызов окна «Параметры компьютера«, в котором имеется функция изменения пароля текущего локального пользователя.
Такие методы вызова апплета управления учётными записями пользователей Панели управления Windows, как, например команда «control userpasswords2«, в качестве отдельного способа мы выделять не будем, так как подобные действия требуют административных прав в удалённой системе. То же самое касается и таких CLI-утилит Windows, как net.exe ( %SystemRoot%\System32\net.exe ) (пример команды «net user username newpassword«), так как они тоже требуют повышения уровня прав пользователя.
Ремарка
Отдельно хочется отметить обстоятельство, про которое порой забывают администраторы, и это может приводить к разным курьёзным ситуациям.
Попытки смены пароля, инициированные самим пользователем, могут оказаться безуспешными в случае, если пароль был недавно изменён и на удалённую Windows систему действует политика безопасности, определяющая минимальный срок действия пароля.
Повторюсь, что повлиять на ситуацию эта политика может только в случаях, когда пользователь самостоятельно инициирует процедуру смены пароля.
Далее мы поговорим о сценарии, при котором требование смены пароля включается для учётной записи пользователя форсировано администратором сервера (для локальных учётных записей), либо администратором службы каталогов Active Directory (для доменных учётных записей).
Практика показывает, что как только администратором включено требование смены пароля пользователя при следующем входе в систему, у пользователя могут возникнуть проблемы с подключением по протоколу RDP, если на стороне RDS сервера (а в некоторых случаях и на стороне RDS клиента) предварительно не предпринято никаких действий по специальной настройке обработки таких ситуаций. Далее мы рассмотрим пару примеров такой настройки.
Клиентский доступ к службам Windows Server RDS может быть организован через веб-интерфейс серверной роли Remote Desktop Web Access (RDWA). В функционале этой роли имеется выключенная по умолчанию возможность смены пароля пользователя в процессе аутентификации на веб-странице RDWA.
Чтобы включить данную возможность в Windows Server 2012/2012 R2 откроем консоль управления Internet Information Services (IIS) Manager, выберем сайт RDWA, развернём RDWeb > Pages и в разделе настроек ASP.NET выберем настройку опций веб-приложения Application Settings:
В перечне опций находим PasswordChangeEnabled и меняем установленное по умолчанию значение false на true:
Если серверов RDWA несколько и они работают в пуле за балансировщиком, например Windows NLB, то не забываем выполнить данное изменение на всех других серверах пула.
Теперь попытаемся от имени пользователя, у которого в свойствах учётной записи установлено требование смены пароля при следующем входе, аутентифицироваться на веб-странице RDWA:
После ввода учётных данных пользователя появится сообщение о том, что пароль пользователя требует замены и ссылка на страницу с функцией смены пароля ( https:// /RDWeb/Pages/ru-RU/password.aspx ):
На этой отдельной странице пользователь сможет ввести свои текущие учётные данные и новый пароль:
В случае успешной смены пароля пользователь получит соответствующее сообщение: 
При необходимости ссылку на страницу смены пароля можно сделать доступной не только тем пользователям, у которых после аутентификации возникает требование смены пароля, но и всем остальным пользователям, чтобы они могли самостоятельно выполнять смену пароля по собственной инициативе через веб-страницу RDWA. Для этого можно будет внедрить ссылку на страницу password.aspx на странице входа login.aspx (по умолчанию страницы расположены в каталоге %windir%\Web\RDWeb\Pages\ru-RU )
Способ №7 – Специальный RDP-файл
Если пользователь выполняет подключение к удалённому рабочему столу на базе Windows Server 2012/2012 R2 через прямой запуск стандартного клиента mstsc.exe, то в ситуации с включенным признаком требования смены пароля, попытка подключения может быть завершена с ошибкой » You must change your password before logging on the first time. Please update your password or contact your system administrator or technical support «.
Если ситуация требует того, чтобы пользователь самостоятельно изменил свой пароль при первом входе в систему, то это потребует некоторого изменения уровня безопасности настроек протокола RDP на стороне RDS сервера и подготовки специального RDP-файла на стороне клиента.
Сначала на клиентской стороне откроем mstsc.exe, настроим все нужные параметры подключения к серверу RDS и используя кнопку Сохранить как, создадим RDP-файл.
После этого откроем RDP-файл в текстовом редакторе и добавим в конец файла строку «enablecredsspsupport:i:0«
Разрешить эту ситуацию можно только понизив уровень безопасности RDP на стороне RDS сервера, отключив обязательное требование проверки подлинности на уровне сети (NLA). Изменить эту настройку можно в свойствах системы на закладке Удалённый доступ:
В английской версии Windows название опции звучит как «Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)»
Если NLA нужно отключить на уровне коллекции серверов Windows Server 2012 R2, то сделать этом можно в свойствах коллекции сеансов, например через оснастку Server Manager:
После того, как отключено требование NLA на стороне RDS сервера, клиент с помощью специального RDP-файла, о котором мы сказали выше, должен успешно установить RDP-сессию и уже в ней получить сообщение о необходимости смены пароля:
И после этого пользователю будет показан экран, на котором он сможет задать новый пароль:
После успешной смены пароля последующие подключения по протоколу RDP будут проходить в штатном режиме без лишних запросов.
Заключение
Приведённый здесь перечень способов смены пароля при использовании протокола RDP не претендует на какую-то полноту и исключительность, а лишь отражает ту информацию, которую мне удалось найти в разных источниках по этому поводу. На мой взгляд, ни один из перечисленных способов нельзя считать наиболее удобным или универсальным, так как каждый из способов может применяться в определённых ограниченных сценариях и имеет, как преимущества, так и недостатки по сравнению с другими способами.
Дополнительные источники информации:
mRemoteNG снова торт
Если вы администратор нескольких десятков Windows и Linux серверов, пачки коммутаторов и маршрутизаторов, то без менеджера удаленных подключений можно быстро и надёжно сойти с ума.
TL;DR. mRemote, разработка которой была давным-давно заброшена, обрела новую жизнь. Если вы пользуетесь RDCMan или Remote Desktop free от Devolutions — попробуйте mRemoteNG!
mRemote — в прошлом очень популярный менеджер удаленных подключений. К сожалению, его разработка была заброшена примерно в 2009 году. Недоработки в интерфейсе, глюки с новыми версиями RDP заставили меня отказаться от него.
Какое-то время хватало Remote Desktop Connection Manager (aka RDCman) от Microsoft.
Коммутаторы и Linux-серверы жили в отдельной консоли SuperPutty. Я был не в восторге ни от первой, ни от второй утилиты. Особенно плохо спалось из-за сохраненных паролей, которые шифровались по принципу Security through obscurity. Fail!
Потом перешел на VisionApp vRD.
Коммерческий, получилось раздобыть NFR лицензию. Неплохой, но глючненький менеджер. И не очень функциональный. Его сильная сторона — хранение подключений в SQL Server, это нужно для того, чтобы у всей вашей команды была общая база подключений. Сейчас продукт называется ASG Remote Desktop.
Двойственные впечатления от vRD заставили подумать об альтернативе. Долго искать не пришлось, в 2014 году на рынке уже доминировал Remote Desktop Manager от канадских ребят из Devolutions.
Великолепный продукт, который очень интенсивно разрабатывается. В нем, кажется, есть все что только можно пожелать. Автозаполнение форм на web-консолях. Свой модуль PowerShell. Шикарная (по-другому не скажешь) интеграция с KeePass — пожалуйста.
А самое главное — быстрый поиск сервера. По имени, описанию, по тегу. Это повысило удобство администрирования на порядок.
Мы купили на работу несколько лицензий. Проблема, как всегда, была одна — цена. 200$ за лицензию — гуманно для Enterprise и не очень для личного использования.
Есть бесплатная версия этого продукта. Внутри все тот же флагманский RDM, но функционал довольно скромен. Отсутствие наследования паролей и любовь к жору памяти заставили осмотреться и снова поискать альтернативу для личного использования.
И она нашлась. Оказалось, что старый добрый mRemote доведен до более чем работоспособного состояния.
Open Source проект под лицензией GPLv2. Судя по странице на GitHub у него как минимум 2 активных разработчика и несколько десятков комитеров. И они действительно правят баги и добавляют новые функции.
Программа отлично работает в Windows 10. За SSH отвечает мод Putty, а не сторонний компонент как в RDM (сторонние на практике обычно «глючат/виснут/тормозят»).
Коротко пробежимся по функциям.
Подключения: RDP, SSH, ICA,VNC, Telnet, HTTP/HTTPS.
Наследование: любые свойства подключения, включая пароли. Иерархическое наследование.
Хранение подключений: в файле, в SQL Server.
Шифрование: полное шифрование файла подключений, выбор из трех алгоритмов, шифрование паролей в SQL Server.
Импорт соединений: из встроенного сканера портов, Active Directory, RDCMan.
Есть поиск по соединениям, но к сожалению с RDM не идет ни в какое сравнение.
Да, проекту далеко до лучших коммерческих образцов, но он полностью рабочий, развивающийся и имеет относительно живой форум на Reddit и багтрекер.
Резюмирую. Мне кажется, что mRemoteNG на сегодня лучшая альтернатива коммерческим менеджерам подключений. 7zip потеснил WinZIP и WinRAR. qBittorent отвоевывает место mTorrent.
Хорошие вещи надо поддерживать. Тем более Open Source.