Например, пароль состоит из букв, цифр и символов.
Я не совсем понимаю суть вопроса? Для усиления пароля действительно стоит использовать комбинацию букв разного регистра, цифр и символов. Желательно, чтобы они были случайными и уникальными для каждого сайта или входа.
Также полезным инструментом является менеджер паролей.
Однако это общие рекомендации по безопасности паролей, а не специфичные для Discourse.
Возможно, вы меня неправильно поняли. Я имею в виду, что я создал форум на Discourse. При регистрации новых пользователей мне нужно ограничивать их пароли тремя типами. Я могу настраивать только длину пароля через системные настройки.
Я думаю, я понял. Вы хотите обязать пользователей использовать пароли, содержащие сочетание букв, цифр и специальных символов.
К сожалению, на данный момент я не знаю способа реализовать это.
Ну, всё равно спасибо.
Есть ли кто-нибудь, кто может решить эту проблему?
Я думаю, это единственные настройки:
По моему мнению, это разумная просьба о #feature?
Недостаток ужесточения требований к паролям заключается в том, что это может раздражать пользователей при регистрации и даже заставить их отказаться от завершения процесса? Приоритетность этого вопроса, безусловно, варьируется в зависимости от сообщества?
@1378434153 ещё один способ решения этой проблемы — отключить локальный вход и обязать использовать социальный вход или авторизацию через сторонние сервисы, где действуют более строгие правила.
Также стоит рассмотреть возможность принудительного включения двухфакторной аутентификации для всех аккаунтов.
Спасибо. Но мне не нужна двухфакторная аутентификация.
Но, возможно, вашим пользователям это нужно или они этого хотят? Это должно быть главным приоритетом, а не ваши потребности.
Это не проблема. Наличие произвольных правил о том, какие символы допускаются, не помогает, а лишь раздражает пользователей. Пароли также проверяются по базе известных паролей (по крайней мере, так я помню).
Скорее всего, люди, придумавшие эти правила для паролей, потратили больше времени и усилий на изучение лучших практик, чем большинство людей. Я предлагаю вам найти о чём ещё стоит беспокоиться.
Если хотите, за 250–1000 долларов вы можете опубликовать сообщение в канале Marketplace и установить любые правила, которые захотите для своих пользователей.
Лучшие/рекомендуемые отраслевые практики (например, поддерживаемые NIST) больше не рекомендуют требовать «LUDS» (строчные + заглавные буквы + цифры + символы) или какие-либо другие требования к классам символов. В качестве лучшей практики они перешли исключительно к ограничениям по минимальной длине. См., например, этот пост в блоге от NIST пятилетней давности:
В нём обобщаются изменения в рекомендациях, и насколько мне известно, Discourse реализовал рекомендуемые практики.
Есть ещё один момент, который часто остаётся незамеченным — всё это очень англоцентрично. Что вы думаете о том, если и когда я использую короткий и довольно простой пароль на финском, шведском, немецком или вообще на любом другом языке, кроме английского, как быстро скрипт или бот сможет его взломать?
Конечно, это не поможет в США, Канаде, Великобритании и т. д., но мир гораздо шире 
Это означает одно: всё делается потому, что англоязычные пользователи используют пароли вроде “password” или “qwerty” 
Но да, я немного устал, когда админ говорит, что я не могу использовать пароль вроде “ÄitiniMun”, потому что в нём нет нескольких цифр или чего-то ещё.
Слишком простые пароли — это не проблема. Проблема в использовании одной и той же комбинации email/пароля в нескольких сервисах.
NIST в этом вопросе, безусловно, на шаг впереди. Например, стандарт PCI-DSS только что увеличил минимальную длину пароля с 8 до 12 символов и всё ещё требует использования буквенно-цифровых паролей. 
Как уже отметили выше @Stephen и @mcdanlj, требование соблюдения таких правил больше не считается передовой практикой в области безопасности, поэтому мы не требуем этого.
Однако, если вы хотите иметь полный контроль над процессом входа в систему Discourse, вы можете делегировать аутентификацию веб-сервису под вашим контролем, используя DiscourseConnect.
Ладно, я понял. Возможно, это всё-таки неразумная просьба.