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

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

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

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

  • как войти в
  • как выйти
  • как оставаться в системе в
  • управление cookies (включая рекомендуемые настройки)
  • шифрование SSL/HTTPS
  • как хранить пароли
  • использование секретных вопросов
  • забыли логин/пароль
  • использование nonces предупреждения подделки межсайтовых запросов (CSRF)
  • OpenID
  • "Запомнить меня" флажок
  • автозаполнение браузером имен пользователей и пароли
  • секретные url (public URL-адресом защищено digest)
  • проверка надежности пароля
  • проверка электронной почты
  • и многое другое о проверка подлинности на основе формы...

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

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

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

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

12 ответов


Часть 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 наиболее распространенных паролей

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

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

  • это, однако, займет чрезмерное количество времени, чтобы взломать даже 6-символьный пароль,если бы Вы были ограничена одной попыткой в секунду!

  • Итак, что мы можем извлечь из этих цифр? Ну, много, но мы можем сосредоточиться на самой важной части: на том, чтобы предотвратить большое количество быстрых последовательных попыток входа в систему (т. е. 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 (очень читаемая исследовательская статья Беркли)

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

    отправка документов

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

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

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

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

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

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

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

    контрольные вопросы

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

    сеансовые cookies

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

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

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

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

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


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

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

    я подытожу это следующим образом:

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

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


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

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

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

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

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

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

    пример:

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

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

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

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

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

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

    быть творческой!


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

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

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

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

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

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

    Так ...

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

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

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

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

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

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

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


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

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


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

    Dropbox Tech блог "архив блога" zxcvbn: реалистичная оценка прочности пароля


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


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


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

    относительно poing Часть IV: Забытая функциональность пароля в первом ответе я бы сделал замечание о времени атаки.

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

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

    https://crypto.stanford.edu / ~dabo / документы / webtiming.pdf


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

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

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

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

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

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

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

    угу ... это совсем ментальный переключатель из "дикого и шерстистого Интернета"."


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

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