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

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

к HTTPS или не к HTTPS?

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

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

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

(не) свернуть свой собственный JavaScript-шифрование / хеширование

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

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

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

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

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

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

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

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

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

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

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

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

данные сеанса - "вы вошли в систему как Spiderman69"

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

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

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

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

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

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

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

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

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

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

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

не реализуйте "секретные вопросы". Функция "секретные вопросы" является анти-шаблон безопасности. Прочитайте статью по ссылке № 4 из списка обязательных для чтения. Вы можете спросить Сара Пэйлин об этом, после ее Yahoo! учетная запись электронной почты был взломан во время предыдущей президентской кампании, потому что ответ на ее вопрос безопасности... "Wasilla High School"!

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

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

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

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

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

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

Часть IV: Забытая функциональность пароля

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

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

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

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

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

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

хорошо, так что, возможно, список не является канонический список наиболее распространенных паролей на любой

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

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

• присутствует капчу после n неудачных попыток (чертовски раздражает и часто неэффективно - но я повторяю себя здесь)

• блокировка счета и требует проверки электронной почты после n неудачных попыток (это DoS приступа)

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

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

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

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

чтобы уточнить: задержка не a задержка перед возвратом ответа в браузер. Это больше похоже на тайм-аут или рефрактерный период, в течение которого попытки входа в определенную учетную запись или с определенного 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 без задержек попытки пароля перед активацией дросселировать.

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

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

часть VII: распределенные атаки грубой силы

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

• распространение попыток в ботнете предотвратить пометку IP-адреса

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

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

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

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

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

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

часть VIII: двухфакторная аутентификация и поставщики аутентификации

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

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

необходимо прочитать ссылки о веб-аутентификации

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