Подробное руководство по аутентификации веб-сайтов на основе форм

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

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

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

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

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

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

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

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

Ответов (12)

Решение

ЧАСТЬ I: Как войти в систему

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

На HTTPS или не на HTTPS?

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

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

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

(Не делать) Сворачивайте собственное шифрование / хеширование JavaScript

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

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

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

КАПЧАС против человечности

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

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

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

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

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

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

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

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

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

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

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

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

Состояние сеанса также может поддерживаться на стороне клиента. Это достигается с помощью таких методов, как JWT (JSON Web Token).

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

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

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

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

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

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

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

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

Не задавайте «секретных вопросов» . Функция «секретные вопросы» - это анти-шаблон безопасности. Прочтите статью по ссылке 4 из списка ДОЛЖНО ПРОЧИТАТЬ. Вы можете спросить об этом Сару Пэйлин после ее Yahoo! учетная запись электронной почты была взломана во время предыдущей президентской кампании, потому что ответ на ее секретный вопрос был ... "Средняя школа Василлы"!

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

  • Стандартный секретный вопрос, например, девичья фамилия матери или любимого питомца.

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

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

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

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

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

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

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

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

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

ЧАСТЬ V: Проверка надежности пароля

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

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

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

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

А для освежающего взгляда на удобство использования паролей с высокой энтропией настоятельно рекомендуется использовать Password Strength xkcd от Randall Munroe .

Используйте Have I Been Pwned API Троя Ханта, чтобы проверять пароли пользователей на соответствие паролям, скомпрометированным в результате утечки общедоступных данных.

ЧАСТЬ 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 из списка ОБЯЗАТЕЛЬНО ПРОЧИТАЕМ) и должна считаться лучшей практикой, даже если она, по общему признанию, носит ограничительный характер.

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

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

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

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

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

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

  • Вместо того, чтобы выбирать одного пользователя и пробовать 50 000 самых распространенных паролей (чего они не могут из-за нашего ограничения), они выберут САМЫЙ самый распространенный пароль и попробуют его вместо 50 000 пользователей. Таким образом, они не только обходят меры по максимальному количеству попыток, такие как CAPTCHA и регулирование входа в систему, но и их шансы на успех возрастают, поскольку самый распространенный пароль номер 1 гораздо более вероятен, чем номер 49,995.

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

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

Слишком абстрактно? Перефразирую:

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

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

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

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

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

ОБЯЗАТЕЛЬНО ПРОЧИТАЙТЕ ССЫЛКИ о веб-аутентификации

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

Мое любимое правило в отношении систем аутентификации: используйте пароли, а не пароли. Легко запомнить, трудно взломать. Более подробная информация: Coding Horror: Passwords vs. Pass Phrases

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

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

Я резюмирую это так:

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

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

Хорошая статья о реалистичной оценке надежности пароля:

Технический блог Dropbox »Архив блога» zxcvbn: реалистичная оценка надежности пароля

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

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

Что касается позиции ЧАСТЬ IV: Функциональность забытого пароля в первом ответе, я хотел бы отметить атаки по времени.

В формах « Запомнить пароль» злоумышленник потенциально может проверить полный список электронных писем и определить, какие из них зарегистрированы в системе (см. Ссылку ниже).

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

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

Используйте OpenID Connect или доступ, управляемый пользователем .

Ведь нет ничего эффективнее, чем вообще этого не делать.

Окончательная статья

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

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

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

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

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

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

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

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

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

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

Сессионные куки

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

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

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

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

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

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

Предлагаемые мной правки / ответы

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

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

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

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

Так ...

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

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

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

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

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

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

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

При хешировании не используйте быстрые алгоритмы хеширования, такие как MD5 (существует множество аппаратных реализаций). Используйте что-то вроде SHA-512. Для паролей лучше использовать более медленные хеш-коды.

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

Хочу добавить один очень важный комментарий: -

  • «В корпоративной внутренней сети» большая часть, если не все вышеперечисленное, может не применяться!

Многие корпорации развертывают веб-сайты «только для внутреннего использования», которые, по сути, являются «корпоративными приложениями», которые были реализованы через URL-адреса. Эти URL-адреса могут (предположительно ...) разрешаться только во «внутренней сети компании». (Какая сеть волшебным образом включает в себя всех подключенных к VPN «дорожных воинов».)

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

Эта услуга «аутентификация + авторизация» может быть предоставлена ​​несколькими различными технологиями, такими как LDAP (Microsoft OpenDirectory) или Kerberos.

С вашей точки зрения вы просто знаете следующее: любой, кто законно заходит на ваш веб-сайт, должен сопровождаться [переменной окружения, магически содержащей ...] «токеном». ( т.е. отсутствие такого токена должно быть непосредственным основанием для этого 404 Not Found .)

Значение токена не имеет для вас никакого смысла, но, если возникнет необходимость, «существуют соответствующие средства», с помощью которых ваш веб-сайт может «[авторитетно] спросить кого-то, кто знает (LDAP ... и т. Д.)» О любых и любых (!) вопрос, который может у вас возникнуть. Другими словами, вы не пользуетесь какой-либо «доморощенной логикой». Вместо этого вы спрашиваете Власть и безоговорочно доверяете ее вердикту.

Ага ... это довольно ментальный выход из "безумного Интернета".