Какая хорошая альтернатива контрольным вопросам?[закрыто]
https://stackoverflow.com/questions/104592
-
01-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
От Проводной Журнал:
... взлом Palin не требовал никаких реальных навыков.Вместо этого хакер просто сбросил пароль Пэйлин, используя ее дату рождения, почтовый индекс и информацию о том, где она познакомилась со своим супругом - секретный вопрос в ее аккаунте Yahoo , на который был дан ответ (Wasilla Высокий) с помощью простого поиска в Google.
Мы не можем доверять таким контрольные вопросы чтобы сбросить забытые пароли.
Как вы можете разработать более совершенную систему?
Решение
Внеполосная связь - это правильный путь.
Например, отправка временного пароля в виде SMS может быть приемлемой (в зависимости от системы).Я часто видел, как это реализовывалось в телекоммуникационных компаниях, где SMS - это дешево / бесплатно / часть бизнеса, а номер мобильного телефона пользователя предварительно зарегистрирован...
Банки часто требуют телефонного звонка на определенный номер, но лично я не слишком в восторге от этого....
И, конечно, в зависимости от системы, принуждение пользователя прийти в филиал для идентификации себя также может сработать (просто ужасно разозлить пользователя).
Суть в том, что НЕ создавайте более слабый канал, чтобы обойти требования к надежному паролю.
Другие советы
Ненадежность так называемых "вопросов безопасности" известна уже давно.Как Брюс Шнайер говорит об этом:
В результате обычный протокол безопасности (пароли) заменяется гораздо менее безопасным протоколом (секретные вопросы).И страдает безопасность всей системы.
Что можно сделать?Мой обычный прием заключается в том, чтобы набрать совершенно случайный ответ - я несколько секунд бешено стучу по клавиатуре - и затем забываю об этом.Это гарантирует, что какой-нибудь злоумышленник не сможет обойти мой пароль и попытаться угадать ответ на мой секретный вопрос, но будет довольно неприятно, если я забуду свой пароль.Единственный раз, когда это случилось со мной, мне пришлось позвонить в компанию, чтобы получить свой пароль и сбросить вопрос.(Честно говоря, я не помню, как я аутентифицировался у представителя службы поддержки клиентов на другом конце телефонной линии.)
Я думаю, что лучший метод - просто отправить электронное письмо со ссылкой, которую они могут использовать для генерации нового случайного пароля к учетной записи электронной почты, которую пользователь первоначально использовал для регистрации.Если они не запрашивали новый пароль, они могут просто проигнорировать его и продолжать использовать свой старый.Как отмечали другие, это не обязательно помогло бы Yahoo, поскольку они использовали службу электронной почты, но для большинства других служб электронная почта является достойной мерой аутентификации (по сути, вы перекладываете проблему аутентификации на поставщика электронной почты пользователя).
Конечно, вы могли бы просто использовать OpenID.
Увидев множество плакатов, предлагающих электронную почту, все, что я могу предложить, это НЕ НАДО используйте электронную почту в качестве своей линии защиты.
Скомпрометировать чью-либо учетную запись электронной почты может быть относительно легко.Множество веб-сервисов электронной почты НЕ НАДО также обеспечивают какую-либо реальную безопасность, и даже если они предлагают SSL, его часто нет По умолчанию и вы все еще полагаетесь на слабость Адрес электронной почты пароль для защиты пользователя (который, в свою очередь, большую часть времени имеет механизм сброса).
Электронная почта - одна из самых небезопасных технологий, и существуют хорошо причины, по которым отправлять через них такую информацию, как данные кредитной карты, действительно плохая идея.Обычно они передаются между серверами в виде открытого текста и, что не менее часто, между сервером и настольным клиентом в равной степени в незашифрованном виде, и все, что требуется, - это прослушивание, чтобы получить URL-адрес сброса и запустить его.(Не говорите, что я параноик, потому что банки используют SSL-шифрование для хорошо Причина.Как вы можете быть уверены, что 20-200 физических устройств на маршруте имеют благие намерения?)
Как только вы получите сброшенные данные, вы сможете сбросить пароль, а затем изменить свой (их) адрес электронной почты и получить постоянный контроль над их учетной записью (это происходит постоянно).
И если они получат вашу учетную запись электронной почты, все, что им нужно будет сделать, это просмотреть ваш почтовый ящик, чтобы найти, на кого вы подписаны, а затем легко сбросить пароль НА ВСЕХ НИХ
Таким образом, теперь использование системы безопасности на основе электронной почты может привести к пропогативный слабость системы безопасности!.Я уверен, что это полезно!.
Заданный вопрос, на мой взгляд, практически невозможно решить с помощью одного программного обеспечения.Вот почему у нас есть 2-факторная аутентификация с аппаратными ключами, которые реагируют на вызовы своей собственной уникальной подписью закрытого ключа, и только в том случае, если вы ее потеряете, вам крышка, и тогда вам придется иметь дело с человеком ( о, нет ), чтобы получить новый.
Это "зависит" от "системы".
Если вы являетесь банком или поставщиком кредитных карт, вы уже выпустили некоторый физический токен своему клиенту, который вы можете проверить на соответствие и многое другое.
Если вы являетесь сайтом электронной коммерции, вы запрашиваете информацию о некоторых недавних транзакциях - точные суммы, номер используемой кредитной карты и др..
Если вы похожи на Yahoo, я бы использовал автоматизированный подход, заключающийся в отправке кода активации посредством телефонного звонка или текстового сообщения на мобильный телефон вместе с некоторыми другими базовыми вопросами и ответами.
Джей
Попросите пользователя ввести 3 вопроса и ответа.Когда они запросят сброс настроек, предложите им выпадающий список из 5 вопросов, один из которых является случайным из 3, которые они ввели.Затем отправьте электронное письмо с подтверждением фактического сброса пароля.
Конечно, ничто не будет по-настоящему "защищено от хакеров".
Полностью устраните контрольные вопросы.Они представляют собой настолько очевидную брешь в системе безопасности, что я на самом деле немного удивлен, что им потребовалось так много времени, чтобы создать серьезный (ну, хорошо разрекламированный) инцидент.
Пока они не исчезнут, я просто буду продолжать рассказывать сайтам, которые их используют, что я ходил в среднюю школу "n4weu6vyeli4u5t"...
Когда задействованы пользователи (и, в основном, когда и нет), безопасность отсутствует;есть только иллюзия безопасности.Ты мало что можешь с этим поделать.У вас могли бы быть "менее распространенные" секретные вопросы, но даже они подвержены эксплуатации, поскольку некоторые люди выставляют все на всеобщее обозрение.
Вторичные каналы, такие как электронная почта, предлагают разумное решение проблемы.Если пользователь запросит сброс пароля, вы можете отправить ему по электронной почте токен для сброса пароля.Все еще не идеально, как говорили другие, но для использования этого потребуется, чтобы злоумышленник находился где-то в зоне прямой видимости между веб-сайтом, его MTA и MUA пользователей.Технически это просто, но я полагаю, что реальность такова, что для них слишком много работы / риска, чтобы беспокоиться о ком-либо, кроме очень известных личностей.
Требование от пользователя предоставлять открытые ключи SSL или GPG во время создания учетной записи окажет огромную помощь, но невежественные пользователи не будут знать, что это такое, не говоря уже о том, чтобы хранить свои закрытые ключи в безопасности и создавать резервные копии, чтобы не потерять их.
Просьба пользователя ввести второй аварийный пароль (что-то вроде PIN / PUK на SIM-картах мобильных телефонов) могла бы помочь, но, скорее всего, пользователь использовал бы один и тот же пароль дважды или забыл бы и второй пароль.
Короткий ответ, вы S.O.L., если только вы не хотите обучить своих пользователей безопасности, а затем вдалбливать им подсказки, пока они не поймут, что необходимо быть в безопасности, а небольшой объем дополнительной работы - это не просто заноза в заднице.
Проверка подлинности всего, отправляя электронные письма, является достаточно эффективным решением.(хотя, возможно, в данном случае это было бы невозможно для Yahoo :)).
Вместо того чтобы возиться с секретными вопросами или другими способами восстановления паролей, просто отвечайте на запросы на восстановление пароля, отправляя электронное письмо на заранее определенную учетную запись электронной почты со ссылкой для авторизации.Оттуда вы можете сменить пароли или что угодно еще, что вам нужно сделать (хотя никогда НЕ ОТПРАВЛЯЙТЕ пароль - вы все равно всегда должны хранить его как соленый хэш, всегда меняйте его.Затем, если учетная запись электронной почты была скомпрометирована, по крайней мере, у пользователя есть какое-то указание на то, что к его другим сервисам был получен доступ)
Истинный ответ заключается в том, что не существует надежного способа оградить себя от хакеров.Я ненавижу секретные вопросы, но если вы собираетесь их использовать, разрешите задавать пользовательские секретные вопросы.Как пользователю, если у меня должен быть секретный вопрос на сайте для создания учетной записи, мне действительно нравится иметь возможность настроить свой собственный секретный вопрос, позволяющий мне задавать вопросы, на которые только я знаю, как ответить.В данном случае это даже не обязательно должен быть реальный вопрос.Но тогда учетная запись пользователя так же безопасна, как и глупость пользователя, и тот факт, что многие пользователи будут использовать что-то вроде "вопрос?" и "ответ!" или что-то столь же глупое.Вы не можете спасти пользователей от их собственной глупости.
Отношение к этим секретным вопросам как к чему-то, что на самом деле является двухфакторной аутентификацией, полностью вводит в заблуждение.Из поддельных материалов, прочитанных ранее, когда от определенных сайтов (банков) требовалось иметь "двухфакторную аутентификацию", они начали внедрять это как дешево способ сделать это.Брюс Шнайер говорил об этом [некоторое время назад][1].
Множество факторов - это лучшие вещи, которые не совпадают.Это должно быть не все, что вы "знаете", а что-то, что вы знаете, что-то, что у вас есть, и т.д.Именно здесь в игру вступают аппаратные токены аутентификации, смарт-карты и другие подобные устройства.
[1]: http://www.schneier.com/blog/archives/2005/03/the_failure_of.html Сбой двухфакторной аутентификации
если это не система электронной почты, отправьте им по электронной почте ссылку на защищенную страницу с хэшем, который должен быть возвращен в строке запроса для сброса пароля.
Тогда, если бы кто-то попытался сбросить ваш пароль, вы бы знали, и они потенциально не смогли бы угадать хэш.
Мы используем 2 guid, умноженных вместе и представленных в виде шестнадцатеричного числа.
Ну, во-первых, он не должен напрямую сбрасывать пароль, а отправить электронное письмо со ссылкой для сброса пароля.Таким образом, она получила бы электронное письмо и знала, что не она инициировала перезагрузку и что ее вопрос / ответ был скомпрометирован.
В случае, когда адрес электронной почты больше не действителен, следует подождать тайм-аута (несколько дней или неделю ), прежде чем разрешить прикрепление нового электронного письма к учетной записи.
Отправьте сообщение на другую учетную запись электронной почты, или отправьте текстовое сообщение на их мобильный телефон, или позвоните им, или отправьте сообщение по электронной почте.Все, что не связано с публичными документами или предпочтениями, которые могут измениться в любое время.
Хорошие секретные вопросы - это неправильное название.Они фактически создают уязвимость в системе.Мы должны обращаться к ним с секретными вопросами.Однако, признавая риск и ценность, которые они обеспечивают, "хорошие" контрольные вопросы должны обладать 4 характеристиками:1.не может быть легко угадан или исследован (безопасно), 2.не меняется со временем (стабильный), 3.запоминающийся, 4.является окончательным или простым.Вы можете прочитать больше об этом по адресу http://www.goodsecurityquestions.com.
Вот список хорошие, справедливые и некачественные контрольные вопросы.
Секретные вопросы IMO следует использовать только в качестве очень слабого элемента управления с ограниченным временем как часть системы.Бывший:Система сброса пароля.
Вы прошли проверку подлинности.Зарегистрируйте номер своего мобильного телефона и свой секретный (не такой уж секретный) ответ.
Вы забыли свой пароль.
Вы запрашиваете разблокировать его.
а) Ваш "Не такой уж секретный" вопрос требует от вас "не такого уж секретного ответа".б) Если все правильно, текстовое сообщение отправляется на предварительно зарегистрированный телефон.
Таким образом, если ваш телефон будет украден, а также такие элементы управления, как pin-код / блокировка на телефоне, не будут работать.У вас по-прежнему будет определенная степень запутывания, с помощью которой злоумышленник сможет сбросить пароль до тех пор, пока не поступит сообщение о потере / краже телефона и его можно будет отключить.
Такое использование - это то, что я считаю единственной целью для "не таких уж секретных" вопросов / ответов.
Поэтому я бы сказал, что в этом мире есть место для них, и что обычно система нуждается в обсуждении.
Задавайте только те вопросы, которые не находятся в открытом доступе.
всегда отправляйте запрос на сброс пароля на зарегистрированную учетную запись электронной почты (что сложно для учетной записи электронной почты) или отправьте PIN-код на зарегистрированный мобильный телефон, или ссылку на адрес обмена мгновенными сообщениями и т.д. - В общем, запишите некоторую дополнительную контактную информацию при регистрации и используйте ее для отправки ссылки "сброс пароля".
Никогда не позволяйте никому менять свой пароль напрямую, всегда следите за тем, чтобы они выполнили дополнительный шаг.
Как насчет того, чтобы попросить пользователей ввести свой собственный секретный вопрос и ответ, а также дополнительное электронное письмо (не то, куда отправляется ссылка для сброса пароля).Сохраните секретный вопрос и хэшированный ответ в базе данных для этого дополнительного шага безопасности.
Если пользователь забудет свой пароль, отправьте ссылка для сброса пароля на имя пользователя основной адрес электронной почты.Затем пользователь нажимает на ссылку, которая перенаправляет, и запрашивает контрольный вопрос и ответ.Если этот шаг пройдет успешно, разрешите пользователю сбросить свой пароль.Если пользователь забудет секретный вопрос / ответ, отправьте ссылку на сбросьте контрольный вопрос / ответ на имя пользователя вторичный адрес электронной почты.
Если злоумышленник получит доступ к одному из электронных писем, оно все равно будет бесполезно без доступа к другому (очень маловероятно, что злоумышленник сможет получить доступ к обоим).Я знаю, что этот процесс требует большой дополнительной работы как со стороны разработчиков, так и со стороны пользователей, но я думаю, оно того стоит.(Возможно, мы могли бы предоставить пользователям рекомендуемую опцию для активации секретного вопроса / ответа, если им нужна эта дополнительная защита.)
Суть в том, что то, насколько сильно или слабо работает эта система, будет в значительной степени зависеть от пользователя.Надежность контрольного вопроса / ответа и то, насколько хорошо два электронных письма "развязаны" (то есть нет способа получить доступ к одному электронному письму через другое), будут определять надежность этой системы.
Я не знаю, есть ли какие-либо проблемы с этим способом выполнения, но если таковые имеются, я был бы рад, если бы кто-нибудь мог указать на них :)
Я предпочитаю, чтобы все было просто, и использую системный подход.Например, я представлю пользователю что-то вроде,
Это действительно ты? Выберите:Да или Нет.
Сгенерируйте хэш, содержащий имя пользователя и пароль пользователя, и отправьте его по протоколу Https пользователю в виде файла.Пользователь сохраняет файл на диск.Они несут ответственность за хранение этого файла в безопасном месте.В качестве альтернативы вы можете отправить его на их адрес электронной почты, но это приведет к снижению безопасности.Если пользователь забудет свои учетные данные для входа, он должен затем загрузить этот файл.Как только сервер подтвердит имя пользователя и пароль, им будет предложено изменить свой пароль.
Из-за развития социальных сетей контрольные вопросы, задаваемые веб-сайтами, слишком легко взломать.Поскольку большинство вопросов - это личная информация, которая легко доступна на тех или иных платформах социальных сетей.Одна из альтернатив избежать взлома учетной записи - ввести строгие правила ввода пароля для входа в систему, например, добавить специальные символы, цифры, заглавные буквы и т.д.Такого рода пароли трудно расшифровать, и они могут в значительной степени повысить безопасность.Но существуют новые альтернативные методы, такие как многофакторная аутентификация, вход без пароля, SMS-аутентификация и т.д.SMS-аутентификация - это часть многофакторной аутентификации, при которой пользователю предоставляется OTP на его / ее мобильном телефоне, который ему / ей необходимо ввести, чтобы войти на веб-сайт.Это безопасный способ, поскольку доступ к мобильному устройству ограничен только пользователем (в основном).Другим методом многофакторной аутентификации является отправка подтверждающей ссылки на электронную почту для завершения процесса входа в систему.На эту тему есть очень хорошо написанный блог на Средний это подробно объясняет эту концепцию.
