Часть I: Как войти в систему

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

К HTTPS или не к HTTPS?

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

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

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

(Не делать) Roll-your-own JavaScript шифрование / хэширование

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

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

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

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

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

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

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

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

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

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

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

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

Данные сеанса - "You are logged in as Spiderman69"

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

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

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

Часть II: Как оставаться в системе-печально известный "Remember Me" Checkbox

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

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

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

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

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

2. И просто повторю один из самых распространенных подводных камней, не храните постоянный логин COOKIE (TOKEN) в вашей базе данных, только HASH из него! Логин-токен эквивалентен паролю, поэтому, если злоумышленник заполучил вашу базу данных, он может использовать эти токены для входа в любую учетную запись, как если бы это были явные комбинации логин-пароль. Поэтому используйте хэширование (согласно https://security.stackexchange.com/a/63438/5002 a weak hash прекрасно подойдет для этой цели) при хранении постоянных маркеров входа.

Часть III: использование секретных вопросов

Не реализовывайте 'secret questions' . Функция 'secret questions' является анти-шаблоном безопасности. Прочитайте статью по ссылке № 4 из списка обязательных к прочтению. Вы можете спросить об этом Сару Пэйлин, после ее Yahoo! email аккаунт был взломан во время предыдущей президентской кампании, потому что ответ на ее секретный вопрос был... "Это Была Средняя Школа Василлы"!

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

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

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

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

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

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

Часть IV: Забыли пароль

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

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

2. Всегда hash потерянный код пароля / токен в базе данных. AGAIN , этот код является еще одним примером эквивалента пароля, поэтому он MUST будет хэшироваться в случае, если злоумышленник доберется до вашей базы данных. Когда запрашивается потерянный код пароля, отправьте открытый текстовый код на адрес пользователя email, затем hash, сохраните hash в своей базе данных-и выбросьте оригинал . Так же, как пароль или постоянный маркер входа.

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

Часть V: проверка надежности пароля

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

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

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

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

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

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

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

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

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

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

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

3. Для взлома сложного пароля symbols-and-letters-and-numbers, upper-and-lowercase длиной менее 8 символов практически не требуется времени (рабочий стол PC может выполнить поиск по всему пространству ключей до 7 символов в течение нескольких дней или даже часов)

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

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

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

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

• Если соединение между клиентом и сервером не зашифровано, все, что вы делаете, уязвимо для атак man-in-the-middle . Злоумышленник может заменить входящий javascript, чтобы сломать хэширование или отправить все учетные данные на свой сервер, он может прослушивать ответы клиентов и идеально олицетворять пользователей и т. д. и т.д. SSL с доверенными центрами сертификации предназначен для предотвращения атак MitM.
• Хэшированный пароль, полученный сервером, менее безопасен , если вы не выполняете дополнительную, избыточную работу на сервере.

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

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

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

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

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

Секретный вопрос

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

Файлы cookie сеанса

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

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

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

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

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

• Dos и Don't аутентификации клиента в Интернете (PDF)
  21 страница научной статьи с множеством советов.
• Задать YC: лучшие практики для проверки подлинности пользователей
  Дискуссия на форуме по данной теме
• Вероятно, вы неправильно храните пароли
  Вводная статья о хранении паролей
• Обсуждение: кодирование ужасов: вы, вероятно, храните пароли неправильно
  Дискуссия на форуме о статье ужасов кодирования.
• Никогда не храните пароли в базе данных!
  Еще одно предупреждение о хранении паролей в базе данных.
• Взлом пароля
  Статья в Википедии о слабых сторонах нескольких схем хэширования паролей.
• Достаточно Радужных Таблиц: Что Вам Нужно Знать О Безопасных Схемах Паролей
  Обсуждение радужных таблиц и способов защиты от них, а также от других потоков. Включает в себя обширное обсуждение.

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

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

Я резюмирую это следующим образом:

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

Это не совсем “form-based authentication for websites”. Но это попытка перейти от текущей нормы проверки подлинности на основе форм к чему-то более безопасному: проверке подлинности с поддержкой браузера.

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

Будьте изобретательны!

Я не думаю, что приведенный выше ответ является "wrong", но есть большие области аутентификации, которые не затрагиваются (или, скорее, акцент делается на "как реализовать сеансы cookie", а не на "what options are available and what are the trade-offs".

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

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

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

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

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

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

Так...

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

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

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

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

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

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

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

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

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

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

Dropbox Tech Blog » Blog Archive » zxcvbn: реалистичная оценка надежности пароля

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

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

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

Что касается функции poing PART IV: Forgotten Password в первом ответе, я бы сделал замечание о временных атаках.

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

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

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

Я хотел бы добавить один очень важный комментарий : -

• "In a corporate, intra- net setting," большинство, если не все вышеизложенное, может быть неприменимо!

Многие корпорации развертывают "internal use only" веб-сайтов, которые, по сути, являются "corporate applications", которые были реализованы через URLs. Эти URLs могут (предположительно ...) может быть разрешен только в пределах "the company's internal network." (которая сеть волшебным образом включает все VPN-подключенные 'road warriors.' )

Когда пользователь покорно подключается к вышеупомянутой сети, его личность ("authentication" ) уже является [...] "conclusively known," как и их разрешение ("authorization") делать определенные вещи ... такие как... "to access this website."

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

Из вашего point-of-view вы просто знаете, что любой , кто законно заводится на вашем веб-сайте, должен сопровождаться [переменной окружения, магически содержащей ...] a "token." ( то есть отсутствие такого знака должно быть непосредственным основанием для 404 Not Found .)

Значение токена не имеет для вас никакого смысла, но, если возникнет необходимость, "appropriate means exist", с помощью которого ваш сайт может "[авторитетно] спросить кого-то, кто знает (LDAP... и т.д.)" о любом И каждом(!) вопрос, который у вас может быть. Другими словами, Вы не пользуетесь никакими "home-grown logic." вместо этого вы спрашиваете у власти и безоговорочно доверяете ее вердикту.

Угу ... это довольно ментальный переход от " wild-and-wooly Интернета."

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

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