Как исключить ввод кириллицы, спецсимволов и пробелов?

Question

[Антон]

Есть ТЗ:
Валидация пароля.
Пароль может содержать только буквы латинского алфавита (любого регистра) и цифры. Не может содержать кириллицу, спецсимволы и пробелы.

Примеры:
QQwert12 - пройдёт валидацию
Кириллица123 - не пройдёт валидацию

Но проблема в том что qweFrty123 йцу # тоже пройдет валидацию

Какой должен быть паттерн/набор для выражения что полностью исключить кириллицу, спецсимволы и пробелы?

Answer 1

[Сергей П]

[a-zA-Z0-9]+
Но у вас плохие требования к паролю.
Они выдают непрофессионализм разработчиков, которые внедряют такие требования.
Это признак того, что пароль лежит в открытом (не хешированном) виде в БД.
Это провоцирует делать слабые пароли.
Это выглядит как поделка студентов.

Если и вводить ограничения, то минимальные:
- пароль должен быть не пустым. Всё.

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

Эти предупреждения должны быть заметны, но не должны запрещать создать такой пароль. Обсуждать можно только то, что касается списка самых распространённых паролей, скажем тысячи самых популярных. Ну и короткие (меньше 6 знаков).
Пароль следует хешировать с только что сгенерированной солью. Хранить соль нужно рядом с хешем. Также рядом можно указать название алгоритма хеширования. Прямо в одной строке. Это не снизит безопасность, зато избавит вас от проблем связанных с переходом на новые алгортимы хеширования.

Comments

[DevMan]

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

[Евгений]

Как правило, это просто дз по регуляркам) отвалидировать пароль, мейл, телефон))

[Сергей П]

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

DevMan, я выводов не делал, я просто сказал, что это признак.
Часто встречаются люди, которые накладывают на ввод пользователя очень странные требования потому что не умеют правильно экранировать строки. В случае пароля это еще и признак хранения пароля не в виде хеша.
Однажды я видел в продакшне даже хранение "зашифрованных", в base64(!), ага, паролей. И нет, там не хеши были в base64? а именно что пароли. На мой непрошенный аудит и WTF горе-разработчики мне заявили, что пароли, же зашифрованные, глазами текст паролей не виден, значит всё хорошо.

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

[Сергей П]

Евгений, отвалидировать бы таких преподов=)
Надо учебные примеры составлять так, чтобы они чему-то учили помимо основной темы лабораторной. Ну или хотя бы не учили плохому.

[DevMan]

Сергей Паньков,

чем у вас обусловлены такие странные требования к паролю?

не у меня, а у автора вопроса.

это признак

это домыслы, а не признак.

[Сергей П]

DevMan, о, простите. Я перепутал вас с топикстартером. Мельком глянул.
Ок. Для вас я перефразирую вопрос: чем бы, по-вашему, могли быть вероятно обусловлены такие требования к составу пароля.

У нас нет подробной информации, но раз уж мы заговорили о признаках, то поясню. Для меня мокрый асфальт - это признак недавно прошедшего дождя, проехавшей поливальной машины или большой перестрелки нудистов из водяных пистолетов среди города. Существуют другие признаки всех этих явлений: пасмурная погода, характерный запах, раскаты грома, фрагментарность мокрого асфальта, голые люди тут и там...
Домыслы? Пожалуй можно назвать и так. Я домысливаю отчего бы автору пришлось делать такие ограничения, поскольку автор не дал больше подробностей. Окончательные выводы не делаю, но о непрофессионализме сказал лишь как о наиболее вероятной гипотезе. Так уж вышло, что этот признак в моей практике редко означает, что пароль предназначается для ввода на упрощенной клавиатуре кастомного IoT-контроллера. Так же редко, как нудисты на городских улицах.

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

[DevMan]

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

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

[Сергей П]

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

[Евгений]

Сергей Паньков, base64 - сильно!))
Ну я хз) обычно же при прохождении регулярок первое в что голову лезет - url, e-mail, пароль, телефон, ник))
У нас тоже была такая тема) просто требование к паролю: наличие маленьких букв, больших и цифр, ну и длина минимум 8 символов, вполне логичное требование, чтобы усложножить получение пароля путем банального перебора) как бы круто не хешировался и не солился пароль, если он вида 1111, то тут сервак бессилен)))

[Сергей П]

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

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

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

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

[DevMan]

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

но вывод, что запрет кириллицы признак хранения пароля в открытом виде, так и остался мной не понятым.

[Сергей П]

Евгений, ух вот вы сейчас подставились, сударь под мою больную тему.

требование к паролю: наличие маленьких букв, больших и цифр, ну и длина минимум 8 символов, вполне логичное требование

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

чтобы усложнить получение пароля путем банального перебора

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

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

[Сергей П]

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

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

избегать подобного – такое же простое правило как избегать национальных символов и пробелов в путях

Это ваше личное правило. У меня есть знакомая бабушка,которая активно пользуется соц-сетями. Ей вообще никогда не нужна латиница, она не техно-гик и никогда не заходит в свои соц-сети со смартфона или другого компьютера в Турции. У неё всегда по умолчанию кириллица и есть пантосвитчер, чтобы не приходилось перенабирать одним пальцем сообщение при ошибке в раскладке. Она вообще не понимает различий между "О, "O" и "0". А вы со своими пережитками проблем зари компьютеризации в голове сочиняете ей дикие (для нее) требования к паролю.

но вывод, что запрет кириллицы признак хранения пароля в открытом виде, так и остался мной не понятым.

Я повторно апеллирую к вашей логике и внимательности. Повторно обращаю внимание, что выводов не делал, лишь отметил признак свидетельствующий в пользу одной из вероятных причин.
Мой ход рассуждений таков: те дилетанты, которые хранят пароли в открытом виде, с большой долей вероятности собирают SQL-запросы методом конкатенации строк и, весьма вероятно, вообще не умеют правильно их экранировать. Чтобы залётная кавычка, пробел или килобайтный текст в поле не поломали им сервер, они выкатывают тупые требования в том числе и к паролям.
А может быть эти грамотные ребята не умеют нормально работать с кодировками и под виндой, а то и где угодно у них постоянно возникают "загадочные" проблемы с конвертацией не ascii символов для сохранения в файл. Такие дятлы могут неправильно настроить систему логирования и в придачу писать пароль в логи тоже в открытом виде. Даже если они потом посолят и захешируют пароль, в дебаг-логах он вполне может осесть и утечь. Сколько раз такое было? Как по-вашему текут пароли на разных сайтах?

Зачем вообще может кому-то прийти в голову запретить пробелы в пароле? А зачем запрещать минусы и подчеркивания?

Я могу придумать и другие причины: про контроллеры IoT я упоминал, но допустим у них секьюрное приложение с собственной программной экранной клавиатурой, где есть только такие символы. Но как вы оцениваете, что более вероятно? Задавали бы ребята из команды разработчиков такого приложения такой тупой и нубский вопрос по поводу тривиального регекспа? А вот "специалистов" не хеширующих пароли (ага, временно, до релиза, хотя бы) я встречал лично, на серьёзных щах утверждавших мне, что это не проблема. Вот так я делаю предположения. Читайте внимательнее.

[DevMan]

Сергей Паньков,

для этого нужно сделать заметное предупреждение.

для этого и нужна регулярка.

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

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

[Сергей П]

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

для этого и нужна регулярка.

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

[Евгений]

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

[Сергей П]

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

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

Налицо ошибка атрибуции

[Антон]

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

Всем спасибо!

Answer 2

[pavelsha]

https://ru.stackoverflow.com/questions/761716/%D0%...

Вот уже лет двадцать такую задачу решают при помощи регулярных выражений.
Гуглится минут за пять