Вопрос: Окончательное руководство по аутентификации веб-сайта на основе форм [закрыто]


Аутентификация на основе форм для веб-сайтов

Мы полагаем, что переполнение стека должно быть не просто ресурсом по очень конкретным техническим вопросам, но и для общих рекомендаций по решению вариантов общих проблем. «Проверка подлинности на основе форм для веб-сайтов» должна стать хорошей темой для такого эксперимента.

Он должен включать такие темы, как:

  • Как войти в систему
  • Как выйти из системы
  • Как оставаться в системе
  • Управление файлами cookie (включая рекомендуемые настройки)
  • Шифрование SSL / HTTPS
  • Как хранить пароли
  • Использование секретных вопросов
  • Забыли имя пользователя / пароль
  • Использование одноразовые предотвращать кросс-сайт подделок (CSRF)
  • OpenID
  • «Запомнить меня»
  • Автозаполнение браузером имен пользователей и паролей
  • Секретные URL (общедоступные URL защищенный дайджестом)
  • Проверка силы пароля
  • Проверка электронной почты
  • и многое другое о проверка подлинности на основе форм ...

Он не должен включать такие вещи, как:

  • Роли и авторизация
  • Базовая аутентификация HTTP

Пожалуйста, помогите нам:

  1. Предложить подтемы
  2. Предоставление хороших статей об этой теме
  3. Редактирование официального ответа

4960


источник


Ответы:


ЧАСТЬ I: Как войти

Предположим, вы уже знаете, как создать форму HTML для входа + пароля, которая отправляет значения сценарию на стороне сервера для аутентификации. В нижеприведенных разделах будут рассмотрены шаблоны для практического практического использования и как избежать наиболее распространенных ошибок безопасности.

К HTTPS или не к HTTPS?

Если соединение уже безопасно (т. Е. Туннелировано через HTTPS с использованием SSL / TLS), ваши значения формы входа будут отправляться в виде открытого текста, что позволяет любому, кто перехватывает строку между браузером и веб-сервером, сможет читать логины по мере их прохождения через. Этот тип прослушивания регулярно выполняется правительствами, но в целом мы не будем рассматривать «принадлежащие» провода, кроме как сказать это: если вы защищаете что-либо важное, используйте HTTPS.

По сути, единственное практическое способ защиты от прослушивания / пакетного обнюхивания во время входа в систему с использованием HTTPS или другой схемы шифрования на основе сертификатов (например, TLS ) или проверенную и проверенную схему ответа на вызов (например, Диффи-Хеллмана основанный на SRP). Любой другой метод можно легко обойти злоумышленником.

Конечно, если вы хотите немного непрактично, вы также можете использовать схему двухфакторной аутентификации (например, приложение Google Authenticator, физическую кодовую книгу типа «холодная война» или ключ ключа генератора RSA). При правильном применении это может работать даже с незащищенным соединением, но трудно представить, что разработчик захочет реализовать двухфакторное аутентификацию, а не SSL.

(Do not) Roll-your-own JavaScript-шифрование / хеширование

Учитывая ненужную стоимость и воспринимаемую техническую трудность при настройке SSL-сертификата на вашем веб-сайте, некоторые разработчики склонны откатывать свои собственные схемы хэширования или шифрования в браузере, чтобы избежать пропусков логических подключений через незащищенный провод.

Хотя это благородная мысль, она по существу бесполезна (и может быть недостаток безопасности ), если он не сочетается с одним из вышеперечисленных - то есть, либо защищая линию сильным шифрованием, либо используя проверенный механизм проверки ответа (если вы не знаете, что это такое, просто знайте, что это один из которых сложнее всего доказать, наиболее сложно спроектировать и наиболее сложно реализовать концепции цифровой безопасности).

Хотя верно, что хеширование пароля возможно эффективный против раскрытие пароля , он уязвим для повторных атак, нападений / захватов Man-In-The-Middle (если злоумышленник может ввести несколько байтов на вашу незащищенную HTML-страницу до того, как он достигнет вашего браузера, они могут просто прокомментировать хеширование в JavaScript), или атаки грубой силы (поскольку вы передаете злоумышленнику имя пользователя, соль и хешированный пароль).

CAPTCHAS против человечества

CAPTCHAs предназначены для того, чтобы помешать одной конкретной категории атаки: автоматическая пробная версия с ошибкой словаря / грубой силы без оператора. Нет никаких сомнений в том, что это реальная угроза, однако есть способы беспрепятственно справляться с этим, не требуя CAPTCHA, специально разработанных схем управления доступом к серверным сайтам - мы обсудим их позже.

Знайте, что реализации CAPTCHA не созданы одинаково; они часто не разрешаются людьми, большинство из них фактически неэффективны против ботов, все они неэффективны против дешевого труда третьего мира (согласно OWASP , текущая ставка потов составляет 12 долларов США за 500 тестов), а некоторые реализации могут быть технически незаконными в некоторых странах (см. Аутентификация OWASP Cheat Sheet ). Если вы должны использовать CAPTCHA, используйте Google рекапчи , поскольку по определению он является OCR-hard (поскольку он использует уже OCR-неправильно классифицированные сканирование книг) и очень сложно быть удобным для пользователя.

Лично я склоняюсь к тому, что CAPTCHAS раздражает и использует их только в качестве последнего средства, когда пользователь несколько раз не входил в систему, а задержки срабатывания макс. Это будет достаточно редко, чтобы быть приемлемым, и это укрепляет систему в целом.

Хранение паролей / проверка логинов

Это может быть, наконец, общеизвестным после всех широко распространенных хаков и утечек пользовательских данных, которые мы видели в последние годы, но нужно сказать: не храните пароли в открытом виде в своей базе данных. Пользовательские базы данных рутинно взломаны, просочились или почерпнули с помощью SQL-инъекции, а если вы храните сырые пароли открытого текста, это мгновенная игра для вашей безопасности входа.

Поэтому, если вы не можете сохранить пароль, как вы проверяете правильность комбинации паролей входа и пароля POSTed из формы входа? Ответ - хеширование с использованием функция деривации ключа , Всякий раз, когда создается новый пользователь или изменяется пароль, вы берете пароль и запускаете его через KDF, например, Argon2, bcrypt, scrypt или PBKDF2, превращая пароль cleartext («correcthorsebatterystaple») в длинную строку в случайном порядке , что намного безопаснее хранить в вашей базе данных. Чтобы проверить логин, вы запускаете ту же функцию хеша на введенном пароле, на этот раз передавая соль и сравнивая полученную строку хеша с значением, хранящимся в вашей базе данных. Argon2, bcrypt и scrypt уже хранят соль с хешем. Проверьте это статья на sec.stackexchange для получения более подробной информации.

Причина использования соли заключается в том, что хеширование само по себе недостаточно - вы захотите добавить так называемую соль, чтобы защитить хэш от радужные столы , Соль эффективно предотвращает два пароли, которые точно соответствуют тому, что они хранятся как одно и то же значение хэш-функции, что предотвращает сканирование всей базы данных за один проход, если злоумышленник выполняет атаку с угадыванием пароля.

Криптографический хеш нельзя использовать для хранения паролей, поскольку пользовательские пароли недостаточно сильны (т. Е. Обычно не содержат достаточно энтропии), и атака с угадыванием пароля может быть завершена в течение относительно короткого времени злоумышленником с доступом к хэшам. Вот почему используется KDF - это эффективно «растянуть ключ» это означает, что каждый пароль, предполагающий, что атакующий делает, включает в себя повторение алгоритма хеширования несколько раз, например, 10 000 раз, что делает пароль злоумышленника более 10 000 раз медленнее.

Данные сеанса - «Вы вошли как Spiderman69»

Как только сервер проверит логин и пароль в вашей базе данных пользователей и найдет соответствие, системе необходимо запомнить, что браузер прошел аутентификацию. Этот факт должен храниться только на стороне сервера в данных сеанса.

Если вы не знакомы с данными сеанса, вот как это работает: единая произвольно сгенерированная строка хранится в истечении срока действия cookie и используется для ссылки на набор данных - данные сеанса, которые хранятся на сервере. Если вы используете структуру MVC, это, без сомнения, уже обрабатывается.

Если это вообще возможно, убедитесь, что cookie сеанса имеет безопасные и только HTTP-флаги, установленные при отправке в браузер. Флаг httponly обеспечивает некоторую защиту от того, что cookie читается атакой XSS. Безопасный флаг гарантирует, что cookie отправляется только через HTTPS, и, следовательно, защищает от сетевых обнюхивающих атак. Значение cookie не должно быть предсказуемым. Если представлен файл cookie, ссылающийся на несуществующий сеанс, его значение следует немедленно заменить, чтобы предотвратить фиксация сеанса ,

ЧАСТЬ II: Как Остаться Записанным - Позорный «Помни меня» Флажок

Постоянная регистрация файлов cookie («запомнить меня») - опасная зона; с одной стороны, они полностью безопасны, как обычные логины, когда пользователи понимают, как их обрабатывать; и, с другой стороны, они представляют собой огромный риск для безопасности в руках небрежных пользователей, которые могут использовать их на общедоступных компьютерах и забывать выйти из системы, а также могут не знать, какие файлы cookie браузера и как их удалить.

Лично мне нравятся постоянные логины для веб-сайтов, которые я посещаю регулярно, но я знаю, как их безопасно обрабатывать. Если вы уверены, что ваши пользователи знают то же самое, вы можете использовать постоянные логины с чистой совестью. Если нет - хорошо, тогда вы можете подписаться на философию, согласно которой пользователи, которые небрежно относятся к своим учетным данным, принесли на себя, если они будут взломаны. Это не то, что мы идем к домам наших пользователей и отрываем все эти заметки Post-It, вызывающие facepalm, с паролями, которые они выстроили на краю своих мониторов.

Конечно, некоторые системы не могут позволить себе Любые взломанные счета; для таких систем вы не можете оправдать наличие постоянных логинов.

Если вы решите внедрить постоянные файлы cookie для входа в систему, вот как вы это делаете:

  1. Во-первых, найдите время, чтобы прочитать Инициатива Paragon Initiative на предмет. Вам нужно будет получить кучу элементов правильно, и статья прекрасно справляется с каждой из них.

  2. И просто повторить одну из самых распространенных ловушек, НЕ ЗАПУСКАЙТЕ СТОЙНУЮ ЛОКАЛЬНУЮ ПОВЕРХНОСТЬ (ТОКЕН) В ВАШЕЙ БАЗЕ ДАННЫХ, ТОЛЬКО ХАШ ЭТО! Маркер входа - это эквивалент паролей, поэтому, если злоумышленник получил доступ к вашей базе данных, они могут использовать токены для входа в любую учетную запись, точно так же, как если бы они были комбинациями паролей и паролей cleartext. Поэтому используйте хеширование (согласно https://security.stackexchange.com/a/63438/5002 слабый хеш будет отлично подходит для этой цели) при сохранении постоянных токенов входа.

ЧАСТЬ III: Использование секретных вопросов

Не выполняйте «секретные вопросы» , Функция секретных вопросов - это анти-шаблон безопасности. Прочитайте документ из номера ссылки 4 из списка MUST-READ. Вы можете спросить у Сары Пэйлин об этом, после ее Yahoo! электронная почта была взломана во время предыдущей президентской кампании, потому что ответ на ее вопрос безопасности был ... «Высшая школа Wasilla»!

Даже с заданными пользователем вопросами очень вероятно, что большинство пользователей выберут:

  • «Стандартный» секретный вопрос, как девичья фамилия матери или любимое домашнее животное

  • Простая мелочь, которую любой мог снять со своего блога, профиль LinkedIn или аналогичный

  • Любой вопрос, который легче ответить, чем угадать их пароль. Который для любого достойного пароля - это каждый вопрос, который вы можете себе представить

В заключение, вопросы безопасности по своей сути небезопасны практически во всех их формах и вариантах и ​​не должны использоваться по схеме аутентификации по какой-либо причине.

Истинная причина, по которой вопросы безопасности даже существуют в дикой природе, заключается в том, что они экономят затраты на несколько вызовов поддержки от пользователей, которые не могут получить доступ к их электронной почте, чтобы получить код реактивации. Это за счет безопасности и репутации Сары Пэйлин. Стоило того? Возможно нет.

ЧАСТЬ IV: Функциональность забытых паролей

Я уже говорил, почему вы должны никогда не используйте вопросы безопасности для обработки забытых / потерянных паролей пользователей; также само собой разумеется, что вы никогда не должны отправлять пользователям по электронной почте свои фактические пароли. В этой области есть, по крайней мере, еще две слишком распространенные ошибки:

  1. не сброс забытый пароль для автогенерированного надежного пароля - такие пароли, как известно, трудно запомнить, а это означает, что пользователь должен либо изменить его, либо записать его - скажем, на ярко-желтый пост-он на краю монитора. Вместо того, чтобы устанавливать новый пароль, просто дайте пользователям сразу выбрать новый, что и в любом случае.

  2. Всегда хэш-код потерянного пароля / токена в базе данных. ЕЩЕ РАЗ , этот код является еще одним примером эквивалента пароля, поэтому он ДОЛЖЕН быть хэширован, если злоумышленник получил доступ к вашей базе данных. Когда запрашивается код с потерянным паролем, отправьте код открытого текста на адрес электронной почты пользователя, затем выберите его, сохраните хэш в своей базе данных - и выбросить оригинал , Также как пароль или постоянный токен входа.

Последнее замечание: всегда убедитесь, что ваш интерфейс для ввода кода «потерянного пароля» не менее безопасен, чем ваша форма входа, или злоумышленник просто использует это, чтобы получить доступ. Удостоверившись, что вы создаете очень длинные «коды паролей» (например, 16 буквенно-цифровых символов, чувствительных к регистру), это хороший старт, но подумайте над тем, чтобы добавить ту же схему дросселирования, что и для самой формы входа.

ЧАСТЬ V: Проверка силы пароля

Во-первых, вы захотите прочитать эту небольшую статью для проверки реальности: 500 наиболее распространенных паролей

Хорошо, так что, возможно, список не канонический список наиболее распространенных паролей Любые система где угодно , но это хороший показатель того, насколько плохо люди будут выбирать свои пароли, если не будет примененной политики. Кроме того, список выглядит пугающе близким к дому, когда вы сравниваете его с общедоступными анализами недавно похищенных паролей.

Итак: без минимальных требований к надежности пароля 2% пользователей используют один из 20 наиболее распространенных паролей. Значение: если злоумышленник получает всего 20 попыток, 1 из 50 учетных записей на вашем сайте будет взломан.

Для этого необходимо вычислить энтропию пароля и затем применить порог. Национальный институт стандартов и технологий (NIST) Специальная публикация 800-63 имеет множество очень хороших предложений. Это, в сочетании с анализом макета словаря и клавиатуры (например, «qwertyuiop» - это плохой пароль), может отклонить 99% всех слабо отобранных паролей на уровне 18 бит энтропии. Простое вычисление силы пароля и показывающий визуальный измеритель силы для пользователя это хорошо, но недостаточно. Если это не будет соблюдено, многие пользователи, скорее всего, не обратят на него внимания.

И для освежающего подхода к удобству использования энтропийных паролей, Рэндалл Мунро Сила пароля xkcd настоятельно рекомендуется.

ЧАСТЬ VI: Гораздо больше - или: Предотвращение попыток входа в систему быстрого доступа

Во-первых, посмотрите на цифры: Скорость восстановления пароля - как долго ваш пароль будет стоять

Если у вас нет времени, чтобы просмотреть таблицы в этой ссылке, вот список из них:

  1. Занимает практически нет времени взломать слабый пароль, даже если вы взламываете его счетом

  2. Занимает практически нет времени взломать буквенно-цифровой 9-значный пароль, если он без учета регистра

  3. Занимает практически нет времени взломать запутанные, символы и буквы и цифры, пароль верхнего и нижнего регистра, если он менее 8 символов (настольный ПК может выполнять поиск всего пространства ключей до 7 символов в течение нескольких дней или даже часов)

  4. Однако потребовалось бы слишком много времени для взлома даже 6-символьного пароля, если вы были ограничены одной попыткой в ​​секунду!

Итак, что мы можем узнать из этих чисел? Ну, много, но мы можем сосредоточиться на самой важной части: тот факт, что предотвращение большого числа быстрых попыток входа в систему с быстрым огнем (т. Е. грубая сила атака) действительно не так сложно. Но предотвращение этого правильно не так просто, как кажется.

Вообще говоря, у вас есть три варианта, которые эффективны против нападений грубой силы (и словарных атак, но поскольку вы уже применяете сильную политику паролей, они не должны быть проблемой) :

  • Представить CAPTCHA, после неудачных попыток N (раздражает, как ад и часто неэффективно, но я повторяюсь здесь)

  • Блокировка учетных записей и требуя проверки по электронной почте после неудачных попыток N (это DoS атака ждет, чтобы произойти)

  • И наконец, регулирование входа в систему : то есть установить временную задержку между попытками после неудачных попыток N (да, атаки DoS все еще возможны, но по крайней мере они гораздо менее вероятны и намного сложнее снять).

Лучшая практика №1: Небольшая временная задержка, которая увеличивается с количеством неудачных попыток, например:

  • 1 неудачная попытка = без задержки
  • 2 неудачных попытки = 2 с задержки
  • 3 неудачных попытки = 4 с задержка
  • 4 неудачных попытки = задержка 8 сек.
  • 5 неудачных попыток = задержка 16 с
  • и т.п.

DoS, атакующий эту схему, будет очень непрактичным, так как полученное время блокировки немного больше суммы предыдущих периодов блокировки.

Чтобы уточнить: Задержка не задержка перед возвратом ответа на браузер. Это больше похоже на тайм-аут или рефрактерный период, в течение которого попытки входа в систему с определенной учетной записью или с определенного IP-адреса вообще не принимаются или не оцениваются. То есть правильные учетные данные не вернутся в успешный вход в систему, а неправильные учетные данные не вызовут увеличения задержки.

Лучшая практика № 2: Временная задержка средней длины, которая вступает в силу после неудачных попыток N, таких как:

  • 1-4 неудачных попытки = без задержки
  • 5 неудачных попыток = 15-30 минут задержки

DoS, атакующий эту схему, будет весьма непрактичным, но, безусловно, выполнимым. Кроме того, может быть уместно отметить, что такая длительная задержка может быть очень раздражающей для законного пользователя. Забывающие пользователи вам не нравятся.

Лучшая практика № 3: Сочетание двух подходов - либо фиксированной, короткой временной задержки, которая вступает в силу после неудачных попыток N, таких как:

  • 1-4 неудачных попытки = без задержки
  • 5+ неудачных попыток = задержка 20 секунд

Или увеличение задержки с фиксированной верхней границей, например:

  • 1 неудачная попытка = 5 секунд задержки
  • 2 неудачных попытки = 15 секунд задержки
  • 3+ неудачные попытки = 45 секунд задержки

Эта окончательная схема была взята из предложений наилучшей практики OWASP (ссылка 1 из списка MUST-READ) и должна считаться лучшей практикой, даже если она, по общему признанию, является ограничивающей стороной.

Однако, как правило, я бы сказал: чем сильнее ваша политика в отношении паролей, тем меньше приходится беспокоить пользователей с задержками. Если вам требуются сильные буквенные символы с буквенным алфавитом + требуемые номера и символы, более 9 символьных паролей, вы можете дать пользователям 2-4 попытки с задержкой пароля до активации дросселирования.

DoS, атакующий эту окончательную схему регулирования входа, будет очень непрактично. И как последний штрих, всегда разрешайте постоянным (cookie) входам (и / или подтвержденной CAPTCHA форме входа), поэтому законные пользователи даже не задерживаются пока атака продолжается , Таким образом, очень непрактичная DoS-атака становится очень непрактичная атака.

Кроме того, имеет смысл делать более агрессивное дросселирование учетных записей администратора, поскольку это наиболее привлекательные точки входа

ЧАСТЬ VII: Распространенные атаки на грубые силы

Так же, как и в стороне, более продвинутые злоумышленники будут пытаться обойти регулирование входа в систему путем «расширения своей деятельности»:

  • Распространение попыток на ботнете для предотвращения помех IP-адреса

  • Вместо того, чтобы выбирать одного пользователя и пытаться использовать 50 000 наиболее распространенных паролей (которые они не могут, из-за нашего дросселирования), они выберут самый общий пароль и попробуют его вместо 50.000 пользователей. Таким образом, они не только преодолевают максимальные попытки, такие как CAPTCHA и дросселирование входа, их шансы на успех также возрастают, так как наиболее распространенный пароль номер 1 гораздо более вероятен, чем номер 49.995

  • Размешивая запросы на вход для каждой учетной записи пользователя, скажем, на расстоянии 30 секунд, чтобы подкрасться под радаром

Здесь наилучшей практикой будет протоколирование количества неудавшихся логинов, общесистемных , и используя среднее значение частоты неудачного входа вашего сайта в качестве основы для верхнего предела, который вы затем накладываете на всех пользователей.

Слишком абстрактно? Позвольте мне перефразировать:

Скажем, за последние 3 месяца на вашем сайте было в среднем 120 плохих логинов в день. Используя это (среднее значение), ваша система может установить глобальный предел в 3 раза - т.е. 360 неудачных попыток в течение 24-часового периода. Затем, если общее количество неудачных попыток на всех учетных записях превышает этот номер за один день (или даже лучше, следить за скоростью ускорения и триггером на расчетном пороге), он активирует системное регулирование входа в систему - это означает короткие задержки для всех пользователей (все же, за исключением файлов cookie и / или резервного копирования CAPTCHA).

Я также разместил вопрос с более подробная информация и действительно хорошее обсуждение того, как избежать сложных ошибок в борьбе с распределенными грубыми атаками

ЧАСТЬ VIII. Двухфакторная аутентификация и аутентификация.

Учетные данные могут быть скомпрометированы, будь то эксплойты, пароли, записываемые и потерянные, ноутбуки с краденными ключами или пользователи, вводящие логины в фишинг-сайты. Логины могут быть дополнительно защищены двухфакторной аутентификацией, в которой используются внешние коэффициенты, такие как одноразовые коды, полученные от телефонного звонка, SMS-сообщения, приложения или ключа. Несколько провайдеров предлагают двухфакторные службы аутентификации.

Аутентификация может быть полностью делегирована службе единого входа, где другой поставщик обрабатывает учетные данные. Это подталкивает проблему к доверенной третьей стороне. Google и Twitter предоставляют сервисы единого входа на основе стандартов, в то время как Facebook предоставляет аналогичное проприетарное решение.

ДОЛЖЕН ПРОЧИТАТЬ ССЫЛКИ О веб-аутентификации

  1. Руководство OWASP для аутентификации / Аутентификация OWASP Cheat Sheet
  2. Dos и Don'ts проверки подлинности клиента в Интернете (очень читаемый исследовательский документ MIT)
  3. Википедия: HTTP cookie
  4. Вопросы личного знания для проверки подлинности: вопросы безопасности в эпоху Facebook (очень читаемая исследовательская работа в Беркли)

3473



Определенный артикль

Отправка учетных данных

Единственный практичный способ безопасного доступа к учетным данным на 100% - это использовать SSL , Использование JavaScript для хеширования пароля небезопасно. Общие ошибки для хэширования пароля на стороне клиента:

  • Если соединение между клиентом и сервером не зашифровано, все, что вы делаете, это уязвимы для нападений «человек-в-середине» , Злоумышленник может заменить входящий javascript, чтобы разорвать хэширование или отправить все учетные данные на свой сервер, они могут прослушивать ответы клиентов и отлично олицетворять пользователей и т. Д. И т. Д. SSL с доверенными полномочными органами сертификации предназначен для предотвращения атак MitM.
  • Хешированный пароль, полученный сервером, менее безопасный если вы не делаете дополнительной, избыточной работы на сервере.

Существует еще один безопасный метод, называемый SRP , но он запатентован (хотя это свободно лицензированный ), и имеется мало хороших реализаций.

Хранение паролей

Никогда не храните пароли в виде открытого текста в базе данных. Даже если вы не заботитесь о безопасности своего сайта. Предположим, что некоторые из ваших пользователей повторно используют пароль своего банковского счета в Интернете. Итак, сохраните хешированный пароль и выбросьте оригинал. И убедитесь, что пароль не отображается в журналах доступа или журналах приложений. OWASP рекомендует использовать Argon2 как ваш первый выбор для новых приложений. Если это не доступно, вместо этого следует использовать PBKDF2 или scrypt. И, наконец, если ни одно из перечисленных выше не доступно, используйте bcrypt.

Хеши сами по себе также небезопасны. Например, идентичные пароли означают одинаковые хэши - это делает таблицы поиска хэша эффективным способом взломать много паролей одновременно. Вместо этого сохраните соленый хэш. Соль - это строка, прикрепленная к паролю до хэширования - используйте различную (случайную) соль для каждого пользователя. Соль является общедоступной, поэтому вы можете хранить их с хешем в базе данных. Видеть Вот для получения дополнительной информации об этом.

Это означает, что вы не можете отправить пользователю свои забытые пароли (потому что у вас есть только хэш). Не переустанавливайте пароль пользователя, если вы не прошли аутентификацию пользователя (пользователи должны подтвердить, что они могут читать электронные письма, отправленные на сохраненный (и проверенный) адрес электронной почты.)

Вопросы безопасности

Вопросы безопасности небезопасны - избегайте их использования. Зачем? Все, что делает секретный вопрос, пароль делает лучше. Читать ЧАСТЬ III: Использование секретных вопросов в @Jens Roland ответить здесь в этой вики.

Файлы сеансов

После входа пользователя в систему сервер отправляет пользователю файл cookie сеанса. Сервер может извлекать имя пользователя или идентификатор из файла cookie, но никто другой не может создать такой файл cookie (механизмы объяснения TODO).

Печенье может быть захвачено : они настолько же безопасны, как и остальные машины клиента и другие коммуникации. Их можно читать с диска, обнюхивать в сетевом трафике, снимать с помощью межсайтового скриптинга, вычищать из отравленного DNS, чтобы клиент отправил свои файлы cookie на неправильные серверы. Не отправляйте постоянные файлы cookie. Куки-файлы должны заканчиваться в конце сеанса клиента (браузер закрывается или покидает ваш домен).

Если вы хотите автологизировать своих пользователей, вы можете установить постоянный файл cookie, но он должен отличаться от cookie с полной сессией. Вы можете установить дополнительный флаг, который пользователь выполнил автозагрузку, и ему необходимо войти в систему для реальных операций. Это популярно у торговых центров, которые хотят предоставить вам беспрепятственный, персонализированный опыт покупок, но по-прежнему защищают ваши финансовые данные. Например, когда вы возвращаетесь, чтобы посетить Amazon, они показывают вам страницу, похожую на то, что вы вошли в систему, но когда вы идете разместить заказ (или изменить свой адрес доставки, кредитную карту и т. Д.), Они просят вас подтвердить ваш пароль.

С другой стороны, финансовые веб-сайты, такие как банки и кредитные карты, имеют только конфиденциальные данные и не должны допускать автоматический вход в систему или режим низкой безопасности.

Список внешних ресурсов


384



Во-первых, сильное предостережение, что этот ответ не подходит для этого точного вопроса. Это определенно не лучший ответ!

Я расскажу о предлагаемых Mozilla BrowserID (или, точнее, Проверенный протокол электронной почты ) в духе поиска пути обновления к лучшим подходам к аутентификации в будущем.

Я обобщу это так:

  1. Mozilla является некоммерческой организацией с значения которые хорошо согласуются с поиском хороших решений этой проблемы.
  2. Сегодня реальность заключается в том, что большинство веб-сайтов используют аутентификацию на основе форм
  3. Аутентификация на основе форм имеет большой недостаток, что увеличивает риск фишинга , Пользователям предлагается ввести конфиденциальную информацию в область, контролируемую удаленным объектом, а не область, контролируемая их User Agent (браузером).
  4. Поскольку браузеры неявно доверяют (вся идея User Agent заключается в том, чтобы действовать от имени Пользователя), они могут помочь улучшить эту ситуацию.
  5. Первичная сила, удерживающая прогресс здесь, разблокировка развертывания , Решения должны быть разложены на этапы, которые обеспечивают некоторую дополнительную выгоду сами по себе.
  6. Самый простой децентрализованный метод выражения личности, встроенный в интернет-инфраструктуру, - это доменное имя.
  7. В качестве второго уровня выражения личности каждый домен управляет собственным набором учетных записей.
  8. Форма «account» @домен "является кратким и поддерживается широким спектром протоколов и схем URI. Такой идентификатор, конечно же, наиболее универсально распознан как адрес электронной почты.
  9. Поставщики электронной почты уже являются фактическими поставщиками первичной идентификации онлайн. Текущие потоки сброса пароля обычно позволяют вам контролировать учетную запись, если вы можете подтвердить, что вы управляете связанным с ней адресом электронной почты.
  10. Протокол Verified Email Protocol был предложен для предоставления защищенного метода на основе криптографии с открытым ключом для оптимизации процесса проверки домена B, что у вас есть учетная запись в домене A.
  11. Для браузеров, которые не поддерживают проверенный протокол электронной почты (в настоящее время все они), Mozilla предоставляет прокладку, которая реализует протокол в клиентском коде JavaScript.
  12. Для почтовых служб, которые не поддерживают протокол проверенной электронной почты, протокол позволяет третьим сторонам выступать в качестве доверенного посредника, утверждая, что они подтвердили право собственности пользователя на учетную запись. Нежелательно иметь большое количество таких третьих сторон; эта возможность предназначена только для того, чтобы разрешить путь обновления, и очень предпочтительно, чтобы службы электронной почты сами предоставляли эти утверждения.
  13. Mozilla предлагает свою собственную услугу, чтобы выступать в качестве доверенной третьей стороны. Поставщики услуг (т. Е. Доверяющие стороны), реализующие протокол проверенного протокола электронной почты, могут предпочесть доверять утверждениям Mozilla или нет. Служба Mozilla проверяет право собственности на пользователя, используя обычные способы отправки электронной почты с помощью ссылки подтверждения.
  14. Поставщики услуг могут, конечно, предлагать этот протокол в качестве опции в дополнение к любым другим способам аутентификации, которые они могут предложить.
  15. Большим преимуществом пользовательского интерфейса здесь является «селектор идентичности». Когда пользователь посещает сайт и выбирает аутентификацию, их браузер показывает им список адресов электронной почты («личные», «работа», «политическая активность» и т. Д.), Которые они могут использовать для идентификации себя на сайте.
  16. Еще одним большим преимуществом пользовательского интерфейса, которое требуется в рамках этих усилий, является помогая браузеру узнать больше о сеансе пользователя - кто они вошли, как в настоящее время, в первую очередь - поэтому он может отображать это в браузере хром.
  17. Из-за распределенной природы этой системы она позволяет избежать блокировки на таких крупных сайтах, как Facebook, Twitter, Google и т. Д. Любой человек может владеть собственным доменом и, следовательно, выступать в качестве своего собственного поставщика удостоверений.

Это не строго «проверка подлинности на основе форм для веб-сайтов». Но это попытка перейти от текущей нормы аутентификации на основе форм к чему-то более безопасному: аутентификация, поддерживаемая браузером.


146



Я просто подумал, что поделюсь этим решением, которое, как мне показалось, работает нормально.

Я называю это Фиктивное поле (хотя я так и не придумал это, так что не кредитуйте меня).

Короче: вам просто нужно вставить это в свой <form>и проверьте, чтобы он был пустым при проверке:

<input type="text" name="email" style="display:none" />

Хитрость заключается в том, чтобы обмануть бота, думая, что он должен вставить данные в нужное поле, поэтому я назвал вход «email». Если у вас уже есть поле, называемое электронной почтой, которое вы используете, попробуйте назвать фиктивное поле чем-то другим, например «компанией», «телефоном» или «электронной почтой». Просто выберите то, что вам известно, что вам не нужно, и что-то похожее на то, что люди обычно найдут логичным, чтобы заполнить веб-форму. Теперь скройте inputполе с использованием CSS или JavaScript / jQuery - все, что вам подходит - просто не установить вход typeв hiddenили бот не попадет на него.

Когда вы проверяете форму (на стороне клиента или на стороне сервера), проверьте, заполнено ли ваше фиктивное поле, чтобы определить, была ли она отправлена ​​человеком или ботом.

Пример:

В случае человека: Пользователь не увидит фиктивное поле (в моем случае с именем «email») и не будет пытаться его заполнить. Поэтому значение фиктивного поля должно быть пустым, когда форма была отправлена.

В случае бота: Бот увидит поле, тип которого textи имя email(или как бы вы это называли) и логически попытается заполнить его соответствующими данными. Неважно, если бы вы ввели форму ввода с помощью какого-нибудь причудливого CSS, веб-разработчики делают это все время. Независимо от значения в фиктивном поле, нам все равно, пока он больше, чем 0персонажи.

Я использовал этот метод в гостевой книге в сочетании с CAPTCHA, , и с тех пор я не видел ни одной спам-почты. Раньше я использовал решение CAPTCHA, но в конечном итоге это привело к появлению около пяти спам-сообщений каждый час. Добавление фиктивного поля в форму прекратило (по крайней мере до сих пор) вскрытие спама.

Я считаю, что это также можно использовать просто с формой входа / аутентификации.

Предупреждение : Конечно, этот метод не является доказательством на 100%. Боты могут быть запрограммированы так, чтобы игнорировать поля ввода со стилем display:noneприменяется к нему. Вы также должны думать о людях, которые используют некоторую форму автозаполнения (например, большинство браузеров имеют встроенный!), Чтобы автоматически заполнить все поля формы для них. Они могут так же хорошо подобрать фиктивное поле.

Вы также можете немного изменить это, оставив поле фиктивного поля видимым, но вне границ экрана, но это полностью зависит от вас.

Будь креативным!


120



Я не думаю, что вышеупомянутый ответ «неправильный», но есть большие области аутентификации, которые не затрагиваются (или, скорее, акцент делается на «как реализовать сеансы cookie», а не на «какие варианты доступны и какова торговля офф».

Мои предложенные изменения / ответы

  • Проблема заключается скорее в настройке учетной записи, чем при проверке пароля.
  • Использование двухфакторной аутентификации гораздо более безопасно, чем более умные средства шифрования паролей
  • НЕ пытайтесь реализовать свою собственную регистрационную форму или базу данных паролей, за исключением случаев, когда хранящиеся данные бесполезны при создании учетной записи и самогенерируются (т. е. стиль Web 2.0, например Facebook, Flickr , и т.д.)

    1. Digest Authentication - это подход, основанный на стандартах, поддерживаемый во всех основных браузерах и серверах, который не будет отправлять пароль даже по защищенному каналу.

Это позволяет избежать необходимости иметь «сеансы» или файлы cookie, поскольку сам браузер будет повторно шифровать сообщение каждый раз. Это самый «легкий» подход к развитию.

Тем не менее, я не рекомендую это, за исключением публичных услуг с низкой стоимостью. Это проблема с некоторыми другими ответами выше - не пытайтесь повторно реализовать механизмы авторизации на стороне сервера - эта проблема была решена и поддерживается большинством основных браузеров. Не используйте файлы cookie. Не храните ничего в собственной ручной базе данных. Просто спросите, по запросу, если запрос подвергнут авторизации. Все остальное должно поддерживаться конфигурацией и сторонним доверенным программным обеспечением.

Так ...

Во-первых, мы путаем первоначальное создание учетной записи (с паролем) с повторная проверка пароля. Если я Flickr и создаю ваш сайт в первый раз, новый пользователь имеет доступ к нулевому значению (пустое пространство). Мне действительно все равно, если человек, создающий учетную запись, лжет о своем имени. Если я создаю учетную запись больничной интрасети / экстрасети, значение лежит во всех медицинских документах, и поэтому я делать заботиться о личности (*) создателя учетной записи.

Это очень сложная часть. только достойное решение - сеть доверия. Например, вы входите в больницу в качестве врача. Вы создаете веб-страницу, размещенную где-нибудь с вашей фотографией, свой номер паспорта и открытый ключ, и хэш их всех с закрытым ключом. Затем вы посещаете больницу, и системный администратор смотрит ваш паспорт, видит, совпадает ли фотография с вами, а затем хеширует хеш веб-страницы / фотографии с закрытым ключом в больнице. С этого момента мы можем безопасно обменять ключи и жетоны. Как может любой, кто доверяет больнице (есть секретный соус BTW). Системный администратор также может предоставить вам RSA ключа или другой двухфакторной аутентификации.

Но это много хлопот, а не очень Web 2.0. Тем не менее, это единственный безопасный способ создания новых учетных записей, которые имеют доступ к ценной информации, которая не создана самостоятельно.

  1. Kerberos и SPNEGO - механизмы единого знака с доверенной третьей стороной - в основном пользователь проверяет доверенную третью сторону. (NB это ни в коем случае нельзя доверять OAuth )

  2. SRP - вид умной аутентификации пароля без доверенной третьей стороны. Но здесь мы попадаем в сферы «безопаснее использовать двухфакторную аутентификацию, даже если это дороже»,

  3. SSL клиентская сторона - предоставить клиентам сертификат открытого ключа (поддержка во всех основных браузерах - но вызывает вопросы по безопасности клиентского компьютера).

В конце концов, это компромисс - какова стоимость нарушения безопасности и затраты на внедрение более безопасных подходов. Однажды мы можем увидеть ИПК широко распространены и, следовательно, больше не имеют собственных проверенных форм и баз данных. Один день...


71



When hashing, don't use fast hash algorithms such as MD5 (many hardware implementations exist). Use something like SHA-512. For passwords, slower hashes are better.

The faster you can create hashes, the faster any brute force checker can work. Slower hashes will therefore slow down brute forcing. A slow hash algorithm will make brute forcing impractical for longer passwords (8 digits +)


48



A good article about realistic password strength estimation is:

Dropbox Tech Blog » Blog Archive » zxcvbn: realistic password strength estimation


46



My favourite rule in regards to authentication systems: use passphrases, not passwords. Easy to remember, hard to crack. More info: Coding Horror: Passwords vs. Pass Phrases


41