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

Мы'будем считать, что вы уже знаете, как построить HTML-форму логин+пароль, которая передает значения скрипту на стороне сервера для аутентификации. В следующих разделах будут рассмотрены шаблоны для надежной практической аутентификации, а также то, как избежать наиболее распространенных ловушек безопасности. To HTTPS or not to HTTPS? Если соединение не является защищенным (то есть, туннелировано через HTTPS с использованием SSL/TLS), значения вашей формы входа будут отправлены в открытом виде, что позволит любому, кто подслушивает на линии между браузером и веб-сервером, прочитать логины по мере их прохождения. Этот тип прослушки регулярно используется правительствами, но в целом, мы не будем рассматривать 'собственные' провода, кроме как сказать следующее: Просто используйте HTTPS. По сути, единственный практичный способ защиты от прослушки/перехвата пакетов при входе в систему - это использование HTTPS или другой схемы шифрования на основе сертификатов (например, [TLS][1]) или проверенной схемы "вызов-ответ" (например, SRP на основе [Diffie-Hellman][2]). Любой другой метод может быть легко обойден подслушивающим злоумышленником. Конечно, если вы хотите быть немного непрактичным, вы можете использовать какую-либо схему двухфакторной аутентификации (например, приложение Google Authenticator, физическую кодовую книгу в стиле холодной войны или ключ-генератор RSA). При правильном применении это может работать даже при незащищенном соединении, но трудно представить, что разработчик захочет внедрить двухфакторную аутентификацию, но не SSL. (Не) Применять собственное шифрование/хеширование JavaScript. Учитывая предполагаемую (хотя сейчас ее можно избежать[27]) стоимость и техническую сложность установки SSL-сертификата на вашем сайте, некоторые разработчики поддаются искушению внедрить собственные схемы хэширования или шифрования в браузере, чтобы избежать передачи логинов в открытом виде по незащищенному проводу. Хотя это благородная мысль, она бесполезна (и может стать [недостатком безопасности][3]), если не сочетается с одним из вышеперечисленных способов - то есть либо с надежным шифрованием, либо с использованием проверенного механизма "вызов-ответ" (если вы не знаете, что это такое, просто знайте, что это одна из самых труднодоказуемых, самых трудноразрабатываемых и самых труднореализуемых концепций цифровой безопасности). Хотя хэширование пароля действительно может быть эффективно против раскрытия пароля, оно уязвимо для атак повторного воспроизведения, атак типа "человек посередине"/перехвата (если злоумышленник может внедрить несколько байт в вашу незащищенную HTML-страницу до того, как она попадет в ваш браузер, он может просто закомментировать хэширование в JavaScript), или атак перебором (поскольку вы передаете злоумышленнику и имя пользователя, и соль, и хэшированный пароль). Каптча против человечества [CAPTCHA][4] предназначена для предотвращения одной конкретной категории атак: автоматизированных атак по словарю/перебором без участия человека. Несомненно, это реальная угроза, однако существуют способы борьбы с ней, которые не требуют использования CAPTCHA, в частности, правильно разработанные схемы дросселирования входа на стороне сервера - о них мы поговорим позже. Знайте, что реализации CAPTCHA не одинаковы; они часто не решаемы человеком, большинство из них неэффективны против ботов, все они неэффективны против дешевой рабочей силы из стран третьего мира (согласно [OWASP][5], текущая ставка потогонного труда составляет $12 за 500 тестов), а некоторые реализации могут быть технически незаконными в некоторых странах (см. [OWASP Authentication Cheat Sheet][6]). Если вы должны использовать CAPTCHA, используйте Google [reCAPTCHA][7], так как он по определению является OCR-трудным (поскольку использует уже OCR-мисслессифицированные сканы книг) и очень старается быть удобным для пользователя. Лично я считаю CAPTCHA раздражающими, и использую их только в крайнем случае, когда пользователь не смог войти в систему несколько раз, а задержки дросселирования максимальны. Это происходит достаточно редко, чтобы быть приемлемым, и это укрепляет систему в целом. Хранение паролей / проверка логинов. Возможно, это уже стало общеизвестным после всех широко разрекламированных взломов и утечек пользовательских данных, которые мы наблюдали в последние годы, но об этом необходимо сказать: Не храните пароли в открытом виде в вашей базе данных. Базы данных пользователей регулярно взламываются, утекают или перехватываются с помощью SQL-инъекций, и если вы храните пароли в открытом виде, это означает, что безопасность входа в систему мгновенно нарушена. Итак, если вы не можете хранить пароль, как проверить, что комбинация логин+пароль, отправленная из формы входа, верна? Ответ - хэшированием с использованием [функции выведения ключа][24]. Каждый раз, когда создается новый пользователь или меняется пароль, вы берете пароль и прогоняете его через KDF, такую как Argon2, bcrypt, scrypt или PBKDF2, превращая пароль в открытом виде ("correcthorsebatterystaple") в длинную, случайно выглядящую строку, которую гораздо безопаснее хранить в базе данных. Для проверки входа в систему вы запускаете ту же хэш-функцию для введенного пароля, на этот раз с добавлением соли, и сравниваете полученную хэш-строку со значением, хранящимся в вашей базе данных. Argon2, bcrypt и scrypt уже хранят соль вместе с хэшем. Более подробную информацию можно найти в этой [статье][23] на sec.stackexchange. Причина использования соли заключается в том, что хэширования самого по себе недостаточно - вам нужно добавить так называемую 'соль' для защиты хэша от [радужных таблиц][8]. Соль эффективно предотвращает хранение двух точно совпадающих паролей в виде одного и того же хэш-значения, предотвращая сканирование всей базы данных за один запуск, если злоумышленник выполняет атаку угадывания пароля. Криптографический хэш не следует использовать для хранения паролей, поскольку выбранные пользователем пароли недостаточно надежны (т.е. обычно не содержат достаточной энтропии), и атака на угадывание пароля может быть выполнена за относительно короткое время злоумышленником, имеющим доступ к хэшам. Именно поэтому используются KDF - они эффективно ["растягивают ключ"][25], что означает, что каждое угадывание пароля злоумышленником приводит к многократному повторению алгоритма хэширования, например, 10 000 раз, что заставляет злоумышленника угадывать пароль в 10 000 раз медленнее. Данные сессии - "Вы вошли в систему как Spiderman69"**. После того как сервер проверил логин и пароль по вашей базе данных пользователей и нашел совпадение, системе необходимо запомнить, что браузер прошел аутентификацию. Этот факт должен храниться только на стороне сервера в данных сессии.

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

ЧАСТЬ II: Как оставаться под своим логином - пресловутый флажок "Запомнить меня"

Постоянные файлы cookie для входа (функциональность "запомнить меня") - это опасная зона; с одной стороны, они полностью безопасны, как и обычные логины, если пользователи понимают, как с ними обращаться; с другой стороны, они представляют огромный риск для безопасности в руках неосторожных пользователей, которые могут использовать их на общественных компьютерах и забыть выйти из системы, и которые могут не знать, что такое куки браузера или как их удалить. Лично мне нравятся постоянные логины для сайтов, которые я посещаю регулярно, но я знаю, как обращаться с ними безопасно. Если вы уверены, что ваши пользователи знают то же самое, вы можете использовать постоянные логины с чистой совестью. Если нет - что ж, тогда вы можете придерживаться философии, что пользователи, небрежно обращающиеся со своими учетными данными, сами виноваты в том, что их взломали. Мы же не идем к нашим пользователям домой и не отрываем все эти вызывающие фейспалм записки Post-It с паролями, которые они выкладывают на краю мониторов. Конечно, некоторые системы не могут позволить себе, чтобы любая учетная запись была взломана; для таких систем невозможно оправдать наличие постоянных логинов. Если вы решите внедрить постоянные файлы cookie для входа, вот как вы это сделаете:.

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

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

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

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

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

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

1. Не сбрасывайте забытый пароль на автогенерируемый сложный пароль - такие пароли, как известно, трудно запомнить, что означает, что пользователь должен либо изменить его, либо записать - скажем, на ярко-желтом листке Post-It на краю монитора. Вместо того чтобы устанавливать новый пароль, просто позвольте пользователям сразу же выбрать новый пароль - это то, что они хотят сделать в любом случае. (Исключением могут быть случаи, когда пользователи повсеместно используют менеджер паролей для хранения/управления паролями, которые обычно невозможно запомнить без записи).
2. Всегда хэшируйте код/токен потерянного пароля в базе данных. AGAIN, этот код является еще одним примером эквивалента пароля, поэтому он ДОЛЖЕН быть хэширован на случай, если злоумышленник завладеет вашей базой данных. Когда запрашивается код потерянного пароля, отправьте код в открытом виде на адрес электронной почты пользователя, затем хэшируйте его, сохраните хэш в вашей базе данных - и выбросьте оригинал. Точно так же, как пароль или постоянный токен для входа в систему. И последнее замечание: всегда убедитесь, что ваш интерфейс для ввода 'кода потерянного пароля' не менее безопасен, чем сама форма входа, иначе злоумышленник просто использует его для получения доступа. Убедитесь, что вы генерируете очень длинные 'коды потерянного пароля' (например, 16 буквенно-цифровых символов с учетом регистра) - это хорошее начало, но подумайте о добавлении той же схемы дросселирования, которую вы используете для самой формы входа.

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

   Во-первых, вам стоит прочитать эту небольшую статью для проверки реальности: 500 самых распространенных паролей. Ладно, возможно, этот список не является каноническим списком наиболее распространенных паролей на любой системе всякой, но он является хорошим показателем того, насколько плохо люди выбирают свои пароли, когда нет никакой принудительной политики. Кроме того, список выглядит пугающе близко к дому, если сравнить его с общедоступным анализом недавно украденных паролей. Итак: При отсутствии минимальных требований к надежности пароля 2% пользователей используют один из 20 наиболее распространенных паролей. Это означает: если злоумышленник получит всего 20 попыток, то 1 из 50 учетных записей на вашем сайте можно будет взломать. Для решения этой проблемы необходимо рассчитать энтропию пароля, а затем применить пороговое значение. Национальный институт стандартов и технологий (NIST) Специальная публикация 800-63 содержит ряд очень хороших предложений. В сочетании с анализом словаря и раскладки клавиатуры (например, 'qwertyuiop' - плохой пароль) это может отсеять 99% всех плохо подобранных паролей на уровне 18 бит энтропии. Простой расчет надежности пароля и демонстрация визуального измерителя надежности пользователю - это хорошо, но недостаточно. Если не обеспечить соблюдение этого требования, многие пользователи, скорее всего, будут его игнорировать. Для освежения взгляда на удобство использования высокоэнтропийных паролей настоятельно рекомендуется статья Рэндалла Манро Password Strength xkcd. Используйте Troy Hunt's Have I Been Pwned API для проверки паролей пользователей на соответствие паролям, скомпрометированным в результате публичных утечек данных.

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

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

3. Для взлома слабого пароля не требуется практически никакого времени, даже если вы взламываете его с помощью абака.
4. Для взлома алфавитно-цифрового 9-символьного пароля, если он нечувствителен к регистру, не требуется практически никакого времени.
5. Для взлома сложного пароля из символов, букв и цифр, заглавных и строчных букв менее 8 символов не требуется практически никакого времени (настольный ПК может перебрать все пространство клавиш до 7 символов за несколько дней или даже часов).
6. Взлом даже 6-символьного пароля займет непомерно много времени, если вы будете ограничены одной попыткой в секунду!. Итак, что мы можем узнать из этих цифр? Многое, но мы можем сосредоточиться на самом важном: на том, что предотвратить большое количество быстрых последовательных попыток входа в систему (т.е. атаку "грубой силы") на самом деле не так уж и сложно. Но предотвратить ее правильно не так просто, как кажется. Вообще говоря, у вас есть три варианта, которые все эффективны против атак методом перебора (и словарных атак, но поскольку вы уже используете политику надежных паролей, они не должны быть проблемой):

• Предъявлять CAPTCHA после N неудачных попыток (чертовски раздражает и часто неэффективно - но я повторяюсь).
• блокировка аккаунтов и требование подтверждения электронной почты после N неудачных попыток (это DoS атака, которая только и ждет, чтобы произойти)
• И, наконец, дросселирование входа: то есть установка временной задержки между попытками после N неудачных попыток (да, DoS-атаки все еще возможны, но, по крайней мере, они гораздо менее вероятны и их гораздо сложнее осуществить). Лучшая практика #1: Небольшая временная задержка, которая увеличивается с ростом числа неудачных попыток, например:
• 1 неудачная попытка = без задержки
• 2 неудачные попытки = 2 секунды задержки
• 3 неудачные попытки = 4 секунды задержки
• 4 неудачные попытки = 8 секунд задержки
• 5 неудачных попыток = 16 секунд задержки
• и т.д. DoS-атака по этой схеме будет очень непрактичной, так как результирующее время блокировки немного больше, чем сумма предыдущих времен блокировки. Чтобы уточнить: задержка - это не задержка перед возвратом ответа браузеру. Это больше похоже на тайм-аут или рефрактерный период, в течение которого попытки входа в систему для определенной учетной записи или с определенного IP-адреса не будут приниматься или оцениваться вообще. То есть, правильные учетные данные не вернутся при успешном входе в систему, а неправильные учетные данные не вызовут увеличения задержки. Лучшая практика #2: Задержка средней длины, которая вступает в силу после N неудачных попыток, например:
• 1-4 неудачные попытки = без задержки
• 5 неудачных попыток = 15-30 минут задержки DoS-атака по такой схеме будет довольно непрактичной, но, безусловно, выполнимой. Кроме того, уместно отметить, что такая длительная задержка может быть очень раздражающей для легитимного пользователя. Забывчивые пользователи будут вас недолюбливать. Лучшая практика #3: Сочетание двух подходов - либо фиксированная, короткая временная задержка, которая вступает в силу после N неудачных попыток, например:
• 1-4 неудачные попытки = без задержки
• 5+ неудачных попыток = 20 секунд задержки Или увеличивающаяся задержка с фиксированной верхней границей, например:
• 1 неудачная попытка = 5 секунд задержки
• 2 неудачные попытки = 15 секунд задержки
• 3+ неудачных попыток = 45 секунд задержки Эта последняя схема была взята из предложений OWASP по лучшей практике (ссылка 1 из списка MUST-READ) и должна считаться лучшей практикой, даже если она, по общему признанию, является ограничительной. В качестве эмпирического правила, однако, я бы сказал: чем сильнее ваша политика паролей, тем меньше вам придется беспокоить пользователей задержками. Если вы требуете надежные (чувствительные к регистру буквенно-цифровые пароли + обязательные цифры и символы) пароли из 9+ символов, вы можете дать пользователям 2-4 попытки ввода пароля без задержки, прежде чем активировать дросселирование. DoS-атака на эту схему окончательного дросселирования входа будет очень непрактичной. И в качестве последнего штриха, всегда позволяйте постоянным (cookie) логинам (и/или форме входа, проверенной CAPTCHA) проходить, так что легитимные пользователи даже не будут задержаны пока идет атака. Таким образом, очень непрактичная DoS-атака становится экстремально непрактичной атакой. Кроме того, имеет смысл сделать более агрессивное дросселирование учетных записей администраторов, поскольку это наиболее привлекательные точки входа.

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

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

• Распределение попыток в ботнете для предотвращения регистрации IP-адресов.
• Вместо того, чтобы выбрать одного пользователя и попробовать 50.000 наиболее распространенных паролей (чего они не могут сделать из-за нашей блокировки), они выберут самый распространенный пароль и попробуют его против 50.000 пользователей. Таким образом, они не только обходят меры по ограничению максимального количества попыток, такие как CAPTCHA и блокировка входа, но и увеличивают свои шансы на успех, так как вероятность того, что наиболее распространенный пароль номер 1 намного выше, чем номер 49.995.
• Промежуток между запросами на вход для каждой учетной записи пользователя, скажем, 30 секунд, чтобы проскользнуть под радаром. Здесь лучшей практикой будет регистрация количества неудачных входов в систему в целом, и использование среднего значения частоты неудачных входов на вашем сайте в качестве основы для верхнего предела, который вы затем наложите на всех пользователей. Слишком абстрактно? Позвольте мне перефразировать: Скажем, за последние 3 месяца на вашем сайте было в среднем 120 неудачных входов в систему в день. Используя это (среднее значение), ваша система может установить глобальный лимит в 3 раза больше - т.е. 360 неудачных попыток за 24 часа. Затем, если общее количество неудачных попыток по всем учетным записям превысит это число в течение одного дня (или, что еще лучше, отслеживать скорость ускорения и срабатывать по рассчитанному порогу), система активирует общесистемное дросселирование входа - что означает короткие задержки для всех пользователей (все еще за исключением входов с cookie и/или резервных входов с CAPTCHA). Я также опубликовал вопрос с более подробной информацией и действительно хорошим обсуждением того, как избежать хитрых подводных камней в борьбе с распределенными атаками грубой силы

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

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

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

1. OWASP Guide To Authentication / OWASP Authentication Cheat Sheet.
2. Dos and Don'ts of Client Authentication on the Web (очень читабельная научная статья Массачусетского технологического института)
3. Википедия: HTTP cookie
4. Вопросы о личных знаниях для обратной аутентификации: Вопросы безопасности в эпоху Facebook (очень читаемая научная статья Беркли)

Определяющая статья

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

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

• Если соединение между клиентом и сервером не зашифровано, все, что вы делаете, [уязвимо для атак типа "человек посередине"][2]. Злоумышленник может заменить входящий javascript, чтобы нарушить хэширование или отправить все учетные данные на свой сервер, он может прослушивать ответы клиента и выдавать себя за пользователя и т.д. и т.п. SSL с доверенными центрами сертификации предназначен для предотвращения MitM-атак.
• Хешированный пароль, полученный сервером, является [менее безопасным][3], если вы не выполняете дополнительную, избыточную работу на сервере. Существует другой безопасный метод, называемый SRP, но он запатентован (хотя он [свободно лицензирован][4]), и существует мало хороших реализаций.

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

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

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

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

  Куки сеанса

  После того как пользователь вошел в систему, сервер посылает ему сессионный файл cookie. Сервер может получить имя пользователя или id из куки, но никто другой не может сгенерировать такие куки (TODO объясняет механизмы). [Cookies могут быть перехвачены][7]: они защищены только так же, как остальная часть машины клиента и другие коммуникации. Они могут быть считаны с диска, перехвачены в сетевом трафике, перехвачены атакой межсайтового скриптинга, подделаны из отравленного DNS, так что клиент отправляет свои куки на неправильные серверы. Не отправляйте постоянные файлы cookie. Срок действия cookies должен истекать по окончании сеанса клиента (закрытие браузера или выход из вашего домена). Если вы хотите автологинить своих пользователей, вы можете установить постоянный cookie, но он должен отличаться от полносеансного cookie. Вы можете установить дополнительный флаг о том, что пользователь автологинился, и для выполнения важных операций ему необходимо войти в систему по-настоящему. Это популярно среди торговых сайтов, которые хотят предоставить вам беспрепятственный, персонализированный опыт покупок, но при этом защитить ваши финансовые данные. Например, когда вы возвращаетесь на сайт Amazon, он показывает вам страницу, которая выглядит так, будто вы вошли в систему, но когда вы переходите к оформлению заказа (или меняете адрес доставки, кредитную карту и т.д.), он просит вас подтвердить пароль. С другой стороны, финансовые веб-сайты, такие как банки и кредитные карты, содержат только конфиденциальные данные и не должны допускать автологин или режим низкой безопасности.

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

• Dos and Don'ts of Client Authentication on the Web (PDF) 21-страничная академическая статья с множеством отличных советов.
• Ask YC: Best Practices for User Authentication Обсуждение темы на форуме
• You're Probably Storing Passwords Incorrectly Вводная статья о хранении паролей
• Обсуждение: Coding Horror: You're Probably Storing Passwords Incorrectly Обсуждение на форуме статьи Coding Horror.
• [Никогда не храните пароли в базе данных!](

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

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

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

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

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

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

Я называю его Фиктивная Область (хотя я haven' t изобрел это так don' t верят мне).

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

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

Уловка должна дурачить личинку, заставляя думать, она должна вставить данные в обязательное поле, that' s, почему я назвал вход " email". если у Вас уже есть область, названная электронной почтой это you' ре используя Вас должно попытаться назвать куклу, выставляют что-то еще как " company" " phone" или " emailaddress". просто выберите что-то, что Вы знаете Вас don' t потребность и что походит на что-то, люди обычно находили бы логичным, чтобы заполнить в веб-форму. Теперь скройте 'входную' область, использующую CSS или JavaScript/jQuery - безотносительно судорог Вы лучше всего - просто don' t устанавливает вход 'тип' в 'скрытый' или иначе личинку won' t попадаются на него.

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

Пример:

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

В случае личинки: Личинка будет видеть область, тип которой - 'текст' и имя 'электронная почта' (или независимо от того, что это - Вы, назвал его), и логически попытается заполнить его соответствующими данными. Это doesn' t заботятся, разработали ли Вы входную форму с некоторым необычным CSS, веб-разработчики делают все это время. Независимо от того, что стоимость в фиктивной области, мы don' t заботятся о целом it' s больше, чем '0' знаки.

Я использовал этот метод на гостевой книге в сочетании с КАПЧОЙ, и я haven' t замеченный единственная почта спама с тех пор. Я использовал решение ТОЛЬКО ДЛЯ КАПЧИ прежде, но в конечном счете, оно приводило приблизительно к пяти постам спама каждый час. Добавление фиктивной области в форме остановило (по крайней мере, до сих пор) весь спам от появления.

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

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

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

Будьте творческими!

Я не думаю, что вышеупомянутый ответ - " wrong" но есть большие площади идентификации, которые не затронуты (или скорее акцент находится на " как осуществить печенье sessions" не на " какие варианты доступны и что является trade-offs".

Мой предложенный редактирует/отвечает,

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

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

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

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

Так...

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

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

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

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

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

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

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

[2]: http://en.wikipedia.org/wiki/RSA _ % 28security_firm%29

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

• Технический Блог Dropbox & raquo; Архив Блога & raquo; zxcvbn: реалистическая оценка силы пароля *

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

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

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

I' d нравится добавлять одно предложение I' используемый ve, на основе защиты подробно. Вы don' у t должен быть тот же auth& подлинная система для администраторов как постоянные пользователи. У Вас может быть отдельная форма логина на отдельном URL, выполняющем отдельный код для запросов, которые предоставят высокие привилегии. Этот может сделать выбор, который был бы полной болью постоянным пользователям. Один таким образом, что I' используемый ve должен на самом деле зашифровать URL логина для доступа администратора и послать администратору по электронной почте новый URL. Остановки любое нападение грубой силы сразу же как Ваш новый URL могут быть произвольно трудными (очень длинная случайная последовательность), но Ваш администратор user' s только неудобство переходит по ссылке в их электронном письме. Нападавший больше не знает, где даже ОТПРАВИТЬ.

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

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

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

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

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

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

• " В корпоративный, intra - чистое урегулирование, " большинство, если не все предшествующие не могли бы примениться!

Многие корпорации развертывают " внутреннее пользование only" веб-сайты, которые являются, эффективно, " корпоративный applications" это, оказывается, было осуществлено через URL. Эти URL могут (предположительно...) только быть решенными в " company' s внутренняя сеть " (Какая сеть волшебно включает все VPN-связанный ' дорожные воины ')

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

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

С Вашей точки зрения Вы просто знаете это: это любой, кто законно ветры на Вашем веб-сайте должны сопровождаться [переменная окружения, волшебно содержащая...] " символ " (i.e. Отсутствие такого символа должно быть непосредственными основаниями для '404, Не Найденных'.)

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

Ага... it' s вполне умственный выключатель от " дикий-и-покрытый-шерстью Интернет "

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

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