Что такое восстановление пароля
Как восстановить доступ к устройству или аккаунту, если потерял пароль
Введение следует отметить, что рекомендации, приведенные в следующем материале, служат не для отслеживания и перехвата паролей. Мы хотим только подсказать, как восстановить доступ к своей информации, хранящейся на зашифрованном устройстве или аккаунте интернет-сервиса, если вдруг забудете пароль.
Как оказывается, это не так уж и маловероятно. Не один пользователь испытывал проблемы с входом в систему Windows после возвращения из двухнедельного отпуска. Не говоря о распаковке зашифрованных много лет назад архивов ZIP или входе на аккаунт, которым не пользовался много лет.
Неудивительно, что пользователи, которые не используют один и тот же пароль для всех случаев (вполне благоразумно), время от времени вынуждены восстанавливать или сбрасывать пароли.
Пароль – степень защиты, риск взлома и щепотка теории
Безопасность, которую обеспечивают надежные пароли, и связанный с ними риск взлома – это невероятно сложные вопросы. Теория теорией, а большой технический прогресс в последние годы очень существенно повлиял на вероятность захвата конфиденциальных данных, учетных записей в интернет-магазинах или цифровых идентификационных данных пользователей. Длинный и сложный пароль обеспечивает только поверхностную безопасность – в следующей части материала мы расскажем о том, почему.
С одной стороны, вычислительная мощность относительно небольшого компьютерного кластера (группы взаимосвязанных компьютеров для получения высокой производительности), который располагает лишь двумя дюжинами видеокарт, настолько велика, что он может в течение нескольких часов «взломать» пароль, состоящий из восьми символов, через обычный перебор всех возможных комбинаций символов.
Конечно, можно представить контраргумент, что увеличение длины пароля приведёт к росту времени, необходимого для подбора пароля. Хотя это правильное предположение, оно работает только в теории. Злоумышленники некоторое время назад перешли на другие методы взлома паролей. Даже базы ярлыков, известные как массивы символьных вычислений, которые собирают значения хеширования для сокращения времени определения пароля, уходят медленно в прошлое.
Пароль – список кодов доступа
Прежде всего, из-за многочисленных случаев массового взлома аккаунтов в сервисах интернета, которые имели место в последние годы, в настоящее время в открытом доступе имеется огромное количество широко используемых паролей. В результате этих вторжений были украдены данные миллионов клиентов. Некоторые коды доступа хранились в явном виде и были опубликованы в интернете, другие стали предметом финансовых сделок.
Располагая такой базой паролей, достаточно соединить её с многоязычными словарями, чтобы проводить эффективные атаки. Обработку нескольких миллионов слов можно осуществить гораздо быстрее, чем последовательный перебор биллиарда возможных комбинаций символов.
Однако, на этом не конец, потому что список паролей, похищенных злоумышленниками, даёт информацию об используемых шаблонах для создания пароля. Хотя простые решения, такие как password, 1234. или имена детей больше не используются так часто, как раньше, но включение обычных слов и использование шаблонов по-прежнему на повестке дня.
Большой популярностью пользуется, например, метод замены букв по образцу, используемого в сленге Leet speak. Так, например, слово kalkulator превращается в немного более сложное k4lkul470r. Некоторые пользователи дополняют созданные таким образом пароли названием портала или сервиса. Однако, такие пароли не обеспечивают должного уровня безопасности, потому что давно фигурируют в файлах словарей, циркулирующих в интернете.
С другой стороны есть много аппаратных решений, для которых безопасность оставляет желать лучшего. Например, более ранние версии Android блокируют экран только после пяти неудачных попыток ввода кода. Повторить ввод можно уже по истечении 30 секунд. Если автоматизировать этот процесс, то угадывание четырехзначной последовательности цифр займет не больше 17 часов.
По цене 35 евро можно приобрести специальное устройство – USB Rubber Ducky, которое выполнит это задание. Защита исправлена только в последней версии Android (Зефир). Гораздо безопаснее в этом вопросе оказывается iOS и Windows Phone.
Пароль к учетным записям в сервисах онлайн
Выше мы представили некоторое «закулисье» паролей и методов атак на системы безопасности. Методы создания и запоминания надежных паролей мы описывали в отдельной статье. Остается вопрос сброса паролей. Эта операция часто необходима в случае учетных записей в социальных сетях.
В принципе, любой сервис, такой как интернет-магазин, портал, социальная сеть или тематический форум, предоставляет возможность восстановления доступа к учетной записи по адресу электронной почты. Система автоматически отправляет сообщение владельцу счета, которое содержит специальную ссылку. Нажав её, пользователь может задать новый пароль доступа к сервису.
Это показывает, какое огромное значение имеет защита почтового ящика. Если злоумышленнику удастся получить пароль для электронной почты своей жертвы, он сможет использовать функцию сброса пароля, чтобы добраться до всех сайтов, зарегистрированных с данного адреса электронной почты. Поэтому необходимо в определенной степени заботиться о безопасности почтового ящика.
Кроме функции сброса паролей, существует ещё несколько решений для забывчивых. К ним относятся, в частности, генерация кода с помощью приложения или получение пароля в СМС-сообщении. Google и другие крупные порталы позволяют даже использовать такие методы защиты, как двухэтапная аутентификация. Также существует система сброса паролей через правильный ответ на «секретный» вопрос. На такая защита мало чего стоит, так как злоумышленники могут получить ответ путём социальной инженерии (social engineering).
Доступ к компьютеру Windows
Не впадайте в панику, если вдруг забудете пароль к учетной записи в Windows. Получить доступ к системе можно без использования инструментов для взлома паролей. Вся операция несколько рискованная, но занимает всего от несколько десятков минут. Работает даже в Windows 10.
Восстановление доступа к Windows без установочного диска
Когда появится экран входа в систему, выключите компьютер, нажав выключатель на задней панели корпуса или вытащив вилку из розетки.
Внимание! Редакция не несет ответственности за возможные повреждения компьютера. Хотя такое случается редко.
Нажмите на ссылку X:/windows/system32/ru-RU/erofflps.txt, чтобы открыть текстовый редактор. В окне редактора выберите меню Файл → Открыть и перейти в каталог /windows/system32 на системном разделе C:
Пароль – доступ для мобильных устройств
Когда вы потеряете доступ к учетной записи в мобильном устройстве, совсем не обязательно его сбрасывать, теряя все данные. Имея доступ к учетной записи Google, вы можете воспользоваться приложением для разблокировки экрана блокировки – так, как это возможно в случае других приложений.
Бесплатное приложение для смартфонов с Android это [Free] Screen Lock. Кроме того, доступно коммерческое приложение Screen Lock Pro. Оба приложения очень просты в использовании. Чуть больше усилий требуется для удаления блокировки посредством Android Debug Bridge.
Пользователи заблокированного iPhone имеют в своём распоряжении только методы, предложенные производителем. Кроме них, не существует никаких трюков, которые помогли бы снять блокировку экрана. Но, по крайней мере, Вы можете восстановить устройство из ранее созданной резервной копии на iTunes, так что вам не придется настраивать всё заново, как это имеет место при использовании безопасного режима.
Заметки о безопасности. Восстановление пароля
Хотелось бы немного рассказать о подходе повествования в данном посте. Всё описанное имеет реальные случаи произошедшие из моей личной практики, в большинстве своём это популярные проекты, поэтому в тексте буду их упоминать. Главное на что я хотел бы обратить внимание — эта статья может показаться не интересной специалистам ИБ, т.к. она не содержит никаких новых векторов атаки и супер крутых подходов. Вся информация ориентирована на разработчиков и проект-менеджеров.
Проводя заказы на аудит целью ставится аналитика максимального ущерба при минимальных действиях и знаниях злоумышленника. Как показывает практика в суровых условиях производства ПО такие нюансы продумывают единицы проектов.
И так, рассмотрим слабые места каждого из пунктов выше.
Контрольный вопрос — ответ
Одним из серьёзных упущений данного подхода чаще всего является отсутствие возможности задавать свой вопрос, а так же после ввода правильного ответа выдача формы с вводом нового пароля.
По оперативной информации было выяснено, что данная атака проводилась на компанию WesternUnion и дала повод серьёзно задуматься о безопасности данной функции, а так же временно ограничить её. Проведя аналитику сервиса было установлено, что на выбор для пользователя давалось 3 варианта вопросов: имя домашнего питомца, родной город и девичья фамилия матери. Ответы на эти вопросы получить для десятков пользователей по средством социальной инженерии не составило труда. На помощь пришли социальные сети facebook, twitter, lj и другие.
Помимо социальной инженерии была и более техническая возможность, варианты с ответом на родной город и имя питомца возможно было подобрать по небольшим словарям. Данную атаку можно было предотвратить дополнительным полем каптчи, что в последствии и было сделано. Таким образом из-за обычной недоработки функционала восстановления паролей злоумышленники смогли получить доступ к функции переводов WU с повышенными лимитами от профилей скомпрометированных пользователей. База по которой отрабатывали пользователей (логины и емайлы) была получена из другого источника, через более банальную уязвимость sql-injection, так же был размещён вредоносный код на главной странице взломанного сайта.
Уникальная ссылка на email
Отсылка нового/действующего пароля на email
BONUS: В одной популярной онлайн игре Stronghold Kingdoms была одна единственная sql-injection в формах восстановления пароля/регистрации на поле логин(он же email) был ajax-запрос с проверкой существования данной записи в базе. Подобная проверка так же встречается очень часто на разных сайтах и хотелось бы описать возможности её эксплуатации даже если там нет sqli. Обычно это получение части базы пользователей: берут большие базы email адресов и прогоняют на существования их на сайте. А потом используют найденные для подбора логина/пароля. Это Вам может показаться очень странным и маловероятным, но если на кону стоят деньги или энтузиазм (а может оба), то нет ничего невероятного. Так же стоит отметить, что при восстановлении пароля бывает, когда просит ввести логин пользователя, а потом выдаёт сообщение на какой email был выслан пароль, что тоже может служить поводом для получения доступа к данной почте. Обязательно скрывайте звёздочками часть email.
SMS OTP (One-time password)
Поскольку предыдущий пункт был очень скучный и разжеванный К.О., то предлагаю последним пунктом взять более интересную и не менее распространённую задачку с временными смс-кодами, тем более, что этот смс-код можно не только обойти, но и заставить владельца сайта раскошелиться.
Одним из заказов на аудит была Украинская компания, название её остаётся в секрет в связи с NDA. Это финансовый сервис, который был фанатично привязан к SMS OTP, чуть ли не на каждое действие. Меня это изрядно раздражало при тестировании, т.к. приходилось сидеть в обнимку с мобильным и вводить эти коды каждый раз. Но как оказалось потом, после авторизации можно было в профиле сменить смс-пароль, на обычный пароль. И тут мне это показалось отличным шансом взять за основу SMS OTP для получения доступа к учётным записям пользователей. Код приходящий по sms представлял из себя всегда 6 цифр и тут нельзя не упомянуть про md5(1234) который мы рассматривали выше. Да, логика у меня была той же. Первым делом я проверил кол-во попыток на ввод код и они оказались неограниченными, после было дело времени, написание рабочего прототипа для подбора SMS OTP и отправки запроса на установку в профиле своего пароля 12345.
Таким образом удалось получить доступ к тестовому пользователю и осуществить от него вывод денежных средств с баланса.
На этом я не остановился, во время тестирования я отослал себе уйму смсок на телефон и решил посчитать затраты:
1 смс = 0.30 коп * реальная стоимость смсок для этого клиента
Скрипт выполняющийся в 10 потоков шлёт минимум 1 запрос в секунду, то есть 10 запросов в секунду.
Итого за 24 часа работы скрипта мы можем отослать 10 * 60 * 60 * 24 = 864 000 смс, что обойдётся клиенту в 259 200 Российских рублей (>$8000).
Вывод: используйте ограничения как на отправку смс для одного логина, так и кол-во попыток проверки OTP.
Отдельным пунктом хочу отметить отсылку любой информации по смс без ограничений, например смс подписку на рассылку новостей, когда вводиться только номер телефона. Или после регистрации смс-код активации.
Для злоумышленников это золотая жила, данный функционал используют для флуда телефонов, автоматизируют ваши запросы и вводят номера жертвы, после чего заваливают его вашими смсками с кодом или сообщением об успешном подписании на новости.
На этом про восстановление паролей хотел бы закончить. Единственное что хотелось бы добавить, что подобная уязвимость, как недостаточная сложность паролей и хешей в огромных кол-вах нас окружает. Последний такой пример компания СИТИЛИНК у которой дисконтные карты выдаются только для покупателей заплативших за раз от 5000р. Сама по себе карта очень полезная и позволяет экономить. Но вот технически карта является обычным 6 значным номером + 4 значным кодом активации с неограниченными попытками подбора этого кода.
Так же стоит отметить недавний инцидент со skype, когда при ошибке восстановления пароля можно было получить доступ к чужой учётной записи.
Когда работаешь в данном направлении и каждый раз изучаешь разные аферы, иногда просто удивляешься как до такого могли вообще додуматься. Многое скажите Вы очевидные вещи, но все эти очевидные вещи становятся только после того, как мы обращаем на них внимания, а обычно это бывает по факту совершения злоумышленниками преступления.
Очень часто мне задают вопрос, а кто из сотрудников должен отвечать за подобные недоработки? И мне действительно хочется сказать, что все понемногу виноваты. Но когда я смотрю на эти вещи не как специалист по ИБ, читающий кучу новостей и статей, проводящий мониторинг тематических форумов и вникающий во все мошеннические схемы, а как обычный человек без всей это информации, то одёргиваю себя и останавливаюсь на мысли, что только человек имеющий всю это корыстную гадость в голове сможет обдумывать все эти нюансы заранее и причём сложность действий зависеть будет только от его изощрённого воображения. 🙂
На этом первую часть объявляю оконченной. Если подход в данной статье Вам понравится, то продолжу писать. Имеется много примеров, которые я раскидал на разные темы.
Как восстановить или обнулить пароль на Android, iPhone, Windows, Mac и Linux
Как восстановить, сбросить пароль возможно на любой ОС, так что для тех, кто забыл его, далеко не все потеряно. Однако этим способом могут воспользоваться разного рода злоумышленники, чтобы проникнуть в систему пользователя. И он намного проще, чем кажется поначалу.
В это статье мы расскажем, как сбросить пароль на Android, iPhone, Windows, macOS, Linux и других платформах. Но сначала следует обезопасить систему, включив шифрование. Потому как пароль от компьютера не спасет от несанкционированного доступа к файлам, ведь это самый элементарный метод защиты устройства от неопытных пользователей. Именно поэтому тем, кто заботится о безопасности своих файлов, следует шифровать их, что, к счастью, осуществляется без каких-либо трудностей.
Как восстановить пароль на Windows
Сбросить пароль на Windows можно разными способами. В системе есть встроенный инструмент, а именно «Создание дискеты сброса пароля», с помощью которого сбрасывается забытый пароль. Создаем такую дискету заранее (понадобится ввести пароль) и пользуемся ею в любое время.
Пользователям Windows 8 или 10, использующим для входа в систему учетную запись Microsoft, можно сбросить пароль, перейдя по этой ссылке и выбрав пункт «Я не помню свой пароль» Способ очень простой, но сработает, только если к профилю привязана эл. почта или телефон.
Сброс пароля также возможен и без помощи встроенных инструментов. Например, бесплатная утилита Offline NT Password & Registry Editor также подойдет для этой цели.
Полное шифрование диска – наиболее оптимальный вариант, который отгородит вашу систему и файлы от постороннего вмешательства, ведь любой сможет сбросить пароль так же легко, как вы. Главное, не потеряйте ключ восстановления! Потому что тогда файлы будут безвозвратно утрачены – для доступа к системе придется удалить файлы и переустановить Windows.
На Mac
Если для входа в Mac используется Apple ID, для восстановления доступа к системе можно сбросить пароль учетной записи. На экране входа в систему процесс сброса пароля сопровождается инструкциями. Также необходимо, чтобы к профилю iCloud был привязан адрес эл. почты или мобильный телефон.
Еще здесь есть встроенный инструмент для сброса пароля в режиме восстановления.
Для защиты от несанкционированного доступа рекомендуется включить встроенную систему шифрования FileVault (если она еще не включена — на многих версиях Mac она выключена по умолчанию). Если эта опция активирована, сбросить пароль вышеописанным способом уже не получится, так что нельзя ни в коем случае терять или забывать его. В таком случае вы потеряете все файлы, и придется ставить всю систему по новой.
Обнулить пароль на Linux
В данном случае мы опираемся на Ubuntu, но на других дистрибутивах Linux порядок действий и сами действия в целом не сильно отличаются друг от друга. На Ubuntu во встроенном по умолчанию загрузчике Grub имеется режим восстановления.
И тут, как и в случаях выше, шифрование – тоже превентивная мера защиты от нежелательного доступа к файлам их изменению.
Как восстановить пароль на Хромбуке
У пользовательского профиля на хромбуке и Google аккаунта один и тот же пароль. Поэтому, если мы хотим войти, но забыли пароль, следует просто сбросить пароль Google аккаунта в браузере, чтобы восстановить доступ к системе.
Предположим, старый Google аккаунт распознается системой как аккаунт владельца хромбука. В этом случае воспользуемся откатом к заводским установкам. Выходим из учетной записи хромбука, затем жмем и удерживаем сочетание клавиш Ctrl+Shift+Alt+R. Выбираем «Перезапустить». Далее жмем на опцию «Сбросить». Аккаунт, в который мы войдем после сброса заводских настроек, будет восприниматься системой как аккаунт владельца устройства. Во время сброса до заводских настроек все данные удаляются, но на многих хромбуках файлы синхронизируются по Интернету.
На хромбуке невозможно получить доступ к файлам пользователя, не зная пароля. Файлы шифруются по умолчанию. Другое дело, если вход осуществляется через Google аккаунт.
Как восстановить или сбросить пароль на Android
Тем, кто забыл пароль для разблокировки экрана на Android, может быть, удастся сбросить его.
К сожалению, эта опция убрана, начиная с Android 5.0, так что на современных гаджетах она будет недоступна.
Если знать уязвимости в системе безопасности, можно обойти блокировку экрана и без профиля Google. Либо откатить настройки до заводских в режиме восстановления. В этом случае на устройстве произойдет полное форматирование всех данных. Затем нужно будет авторизоваться и заново произвести настройки уже с другого Google аккаунта.
Как сбросить и восстановить пароль на iPhone и iPad
Забытый пароль от iPhone, iPad или iPod Touch подлежит сбросу. Тем, кто забыл пароль на устройстве с iOS, понадобится сбросить настройки до заводских, при этом все данные будут удалены. Однако, если гаджет синхронизирован с учетной записью Apple ID, и пароль от нее не забыт, тогда после, благодаря резервным копиям на iCloud, появится возможность восстановить свои файлы.
Для отката до заводских настроек существуют разные способы.
Тем, у кого нет доступа к функции «Найти iPhone» и ни одной резервной копии, все же имеется возможность сбросить настройки, загрузившись в режиме восстановления.
Установка пароля на вход в систему нужна для того, чтобы никто из посторонних и неопытных пользователей не смог воспользоваться вашим устройством. Но если у злоумышленника есть физический доступ к вашему гаджету, он может в любой момент отформатировать зашифрованные файлы, сбросив установки до исходных, чтобы пользоваться чужим устройством как ни в чем не бывало, и тут уж мало что получится сделать. Хотя есть вариант удаленно заблокировать гаджет, дабы воришка не смог воспользоваться украденным айфоном или айпэдом.
Всё, что вы хотели знать о безопасном сбросе паролей. Часть 1
Недавно у меня появилось время снова поразмыслить над тем, как должна работать функция безопасного сброса пароля, сначала когда я встраивал эту функциональность в ASafaWeb, а потом когда помогал сделать нечто подобное другому человеку. Во втором случае я хотел дать ему ссылку на канонический ресурс со всеми подробностями безопасной реализации функции сброса. Однако проблема в том, что такого ресурса не существует, по крайней мере, такого, в котором описывается всё, что мне кажется важным. Поэтому я решил написать его сам.
Видите ли, мир забытых паролей на самом деле довольно загадочен. Существует множество различных, совершенно приемлемых точек зрения и куча довольно опасных. Есть вероятность, что с каждой из них вы много раз сталкивались как конечный пользователь; поэтому я попытаюсь воспользоваться этими примерами, чтобы показать, кто делает всё правильно, а кто нет, и на чём нужно сосредоточиться для правильной реализации функции в своём приложении.
Хранение паролей: хэширование, шифрование и (ох!) простой текст
Мы не можем обсуждать, что делать с забытыми паролями, прежде чем не обсудим способ их хранения. В базе данных пароли хранятся в одном из трёх основных видов:
Шифрование лучше, но имеет свои слабые стороны. Проблема шифрования — в дешифровке; можно взять эти безумно выглядящие шифры и преобразовать их обратно в простой текст, а когда это произойдёт, мы вернёмся к ситуации с читаемыми паролями. Как это происходит? Небольшой изъян проникает в код, занимающийся дешифровкой пароля, делая его публично доступным — это один из способов. Доступ к машине, на которой хранятся зашифрованные данные, получают взломщики — это второй способ. Ещё один способ опять-таки заключается в том, что похищают резервную копию базы данных, и кто-то также получает ключ шифрования, которые часто хранятся очень ненадёжно.
И это приводит нас к хэшированию. Идея хэширования заключается в том, что оно выполняется в одну сторону; единственный способ сравнения введённого пользователем пароля с его хэшированной версией — хэширование введённого и их сравнение. Чтобы предотвратить атаки при помощи инструментов наподобие «радужных таблиц», мы при помощи соли добавляем в процесс случайность (для полноты картины прочитайте мой пост о криптографическом хранении). В конечном итоге, при правильной реализации мы можем с большой долей уверенности считать, что хэшированные пароли больше никогда не станут простым текстом (о преимуществах различных алгоритмов хэширования я расскажу в другом посте).
Краткий аргумент о хэшировании и шифровании: единственная причина, по которой вам когда-нибудь потребуется зашифровать, а не хэшировать пароль — это когда вам нужно увидеть пароль в простом тексте, а вам этого никогда не должно хотеться, по крайней мере, в ситуации со стандартным веб-сайтом. Если вам это нужно, то, скорее всего, вы делаете что-то не так!
Чуть ниже в тексте поста есть часть скриншота порнографического веб-сайта AlotPorn. Он аккуратно обрезан, и так нет ничего такого, чего нельзя увидеть на пляже, но если это всё равно может вызвать какие-то проблемы, то не прокручивайте страницу вниз.
Всегда сбрасывайте пароль, никогда его не напоминайте
Вас когда-нибудь просили создать функцию напоминания пароля? Сделайте шаг назад и подумайте об этой просьбе в обратную сторону: зачем нужно это «напоминание»? Потому что пользователь забыл пароль. Что мы на самом деле хотим сделать? Помочь ему снова войти в систему.
Я понимаю, слово «напоминание» используется (часто) в разговорном смысле, но на самом деле мы пытаемся безопасно помочь пользователю снова быть онлайн. Так как нам нужна безопасность, есть две причины, по которым напоминание (т.е. отправка пользователю его пароля) не подходит:
Очевидно, первая проблема заключается в том, что страница входа в систему не загружается по HTTPS, но сайт к тому же ещё и предлагает отправить пароль («Send Password»). Возможно, это пример упомянутого выше разговорного применения данного термина, поэтому давайте сделаем ещё один шаг и посмотрим, что произойдёт:
Выглядит ненамного лучше, к сожалению; и электронная почта подтверждает наличие проблемы:
Это говорит нам о двух важных аспектах usoutdoor.com:
Перечисление имён пользователей и его влияние на анонимность
Эту проблему лучше проиллюстрировать визуально. Проблема:
Подобные практики также вызывают возникновение опасности «перечисления имён пользователей», при котором можно проверить существование на веб-сайте целой коллекции имён пользователей или адресов почты простыми групповыми запросами и изучением ответов на них. У вас есть список адресов электронной почты всех сотрудников и несколько минут на написание скрипта? Тогда вы видите, в чём проблема!
Какова же альтернатива? На самом деле, она довольно проста, и замечательно реализована на Entropay:
Здесь Entropay совершенно ничего не раскрывает о существовании в своей системе адреса электронной почты тому, кто не владеет этим адресом. Если вы владеете этим адресом и он не существует в системе, то вы получите подобное электронное письмо:
Разумеется, возможны приемлемые ситуации, в которых кто-то думает, что зарегистрировался на веб-сайте. но это не так, или сделал это с другого адреса почты. Показанный выше пример удачно справляется с обеими ситуациями. Очевидно, если адрес совпал, то вы получите письмо, упрощающее сброс пароля.
Тонкость выбранного Entropay решения в том, что проверка идентификации выполняется по электронной почте до любой онлайн-проверки. Некоторые сайты спрашивают у пользователей ответ на секретный вопрос (подробнее об этом ниже) до того, как сможет начаться сброс; однако, проблема этого в том, что нужно ответить на вопрос, предоставив при этом какой-либо вид идентификации (почту или имя пользователя), из-за чего затем почти невозможно ответить интуитивно понятно, не раскрывая существования учётной записи анонимного пользователя.
При таком подходе есть небольшое снижение юзабилити, потому что в случае попытки сброса несуществующего аккаунта нет мгновенной обратной связи. Разумеется, в этом и есть весь смысл отправки электронного письма, но с точки зрения настоящего конечного пользователя, если он введёт неправильный адрес, то впервые узнает об этом только при получении письма. Подобное может вызвать определённую напряжённость с его стороны, но это небольшая плата за столь редкий процесс.
Ещё одно примечание, немного отклоняющееся от темы: функции помощи входу в систему, раскрывающие правильность имени пользователя или адреса электронной почты, обладают той же проблемой. Всегда отвечайте пользователю сообщением «Неправильное сочетание имени пользователя и пароля» (You username and password combination is invalid), а не подтверждайте явным образом существование идентификационной информации (например, «имя пользователя верное, но пароль введён неверно»).
Отправка пароля сброса против отправки URL сброса
Следующая концепция, которую нам нужно обсудить, связана со способом сброса пароля. Существует два популярных решения:
Но кроме этого у первого пункта существует ещё одна серьёзная проблема — он максимально упрощает блокировку учётной записи со злым умыслом. Если я знаю адрес почты того, кто владеет учётной записью на веб-сайте, то я могу заблокировать его в любой момент времени, просто сбросив его пароль; это атака типа «отказ в обслуживании», выложенная на блюдечке с голубой каёмочкой! Именно поэтому сброс должен выполняться только после успешной проверки у запрашивающего права на него.
Когда мы говорим об URL сброса, то подразумеваем адрес веб-сайта, который является уникальным для этого конкретного случая процесса сброса. Разумеется, он должен быть случайным, его не должно быть легко разгадать и он не должен содержать никаких внешних ссылок на учётную запись, упрощающих сброс. Например, URL сброса не должен быть просто путём наподобие «Reset/?username=JohnSmith».
Мы хотим создать уникальный токен, который можно будет отправить по почте как URL сброса, а затем сверить его с записью на сервере с учётной записью пользователя, подтвердив таким образом, что владелец учётной записи и в самом деле тот же самый человек, который пытается сбросить пароль. Например, токен может иметь вид «3ce7854015cd38c862cb9e14a1ae552b» и храниться в таблице вместе с ID пользователя, выполняющего сброс, и временем генерации токена (подробнее об этом чуть ниже). При отправке письма оно содержит URL наподобие «Reset/?id=3ce7854015cd38c862cb9e14a1ae552b», а когда пользователь загружает его, страница запрашивает существование токена, после чего подтверждает информацию пользователя и разрешает изменить пароль.
Разумеется, поскольку описанный выше процесс (будем надеяться) позволяет пользователю создать новый пароль, нужно гарантировать загрузку URL по HTTPS. Нет, передать его POST-запросом по HTTPS недостаточно, этот URL с токеном должны использовать безопасность транспортного слоя, чтобы на форму ввода нового пароля невозможно было совершить атаку MITM и созданный пользователем пароль передавался по защищённому соединению.
Также для URL сброса нужно добавить лимит времени токена, чтобы процесс сброса можно было выполнить в течение определённого интервала, допустим, в пределах часа. Это гарантирует, что окно времени сброса будет минимальным, чтобы получивший этот URL сброса мог действовать только в рамках этого очень маленького окна. Разумеется, нападающий может снова начать процесс сброса, но ему понадобится получить ещё один уникальный URL сброса.
Наконец, нам нужно обеспечить одноразовость этого процесса. После завершения процесса сброса токен необходимо удалить, чтобы URL сброса больше не был работающим. Предыдущий пункт нужен для того, чтобы у нападающего было очень малое окно, в течение которого он может манипулировать URL сброса. Плюс, разумеется, после успешного завершения сброса токен больше не нужен.
Некоторые из этих шагов могут показаться чересчур избыточными, но они совершенно не мешают юзабилити и на самом деле повышают безопасность, хотя и в ситуациях, которые, мы надеемся, будут редкими. В 99% случаев пользователь будет задействовать сброс в течение очень короткого промежутка времени и не будет сбрасывать пароль снова в ближайшем будущем.
Роль CAPTCHA
О, CAPTCHA, средство защиты, которое все мы так любим ненавидеть! На самом деле, CAPTCHA средство не столько защиты, сколько идентификации — человек вы или робот (или автоматизированный скрипт). Её смысл в том, чтобы избежать автоматическую отправку форм, которая, разумеется, может применяться как попытка взлома защиты. В контексте сброса паролей CAPTCHA означает, что функцию сброса невозможно будет взломать грубым перебором, чтобы или потом спамить пользователю, или попытаться определить существование учётных записей (что, разумеется, будет невозможно, если вы следовали советам из раздела о проверке идентификации).
Разумеется, сама по себе CAPTCHA неидеальна; существует множество прецедентов её программного «взлома» и достижения достаточных показателей успеха (60-70%). Кроме того, существует решение, показанное в моём посте о взломе CAPTCHA автоматизированными людьми, при котором можно платить людям доли цента для решения каждой CAPTCHA и получения показателя успеха в 94%. То есть она уязвима, однако (слегка) повышает входной барьер.
Давайте взглянем на пример PayPal:
В данном случае процесс сброса просто не может начаться до решения CAPTCHA, поэтому теоретически автоматизировать процесс невозможно. Теоретически.
Однако для большинства веб-приложений это будет перебором и совершенно точно представляет собой снижение юзабилити — люди просто не любят CAPTCHA! Кроме того, CAPTCHA — это такая вещь, к которой при необходимости можно будет легко вернуться. Если сервис начинает подвергаться нападению (здесь пригождается логгинг, но подробнее об этом позже), то добавить CAPTCHA легче некуда.
Секретные вопросы и ответы
При всех рассмотренных нами способах мы имели возможность сбросить пароль, всего лишь имея доступ к учётной записи электронной почты. Я говорю «всего лишь», но, разумеется, незаконное получение доступа к чужой учётной записи почты должно быть сложным процессом. Однако это не всегда так.
На самом деле, представленная выше ссылка о взломе учётной записи Сары Пэйлин на Yahoo! служит двум целям; во-первых, она иллюстрирует, насколько легко можно взламывать (некоторые) почтовые аккаунты, во-вторых, она показывает, как можно со злым умыслом использовать плохие секретные вопросы. Но мы вернёмся к этому позже.
Проблема со сбросом паролей со стопроцентной зависимостью от электронной почты заключается в том, что целостность учётной записи сайта, пароль которого вы пытаетесь сбросить, становится стопроцентно зависимым от целостности учётной записи электронной почты. Любой, кто имеет доступ к вашей электронной почте, имеет доступ к любому аккаунту, который можно сбросить простым получением электронного письма. Для таких аккаунтов электронная почта является «ключом от всех дверей» вашей жизни онлайн.
Один из способов снижения этого риска — реализация паттерна секретного вопроса и ответа. Без сомнений, вы уже видели их: выбираете вопрос, на который только вы должны знать ответ, после чего при сбросе пароля вам его задают. Это добавляет уверенности в том, что человек, пытающийся выполнить сброс и в самом деле является владельцем аккаунта.
Вернёмся к Саре Пэйлин: ошибка была в том, что ответы на её секретный вопрос/вопросы легко можно было найти. В частности, когда ты такая значимая общественная фигура, информация о девичьей фамилии матери, истории обучения или о том, где кто-то мог жить в прошлом, не такая уж и секретная. На самом деле, большая её часть может быть найдена практически любым. Так и произошло с Сарой:
Хакер Дэвид Кернелл получил доступ к учётной записи Пэйлин, найдя подробности её биографии, такие как её вуз и дату рождения, а затем использовав функцию восстановления забытых паролей к учётным записям Yahoo!.
В первую очередь это ошибка проектирования со стороны Yahoo! — указав такие простые вопросы, компания по сути саботировала ценность секретного вопроса, а значит, и защиту своей системы. Разумеется, сброс паролей к учётной записи электронной почты всегда сложнее, ведь вы не можете подтвердить её владение, отправив владельцу электронное письмо (не имея второго адреса), но, к счастью, сегодня для создания такой системы не так уж много способов применения.
Вернёмся к секретным вопросам — существует вариант предоставить пользователю возможность создания собственных вопросов. Проблема в том, что в результате будут получаться ужасно очевидные вопросы:
Какого цвета небо?
Вопросы, ставящие людей в неудобное положение, когда для идентификации секретный вопрос использует человек (например, в колл-центре):
С кем я переспал на Рождество?
Или откровенно глупые вопросы:
Как пишется «пароль»?
Когда дело касается секретных вопросов, пользователей нужно спасти от самих себя! Другими словами, секретный вопрос должен определять сам сайт, а ещё лучше, задавать серию секретных вопросов, из которых может выбирать пользователь. И не просто выбирать один; в идеале пользователь должен выбрать два или более секретных вопросов в момент регистрации аккаунта, которые затем будут использоваться как второй канал идентификации. Наличие нескольких вопросов повышает степень уверенности в процессе проверки, а также даёт возможность добавления случайности (не всегда показывать одинаковый вопрос), плюс обеспечивает немного избыточности на случай, если настоящий пользователь забыл пароль.
Каким же должен быть хороший секретный вопрос? На это влияет несколько факторов:
Позвольте мне продемонстрировать, как секретные вопросы реализованы в PayPal и, в частности, какие усилия сайт прикладывает для идентификации. Выше мы видели страницу начала процесса (с CAPTCHA), а здесь мы покажем, что происходит после того, как вы вводите адрес почты и решаете CAPTCHA:
В результате пользователь получает такое письмо:
Пока всё вполне обычно, но вот что скрывается за этим URL сброса:
Итак, в дело вступают секретные вопросы. На самом деле, PayPal также позволяет сбросить пароль, подтвердив номер кредитной карты, поэтому существует дополнительный канал, к которому не имеют доступа множество сайтов. Я просто не могу изменить пароль, не ответив на оба секретных вопроса (или не зная номер карты). Даже если кто-то захватит мою электронную почту, он не сможет сбросить пароль учётной записи PayPal, если не знает обо мне чуть больше личной информации. Какой информации? Вот варианты секретных вопросов, предлагаемые PayPal:
Вопрос о школе и больнице может быть слегка сомнительным с точки зрения простоты поиска, но остальные не так плохи. Однако для повышения безопасности PayPal требует дополнительной идентификации для изменения ответов на секретные вопросы:
PayPal — довольно утопический пример безопасного сброса пароля: он реализует CAPTCHA для снижения опасности грубого перебора, требует два секретных вопроса, а затем требует ещё один вид совершенно другой идентификации только для смены ответов — и это после того, как пользователь уже выполнил вход. Разумеется именно этого мы и ожидали бы от PayPal; это финансовая организация, работающая с большими суммами денег. Это не означает, что каждый сброс пароля должен следовать этим этапам — в большинстве случаев это перебор — однако это хороший пример для случаев, когда безопасность — серьёзный бизнес.
Удобство системы секретных вопросов в том, что если вы не реализовали её сразу, то её можно добавить позже, если этого требует уровень защиты ресурса. Хорошим примером этого служит Apple, только недавно реализовавшая этот механизм [статья написана в 2012 году]. Начав однажды обновлять приложение на iPad, я увидел следующий запрос:
Затем я увидел экран, на котором можно было выбрать несколько пар секретных вопросов и ответов, а также спасательный адрес электронной почты:
Что касается PayPal, то вопросы выбраны заранее и некоторые из них на самом деле довольно неплохи:
Каждая из трёх пар вопросов и ответов представляет отдельное множество возможных вопросов, поэтому существует достаточное количество способов конфигурирования учётной записи.
Ещё одним аспектом, который нужно рассмотреть относительно ответа на секретный вопрос, является хранение. Нахождение в ДБ простого текста представляет почти те же угрозы, что и в случае пароля, а именно — раскрытие базы данных мгновенно раскрывает значение и подвергает риску не только приложение, но и потенциально совершенно другие приложения, использующие те же секретные вопросы (это снова вопрос ягод асаи). Одним из вариантов является безопасное хэширование (стойкий алгоритм и криптографически случайная соль), однако в отличие от большинства случаев хранения паролей, здесь может быть уважительная причина видимости ответа как простого текста. Типичным сценарием является проверка личности живым оператором по телефону. Разумеется, в этом случае хэширование тоже применимо (оператор может просто ввести названный клиентом ответ), но в самом худшем случае секретный ответ должен находиться на каком-нибудь уровне криптографического хранилища, даже если это просто симметричное шифрование. Подведём итог: обращайтесь с секретами как с секретами!
И последний аспект секретных вопросов и ответов — они более уязвимы для социального инжиниринга. Пытаться напрямую выпытывать пароль к чужому аккаунту — это одно дело, а завязать разговор о его образовании (популярный секретный вопрос) — совершенно другое. На самом деле, вы вполне реально можете общаться с кем-то о многих аспектах его жизни, которые могут представлять секретный вопрос, и не вызывать при этом подозрений. Разумеется, сама суть секретного вопроса в том, что он связан с чьим-то жизненным опытом, поэтому он запоминается, и именно в этом заключается проблема — люди любят рассказывать о своём жизненном опыте! С этим мало что можно поделать, только если выбрать такие варианты секретных вопросов, чтобы их с меньшей вероятностью можно было бы вытянуть социальным инжинирингом.
На правах рекламы
VDSina предлагает надёжные серверы с посуточной оплатой, каждый сервер подключён к интернет-каналу в 500 Мегабит и бесплатно защищён от DDoS-атак!