Из журнала Wired:
... взломать Пэйлин не требовалось никаких реальных навыков. Вместо этого, хакер просто сбросил пароль Пэйлин, используя ее дату рождения, почтовый индекс и информацию о том, где она встретила своего супруга - секретный вопрос в ее учетной записи Yahoo, на который (Wasilla High) был дан простой поиск в Google.
Мы не можем доверять таким вопросам безопасности для восстановления забытых паролей.
Как вы проектируете лучшую систему?
Внеполосная связь - это путь.
Например, отправка временного пароля в SMS может быть приемлемой (в зависимости от системы). Я видел, как это часто осуществлялось операторами связи, где SMS дешево/бесплатно/часть бизнеса, а номер мобильного телефона пользователя предварительно зарегистрирован...
Банкам часто требуется телефонный звонок с/на определенный номер, но я лично не слишком сумасшедший об этом....
И, конечно, в зависимости от системы, заставить пользователя войти в филиал, чтобы лично идентифицировать себя, также может работать (просто рояльно раздражает пользователя).
Нижняя строка, НЕ создавайте более слабый канал для обхода надежных требований к паролю.
Небезопасность так называемых "вопросов безопасности" известна уже давно. Как Брюс Шнайер ставит его:
В результате нормальный протокол безопасности (пароли) возвращается к гораздо менее безопасному протоколу (секретные вопросы). И безопасность всей системы страдает.
Что можно сделать? Моя обычная техника заключается в том, чтобы набрать абсолютно случайный ответ - я безумно шлепаю по моей клавиатуре в течение нескольких секунд - и затем забываю об этом. Это гарантирует, что какой-либо атакующий не сможет обойти мой пароль и попытаться угадать ответ на мой секретный вопрос, но довольно неприятно, если я забуду свой пароль. Однажды это случилось со мной, мне пришлось позвонить в компанию, чтобы получить мой пароль и вопрос reset. (Честно говоря, я не помню, как я подтвердил себя представителем службы поддержки клиентов на другом конце телефонной линии.)
Я думаю, что лучше всего просто отправить электронное письмо со ссылкой, которую они могут использовать для создания нового случайного пароля для учетной записи электронной почты, которую пользователь первоначально использовал для регистрации. Если они не запросят новый пароль, они могут просто игнорировать его и продолжать использовать свой старый. Как отмечали другие, это не обязательно помогло бы Yahoo, поскольку у них была служба электронной почты, но для большинства других служб электронная почта - достойная проверка подлинности (фактически, вы навязываете проблему аутентификации на поставщик электронной почты пользователя).
Конечно, вы можете просто использовать OpenID.
Увидев много плакатов, предлагайте электронную почту, все, что я могу предложить, это DONT использовать электронную почту в качестве вашей линии защиты.
Компрометация учетной записи электронной почты somebodys может быть относительно простой. Многие веб-службы электронной почты DONT предоставляют любую реальную безопасность, даже если они предлагают SSL, часто не являются стандартными, и вы все еще полагаетесь на слабость пароля электронной почты для защиты пользователя (что в В большинстве случаев оборот имеет механизм reset).
Электронная почта - одна из самых небезопасных технологий, и есть веские причины, почему ее действительно плохая идея отправлять информацию, такую как данные кредитной карты по ним. Обычно они передаются между серверами в виде открытого текста и одинаково часто между сервером и настольным клиентом одинаково незашифрованным, и все, что требуется, - это проводное обнюхивание, чтобы получить URL-адрес reset и запустить его. (Не говорите, что я параноидальный, потому что банки используют SSL-шифрование по уважительной причине. Как вы можете доверять 20-200 физическим устройствам на маршруте, имеют хорошие намерения?)
Как только вы получите данные reset, вы можете reset пароль, а затем изменить свой (их) адрес электронной почты и иметь постоянный контроль над своей учетной записью (это происходит все время).
И если они получат вашу учетную запись электронной почты, все, что им нужно сделать, - это просмотреть свой почтовый ящик, чтобы найти, на кого вы подписаны, а затем легко reset пароль ПО ВСЕМУ ИХ
Итак, теперь, используя безопасность на основе электронной почты, может привести к уязвимости безопасности! Я уверен, что это полезно!
Заданный вопрос. Я считаю, что практически невозможно сделать это с помощью программного обеспечения. Вот почему у нас есть двухфакторная аутентификация с аппаратными ключами, которые реагируют на вызовы с их собственной уникальной подписью на секретный ключ, и только если вы потеряете то, что вы ввернули, и вам тогда придется иметь дело с человеком (о нет), чтобы получить новый.
Это зависит от "системы".
Если вы являетесь Банком или поставщиком кредитной карты, вы уже выпустили какой-либо физический токен для вашего клиента, который вы можете проверить против и больше.
Если вы являетесь сайтом электронной коммерции, вы запрашиваете некоторые недавние транзакции -точные суммы, номер используемой кредитной карты и др.
Если вы похожи на Yahoo, автоматизированный подход, который я бы использовал, - это отправить код активации через телефонный вызов или текстовое сообщение в ячейку телефон вместе с некоторыми другими основными вопросами и ответами.
Джей
Попросите пользователя ввести 3 вопроса и ответы. Когда они запрашивают reset представить их с выпадающим из 5 вопросов, один, если это случайный номер из 3, которые они ввели. Затем отправьте письмо с подтверждением на reset пароль.
Конечно, ничто не будет действительно "доказательством хакера".
Уберите все вопросы (в) безопасности. Они - такая очевидная дыра в безопасности, что я на самом деле немного удивлен, что для этого потребовалось много времени, чтобы создать серьезный (ну, очень известный) инцидент.
Пока они не исчезнут, я просто буду продолжать рассказывать веб-сайты, которые используют их, что я пошел в "n4weu6vyeli4u5t" в средней школе...
Когда пользователи участвуют (и в большинстве случаев, когда нет) тоже нет безопасности; есть только иллюзия безопасности. Там вы не можете много сделать. У вас могут быть "менее распространенные" вопросы безопасности, но даже они подвержены эксплуатации, поскольку некоторые люди все раскрывают в глазах общественности.
Вторичные каналы, такие как электронная почта, предлагают разумное решение проблемы. Если пользователь запрашивает пароль reset, вы можете отправить им по электронной почте пароль reset. Все еще не идеально, как говорили другие, но использование этого потребовало бы, чтобы злоумышленник находился где-то в зоне видимости между веб-сайтом, его MTA и пользователями MUA. Это технически легко, но я полагаю, что реальность - это слишком много работы/риска для них, чтобы беспокоить кого угодно, кроме людей с очень высоким профилем.
Требование, чтобы пользователь предоставил открытые ключи SSL или GPG во время создания учетной записи, будет чрезвычайно помог, но незнакомые пользователи не будут знать, что эти вещи позволяют самостоятельно сохранять и защищать свои секретные ключи, t потерять их.
Просить пользователя предоставить второй пароль для экстренной помощи (например, PIN/PUK на SIM-картах мобильного телефона) может помочь, но, скорее всего, пользователь будет использовать один и тот же пароль дважды или забыть второй пароль тоже.
Короткий ответ, вы SOL, если вы не хотите обучать своих пользователей безопасности, а затем ударить их с помощью cluestick, пока они не поймут, что необходимо быть в безопасности, а небольшая сумма дополнительной работы - это не просто боль в заднице.
Аутентификация всего, отправляя электронные письма, является достаточно эффективным решением. (хотя, возможно, в этом случае это не было бы возможно для Yahoo:)).
Вместо того, чтобы возиться с вопросами безопасности или другими способами для восстановления паролей, просто ответьте на запросы восстановления пароля, отправив электронное письмо на предопределенную учетную запись электронной почты с помощью ссылки авторизации. Оттуда вы можете изменить пароли или все, что вам нужно сделать (никогда не отсылайте пароль, хотя вы всегда должны хранить его как соленый хеш, всегда меняйте его. Затем, если учетная запись электронной почты была скомпрометирована, по крайней мере, есть некоторые указания на пользователь, к которому обращались другие сервисы)
Истинный ответ заключается в том, что у вас есть хакерские доказательства. Я ненавижу вопросы безопасности, но если вы собираетесь использовать их, разрешите заданные пользователем вопросы безопасности. Как пользователь, если у меня должен быть вопрос безопасности на сайте, чтобы настроить учетную запись, мне очень нравится иметь возможность настроить свой собственный вопрос безопасности, чтобы я мог спросить то, что только я знаю, как ответить. В этом случае это даже не должно быть реальным вопросом. Но учетная запись пользователей тогда столь же безопасна, как глупость пользователя, и тот факт, что многие пользователи будут использовать что-то вроде "вопроса"? и ответ!" или что-то столь же немое. Вы не можете спасти пользователей от своей глупости.
Рассмотрение этих вопросов безопасности, поскольку что-то фактически является двухфакторной аутентификацией, полностью вводит в заблуждение. Из поддельных статей, прочитанных ранее, когда определенные (банковские) сайты должны были иметь "двухфакторную аутентификацию", они начали применять это как дешевый способ сделать это. Брюс Шнайер говорил об этом [назад] [1].
Несколько факторов - это лучшие вещи, которые не являются одними и теми же. Это не должно быть все, что вы "знаете", но что-то знаете, и что-то у вас есть, и т.д. Это значит, что в игру вступают аппаратные маркеры аутентификации, смарт-карты и другие подобные устройства.
[1]: http://www.schneier.com/blog/archives/2005/03/the_failure_of.html Отказ двухфакторной аутентификации
когда он не является почтовой системой, напишите им ссылку на защищенную страницу с хешем, который должен вернуться в строку запроса к паролю reset.
Тогда, если кто-то попытался reset ваш пароль, вы бы знали, и они не смогли бы угадать хэш потенциально.
Мы используем две команды, умноженные вместе, представленные как hex.
Ну, для одного он не должен напрямую reset пароль, но отправить электронное письмо со ссылкой на пароль reset. Таким образом, она получила бы электронное письмо и узнала, что это не ее инициатива reset, и что ее вопрос/ответ был скомпрометирован.
В случае, если адрес электронной почты больше недействителен, он должен дождаться таймаута (несколько дней или недели), прежде чем разрешать прикрепление нового сообщения к учетной записи.
Отправьте сообщение на другую учетную запись электронной почты или напишите на своем мобильном телефоне или позвоните им или отправьте сообщение с уличной почтой. Все, что не связано с публичными отчетами или предпочтениями, которые могут измениться в любое время.
Хорошие вопросы безопасности являются неправильным. Они фактически создают уязвимость в системе. Мы должны называть их безопасными вопросами. Однако, признавая риск и ценность, которые они предоставляют, "хорошие" вопросы безопасности должны иметь 4 характеристики: 1. не может быть легко догадаться или исследоваться (безопасно), 2. не изменяется со временем (стабильно), 3. запоминается, 4. является окончательным или простым. Подробнее об этом можно узнать на http://www.goodsecurityquestions.com.
Вот список хорошие, честные и плохие вопросы безопасности.
Секретные вопросы ИМО должны использоваться только как очень слабый контроль с ограничением времени как частью системы. Пример: пароль reset.
Вы аутентифицированы. Зарегистрируйте свой номер мобильного телефона и ваш секретный (не столь секретный) ответ.
Вы забыли свой пароль.
Вы хотите разблокировать его.
a) Ваш "не такой секретный" вопрос задает вам "не такой секретный ответ". б) Если правильно, текстовое сообщение отправляется на предварительно зарегистрированный телефон.
Таким образом, если ваш телефон украден и также, элементы управления, такие как pin/lock на телефоне, не работают. У вас все еще будет мера обфускации для злоумышленника, чтобы добраться до reset пароля до тех пор, пока он не сообщит, что телефон потерян/украден и может быть отключен.
Это использование - это то, что я считаю единственной целью для "не столь секретных" вопросов/ответов.
Итак, я бы сказал, что для них есть место в этом мире, и что обычно должна быть дискуссия.
Задавайте только те вопросы, которые не относятся к общедоступной записи.
всегда отправлять пароль reset на зарегистрированную учетную запись электронной почты (что сложно для учетной записи электронной почты) или отправлять PIN-код на зарегистрированный мобильный телефон или ссылку на IM-адрес и т.д. - в основном, захватывать некоторые вторичные контактную информацию о регистрации и использовать ее для отправки ссылки "пароль reset".
Никогда не позволяйте никому менять свой пароль напрямую, всегда проверяйте, чтобы они прошли дополнительный шаг.
Как просить пользователей ввести свой собственный вопрос безопасности и ответ, а также вторичное электронное письмо (а не адрес, на который отправляется ссылка на пароль reset). Сохраните секретный вопрос и ответьте хэшированием в базе данных для этого дополнительного шага безопасности.
Если пользователь забудет свой пароль, отправьте пароль reset ссылку на адрес основного пользователя . Затем пользователь нажимает на ссылку, которая перенаправляет и запрашивает секретный вопрос и ответ. Если этот шаг будет успешным, тогда пользователь сможет reset ввести свой пароль. Если пользователь забудет секретный вопрос/ответ, отправьте ссылку на reset вопрос безопасности/ответ пользователю вторичному электронному письму.
Если злоумышленник получает доступ к одному из писем, он все равно будет бесполезен без доступа к другому (очень маловероятно, что злоумышленник может получить доступ к обоим). Я знаю, что этот процесс требует много дополнительной работы как для разработчиков, так и для пользователей, но я думаю, что это того стоит. (Возможно, мы могли бы предоставить пользователям рекомендованный вариант для активации защитного вопроса/ответа, если им нужен этот дополнительный бит безопасности.)
Суть в том, что сильная или слабая работа этой системы сильно зависит от пользователя. Сила защитного вопроса/ответа и то, насколько хорошо эти два письма "развязаны" (то есть нет способа получить доступ к одному электронному письму через другой), решит эту силовую систему.
Я не знаю, есть ли какие-либо проблемы с этим способом, но если они есть, я был бы рад, если бы кто-нибудь мог указать на них:)
Я предпочитаю держать вещи простыми и использовать системный подход чести. Например, я представлю пользователю что-то вроде
Это действительно вы? Выберите: Да или Нет.
Создайте хэш, содержащий имя пользователя и пароль пользователя и отправляйте его через Https пользователю в виде файла. Пользователь сохраняет файл на диск. Это их обязанность хранить этот файл в надежном месте. В качестве альтернативы вы можете отправить его на свой адрес электронной почты, но это приведет к снижению безопасности. Если пользователь забыл свои учетные данные, он должен загрузить этот файл. После того, как сервер проверит имя пользователя и пароль, им будет предложено изменить пароль.
Из-за эволюции социальных сетей вопросы безопасности, задаваемые веб-сайтами, слишком легко взломать. Поскольку большинство вопросов являются личной информацией, которая легко доступна на платформах социальных сетей. Одной из альтернатив, позволяющих избежать взлома учетной записи, является установление строгих правил для паролей при входе в систему, таких как добавление специальных символов, цифр, заглавных букв и т.д. Такие пароли сложно декодировать и могут значительно повысить безопасность. Но существуют новые альтернативные методы, такие как многофакторная аутентификация, вход без пароля, аутентификация через SMS и т.д. Аутентификация через SMS является частью многофакторной аутентификации, когда пользователю предоставляется OTP на его/ее мобильном телефоне, который он/она должен ввести для того, чтобы войти на сайт. Это безопасный способ, поскольку доступ к мобильному телефону ограничен только пользователем (в основном). Другой способ многофакторной аутентификации - отправка ссылки для подтверждения на электронную почту для завершения процесса входа. На этой теме есть очень хорошо написанный блог на Medium, который подробно объясняет эту концепцию.