Что значит сбросить пароль
Забыл пароль от телефона Android: как сбросить
Рассмотрим несколько способов снятия блокировки с экрана телефона или другого устройства под управлением операционной системы Android.
Чтобы обезопасить свое мобильное устройство от взлома и ограничить несанкционированный доступ к нему, практически каждый из нас пользуется блокировкой экрана. Ранее заблокировать экран можно было только с помощью нескольких примитивных способов: пароль, PIN-код или графический ключ.
Со временем появились более надежные и технологичные методы защиты: блокировка по отпечатку пальца, распознавание лица и сканер сетчатки глаза. Да и к тому же новые способы не требуют запоминать никаких паролей – просто приложил палец к сканеру или посмотрел на глазок камеры, и в считанные секунды телефон будет разблокирован.
Но при использовании более примитивных методов часто бывает так, что мы попросту забываем заданные пароль, PIN-код или графический ключ. И если в более ранних версиях Android существовали простые лазейки, чтобы обойти блокировку и снять ее, то на новых сборках сделать это не так просто.
Сброс до заводских настроек
Сначала разберем самый простой вариант сброса – возврат к заводскому состоянию. Это довольно простая процедура, которую можно активировать и в настройках, но учитывая, что экран заблокирован, мы пойдем немного иным способом.
Обратите внимание! Данный метод полностью очищает внутреннее хранилище. Все установленные приложения, загруженные фотографии, видео и другой контент будет удален. Если на устройстве хранится ценная для вас информация, пропускайте этот способ.
Откат к заводскому состоянию фактически возвращает систему к тому виду, в котором она была после первого запуска, когда вы только вытащили устройство новеньким из коробки. Естественно, что в таком случае будут сброшены пользовательские настройки и удалены все приложения и данные.
Шаг 1. Зажимаем кнопку питания и выключаем смартфон.
Шаг 2. Нажимаем «Громкость +» и клавишу питания, удерживая их до появления логотипа. Важный момент: первой нажимаем именно клавишу качели громкости, а отпускаем ее в последнюю очередь.
Шаг 2.1. Нажимаем и удерживаем «Громкость +» (клавиша увеличения громкости).
Шаг 2.2. Нажимаем и удерживаем кнопку питания.
Шаг 2.3. Ожидаем вибрации и появления логотипа.
Шаг 2.4. Ждем еще 1-2 секунды, отпускаем клавишу питания и громкости.
Шаг 3. Запустится сервисное меню, где нужно найти строку «Wipe data/factory reset». Качелькой громкости выбираем ее и подтверждаем намерение кнопкой «Power».
Здесь может запуститься меню «Fastboot» вместо нужного нам «Recovery». Если вы не найдете описанную выше строку, то ищем среди списка что-то вроде «Recovery» (или «Boot Recovery»), как показано на фото ниже и возвращаемся к пункту 3.
Шаг 4. Далее подтверждаем свой выбор опять же с помощью клавиш качельки громкости и питания, выбирая строку «Yes — delete all user data».
Шаг 5. По завершении процесса вновь появится меню со списком действий, которые мы можем выбрать. В этот раз выбираем строку «Reboot system now» и перезагружаемся.
Пользуемся сервисом Google
Пожалуй, это был бы лучший способ снятия блокировки с экрана Android устройства, если бы не пара нюансов.
Сам сервис называется «Find My Phone» и помогает найти утерянное устройство, а также предотвратить к нему доступ или утечку данных. Итак, если есть возможность подключиться к сети (включить мобильные данные и Wi-Fi можно даже в заблокированном состоянии), то повторяем следующие действия:
Шаг 1. Переходим на эту страницу и вводим свои данные от аккаунта Google.
Шаг 2. Выбираем нужное нам устройство из списка (если их несколько) и нажимаем на раздел «Erase Device».
Шаг 3. Развернется небольшое меню с предупреждениями о том, что все данные будут удалены и прочее. Мы об этом уже знаем и просто жмем на зеленую кнопку «Erase Device».
Шаг 4. Далее снова подтверждаем действие и ожидаем окончания процесса. На этом этапе Google может попросить снова зайти в аккаунт, чтобы подтвердить свою личность.
Пользуемся сервисом Samsung
Это практически идентичный способ сброса блокировки, который мы только что рассмотрели выше. Дело в том, что и у компании Samsung есть сервис, позволяющий найти привязанные к аккаунту устройства и проделать некоторые манипуляции с ними. Даже название этого сервиса практически не изменилось – «Find My Mobile».
Но у сервиса южнокорейской компании есть 1 неоспоримое преимущество – мы можем разблокировать устройство (снять установленные способы защиты экрана) без удаления пользовательских данных.
Шаг 1. Переходим по этой ссылке на официальный сайт и нажимаем кнопку «Войти».
Шаг 2. Выполняем вход в учетную запись Samsung Account, вводя данные электронной почты и пароля.
Шаг 3. Принимаем политику конфиденциальности и другие необходимые для использования сервиса соглашения нажатием кнопки «Принять».
Шаг 4. Аналогично шагам предыдущей инструкции выбираем нужное устройство, жмем кнопку «Разблокировать» и подтверждаем действия.
Снимаем блокировку с помощью ADB
Данный метод уникален тем, что позволяет сбросить пароль, не затрагивая никаких личных данных, хранящихся на устройстве. Все приложения, фотографии, документы и другой контент останется в целостности, мы повлияем только на несколько файлов в системе, которые и отвечают за установленный метод блокировки экрана.
Следует отметить, что данный способ будет работать, только если выполняются следующие условия:
- В настройках активирован режим «Для разработчиков». Включена функция «Отладка по USB». Присутствует root-доступ.
Также, скорее всего все следующие действия сработают только для смартфонов/планшетов под управлением ОС Android 5.1 и ниже. Можно попробовать и на более свежих выпусках (6.0+), но 100% работоспособность не гарантируется, так как, скорее всего, Google «прикрыла» эту фишку.
Для начала устанавливаем сам пакет ADB.
Шаг 1. Переходим на официальный сайт по этой ссылке и скачиваем необходимые инструменты нажатием на «Download SDK Platform-Tools for Windows» (есть также версии для Mac и Linux).
Шаг 2. Принимаем соглашения и нажимаем на кнопку загрузки.
Шаг 3. В загруженном архиве будет единственная папка «platform-tools», которую мы просто перемещаем на системный диск «C».
Шаг 4. Открываем эту папку, зажимаем клавишу «Shift» и кликаем правой кнопкой мыши по пустой области, вызывая контекстное меню. Выбираем строку «Открыть окно команд».
Шаг 5. Подключаем по USB устройство к компьютеру и проверяем работоспособность пакета ADB. Делается это с помощью следующей команды: «adb devices». Если появляется строка с номером устройства и надписью «device», то значит, что все работает – компьютер видит подключенный смартфон. Если этого не происходит, можно попробовать установить универсальные драйвера ADB и Fastboot под ваше устройство по этой ссылке.
Теперь рассмотрим 2 способа снятия блокировки через ADB. Каждый из них предполагает последовательное введение запросов в командной строке компьютера.
Вариант 1:
Если в процессе ввода команд выше появляются какие-то ошибки вроде «No such file or directory» и других – это еще мало о чем говорит, поэтому просто продолжаем. Несмотря на появление ошибки при вводе одной из команд, на планшете ASUS FoneFad 7 все прошло успешно после перезагрузки – графический ключ исчез.
Вариант 2 (для тех, у кого установлен графический ключ):
Для тех, кто пробует второй вариант – после ввода команд сброс ключа не произойдет, но можно будет ввести любую комбинацию, и устройство примет ее в качестве правильной. А уже после разблокировки можно зайти в настройки и снять ключ.
Сброс с помощью кастомного рекавери (CWM/TWRP)
Последний способ в нашей инструкции касается устройств, которые имеют установленное кастомное рекавери. Если вы первый раз слышите слова «CWM Recovery» или «TWRP Recovery», то, скорее всего, этот блок статьи ничем вам не поможет. А чуть более опытные пользователи, уже сталкивавшиеся с процессом установки кастомного рекавери, наверняка и без следующей инструкции знают что делать.
И все же, рассчитывая на то, что не все знают о данном методе, мы подробно рассмотрим его. Если кратко, то благодаря кастомному рекавери мы запустим файловый менеджер, вручную перейдем по пути и найдем несколько файлов, содержащих в себе информацию о способе блокировки экрана.
Для тех, у кого установлено TWRP Recovery:
Шаг 1. Загружаемся в рекавери и переходим на вкладку «Advanced».
Шаг 2. Выбираем пункт «File Manager» и запускаем проводник.
Шаг 3. Переходим по пути «/data/system» и находим 5 файлов: «gatekeeper.password.key» (или просто «password.key»), «locksettings.db-shm», «locksettings.db», «gatekeeper.pattern.key» (или же «gesture.key») и «locksettings.db-wal».
Шаг 4. Удаляем файлы (нажимаем по любому из них и жмем кнопку «Delete», после чего повторяем действие с помощью свайпа и возвращаемся назад клавишей «Back») и перезагружаемся в систему.
Для тех, у кого установлено CWM Recovery:
Шаг 1. Переходим по ссылке и скачиваем архив, который помещаем на карту памяти нашего устройства.
Шаг 2. Загружаемся в рекавери и выбираем пункт под названием «install.zip».
Шаг 3. Выбираем строку «Choose zip from /sdcard» и переходим по пути на карте памяти, в которой лежит загруженный архив.
Шаг 4. Нажимаем на строку с именем архива и ждем запуска.
Шаг 5. Повторяем действия, описанные в шагах 3 и 4 из инструкции выше (также находим файлы и удаляем их, но уже в интерфейсе проводника «Aroma»).
Заключение
Выше мы разобрали 5 наиболее эффективных и работающих методов для сброса пароля на Android. Одни из них требуют root, установленного пакета ADB и прочих «танцев с бубном» и различных подготовительных процессов, поэтому подойдут далеко не каждому пользователю. Но среди описанных методов есть и те, которыми может воспользоваться каждый. Например, сброс до заводского состояния. Правда придется пожертвовать хранящимися в памяти файлами.
Есть и некоторые другие варианты сброса пароля, но все они так или иначе являются производными от тех, что мы уже описали. Пробуйте и в точности следуйте инструкциям, и у вас все получится.
Как восстановить аккаунт на любом сайте через сброс пароля: пошаговая инструкция с примерами!
Никто не застрахован от потери логинов, паролей, пинкодов карт и другой важной информации, которую в таком случае приходится восстанавливать, чтобы получить доступ к сайтам, личному кабинету банка или, например, снять наличку в банкомате.
Из своего опыта вижу насколько часто ещё неопытные пользователи компьютеров и в целом любых гаджетов забывают или теряют свои пароли от аккаунтов на различных сайтах, например, от своей почты, от странички в социальной сети.
Потому что не привыкли правильно сохранять пароли в «облаке» через браузеры, пользоваться специальными менеджерами паролей, которые позволяют все их хранить вместе с логинами и другими данными от интернет-ресурсов, ну или, на крайний случай, не записывают в какой-нибудь блокнот.
Поэтому, сохранив пароль, например, лишь в браузере локально (т.е. на компьютере), при сбросе настроек браузера или при его очистке, пароли будут потеряны и это сразу доставляет проблем новичку. А тетрадка с паролями может потеряться, испортиться или же сразу при записи пароля могли ошибится, ведь всё делали вручную.
Как восстановить аккаунт (сбросив пароль) на любом интернет-ресурсе
Я указал, что на любом и в принципе всё так и есть в 99% случаев, за мааалым совсем исключением, когда на сервисах нет возможности сброса пароля. Если честно, я таких встречал может 1-2 за всё время взаимодействия с интернетом, причём даже уже и не помню, что это были за сайты.
Сама технология сброса аналогична для любых сайтов и состоит в следующем:
Перейти по ссылке сброса пароля (как правило, называется «Забыли пароль?», «Не помню пароль» и аналогично);
Указать свои данные. Как правило, сайты запрашивают email, на который произведена регистрация, бывает требуется ответ на контрольный вопрос, указание каких-то других данных из восстанавливаемого аккаунта (например, даты рождения, ФИО…).
Вместо email или вместе с ним могут запрашивать и телефон и тогда восстановление идёт уже через него.
А иногда запрашивается резервный адрес, который был указан в аккаунте для восстановления доступа;
На указанный email отправляется ссылка, по которой достаточно перейти и можно указывать уже новый пароль, под которым затем сможете заходить на сайт.
Или же придёт СМС-ка на телефон, где будет код для восстановления доступа, который нужно ввести на сайте, после чего можно будет указать новый пароль.
То есть в самом процессе никаких хитростей и сложностей нет. Не придётся с какими-нибудь бумагами нестись в офис, чтобы что-то восстановить :))
Теперь рассмотрим пару конкретных примеров, пройдём процедуру сброса пароля от начала и до конца в двух различных сервисах.
Пример №1: сброс пароля в сервисах Яндекс
Итак, перешли мы к странице входа в наш аккаунт Яндекса, ввели логин и вот проблема, пароль то забыли! Ну что ж, решаем проблему, нажимаем кнопку «Не помню пароль».
Нас перебрасывает на страницу, где просят указать логин и ввести капчу. Причём обратите внимание, яндекс даже предусмотрел случай, когда забыт не только пароль, но и логин, поскольку имеется ссылка «Я не помню логин», для его восстановления.
Вводим данные и жмём «Далее»:
Яндекс просит указать резервный email, который был указан в личном кабинете. Указываем его, нажимаем «Получить код».
Теперь нужно перейти на почту, которую сейчас указывали, найти там письмо от Яндекс и перейти в нём по ссылке:
В итоге Яндекс откроет страницу для ввода нового пароля, останется ввести его дважды и в общем-то всё, доступ восстановлен!
Далее нужно будет войти в Яндекс уже под новым паролем. И рассмотрим ещё один пример.
Пример №2: сброс пароля от аккаунта интернет-магазина Юлмарт
Итак, перешёл я на страницу входа в личный кабинет Ulmart, пароля не помню, что делать? Правильно, меня спасёт всё та же волшебная ссылка «Забыли пароль?», на которую я нажимаю:
На следующей странице сервис просит указать либо электронную почту, либо телефон, под которыми я регистрировался. Мне всегда было удобнее восстанавливать по почте, поэтому я выбрал этот способ, после чего ввёл капчу «Я не робот», указал зарегистрированный email и нажал «Отправить».
Магазин сразу сообщил мне, что инструкция по восстановлению выслана на указанный адрес почты:
Далее проверяю указанную почту, нахожу письмо от Юлмарт, открываю и вижу, что для восстановления пароля нужно перейти по ссылке:
Кликаю по ней и на новой странице остаётся указать новый пароль, ввести его повторно и сохранить. Готово!
Заключение
Как видим из двух разобранных мной примеров, процедура восстановления пароля на сайтах очень простая, работает везде по одному принципу.
Бывает, что помимо пароля, забывается ещё и логин, в таком случае ситуация усложняется. Часто на форме входа в аккаунт на сайтах есть ссылка и на этот случай, например, «Не помню логин» и тогда вам будут предложены способы его восстановления.
Крайний случай, когда никакой информации не помните, которую запрашивает сервис при восстановлении, обратитесь в тех.поддержку, вероятно, вам помогут восстановить доступ.
Но упускать ситуацию до такого не следует! Обязательно храните где-нибудь пароли, например я сам пароли храню в облаке Google, куда они попадают прямо из браузера Google Chrome.
Пользуюсь я именно этим браузером, потому что для меня он удобен и пароли могу достать с любого устройства очень быстро, главное чтобы было подключение к интернету. Вы можете выбрать любой другой способ, например, хранить пароли в облаке через другой браузер (сейчас в принципе все основные позволяют это делать), либо пользуйтесь специальными менеджерами паролей!
Совет напоследок: делайте пароли сложными, не следуйте стандартной логике, что чем проще пароль, тем соответственно легче его запомнить! Чем проще пароль, тем быстрее вас взломают, вот так будет правильнее!
Делайте сложные пароли, причем для каждого сайта свой, чтобы если вдруг кто-то получил доступ от вашего аккаунта на одном сайте, не смог затем быстренько заполучить доступ и к вашим личным кабинетам на других ресурсах.
Частенько ли вы забываете пароли, что приходится восстанавливать? А может кто-то помнит случай, когда пароль был забыт и стандартная процедура восстановления не помогла, опишите ситуацию, было бы интересно узнать что за сайт такой и почему не получилось восстановить доступ. А может и способ подскажу, если ещё актуально 😉
Всего вам суперского, скоро увидимся!
Сделай репост – выиграй ноутбук!
Каждый месяц 1 числа iBook.pro разыгрывает подарки.
—> 
LENOVO или HP от 40-50 т.р., 8-16ГБ DDR4, SSD, экран 15.6″, Windows 10
12 комментариев
Автор: Владимир Белев
Автор: Владимир Белев
Бывает такое, что на сервисе не восстанавливают доступ, но это крайне редко. Если дадите ссылку на сайт, зайду посмотрю. Возможно делают восстановление через обращение в отдел тех.поддержки или чат, если он там доступен.
А как поменять пароль от сайта gamehag? Я уже его 5 раз меняла потому что старый забыла,а теперь хочу забрать приз робуксы,но я не могу потому что теперь надо его забирать из Яндекса. Что делать? Подскажите пожалуйста.
Автор: Владимир Белев
На любом сервисе процедура смены пароля и восстановления его в случае утери, одинакова. Gamehag не исключение: если забыли пароль, там есть кнопка «Зайти» и далее ссылка «Забыли пароль» (http://prntscr.com/rxrwck), при помощи которой мы можем получить на почту новый пароль. Если же пароль не утерян, то можно его сменить в личном кабинете, в своем профиле.
Автор: Алевтина
Автор: Владимир Белев
Обычно без причин отказов Яндекс не дает. Что вам ответили из Яндекса?
Какие ж умные,думаете без вашего этого бреда не кто без вас не додумался?тогда уж простите кто вы.а вот если реально не чего нет не не электронки не номера?.все пороли забыл со временем.вот это проблема.а то что описанно в этой статье может сделать и ребенок.
Автор: Владимир Белев
Уважаемый, если человек регистрируясь на сайте не помнит ни email, ни телефона, ни логина, ни других данных, это несерьезно. А на счет «сможет сделать ребенок», посмотрите ради интереса по подсказкам поисковика и статистике запрашиваемости подобных вопросов, удивитесь. Люди это ищут и поверьте, не единицы. Удачи 😉
Большое спасибо! за очень полезную статью! 
Всё, что вы хотели знать о безопасном сбросе паролей. Часть 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-атак!