За десятилетия айтишки сложилась практика ограничивать пользователей в сложности их паролей. Сейчас пароль пользователя должен:

  • быть не меньше N символов;

  • && быть не больше M символов (чуть реже встречается такое правило);

  • Содержать хотя бы одну большую букву;

  • Содержать хотя бы одну маленькую букву;

  • Содержать хотя бы одну цифру;

  • Содержать хотя бы один спецсимвол;

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

Уж где мы только не подстелили соломы для наших нерадивых пользователей, лишь бы они были в безопасности. Ведь и мы, и матанализ, и различные софтинки – все наперебой говорят, что пароль qwerty и пароль W0wS3qur3P/-\$$ имеют кардинально разную подбороустойчивость...

Алгоритм везде один и тот же. К слову, обычно проверка на спецсимволы производится "хотя бы однин символ из заранее захардкоженного словаря". Обычно, словарь вида "не буквы и не цифры с обычной клавиатуры английской раскладки". Просто курсор в кавычки константы, глазки на клавиатуру – и погнали составлять наш шикарнейший словарь.

Данный алгоритм настолько распространён, что встречается почти что в каждой первой статье. Примеров подобных статей – тысячи. Есть даже на хабре (в примере кода можно заметить ту самую регулярку).

Однако, всё ли у нас в порядке с нашим алгоритмом?

Что есть спецсимвол?

Дисклеймер: примеры кода будут на пыхе, для простоты забудем про ограничения длины пароля

Типовой шаблон для поиска спецсимволов выглядит в лучшем случае вот так:

$password = 'fF6:';
var_dump(preg_match('/[\.:,;\?!@#\$%\^&\*_\-\+=]/', $password));
//true

А что если скобка?

<?php
$password = 'fF6:(';
var_dump(preg_match('/[\.:,;\?!@#\$%\^&\*_\-\+=]/', $password));
//false

Ок, не проблема, добавим в словарь ещё и все скобки

<?php
$password = 'fF6:(';
var_dump(preg_match('/[\.:,;\?!@#$%^&\*_\-\+=\(\)<>{}\[\]]/', $password));
//true

А как же слэш?

<?php
$password = 'fF6:(/';
var_dump(preg_match('/[\.:,;\?!@#\$%\^&*_\-\+=\(\)<>{}\[\]]/', $password));
//false

Ок, ладно, сейчас мы сотрём регулярку и заново внимательно перенесём каждый чёртов символ с клавиатуры...

<?php
$password = 'fF6:(/';
var_dump(preg_match('/[\.:,;\?!@#\$%\^&\*_\-\+=\(\)<>{}\[\]\'"`\/_~|\\]/', $password));
//true

И вроде мы собой довольны, однако... "•√π÷׶∆£¢€¥°©®™✓". Вот лишь некоторые символы, которые я слишком легко могу ввести со стандартной GBoard клавиатуры на своём телефоне. Буквально два нажатия: открыть клавиатуру символов и перейти на вторую страницу. Это уже не говоря о различных альтернативах вроде длинного и очень длинного тире (также известные как &ndash; (–) и &mdash; (—)). Что, опять словарь дополнять? Кстати, если переключить перед этим раскладку клавиатуры – то гборд даже поменяет некоторые символы. То есть мы уже видим проблему множества раскладок. А теперь ещё можно вспомнить про то, что есть другие клавиатуры, и даже другие операционые системы, у которых свои клавиатуры. Ну и на сладенькое...

???? Эмоджи
???? тоже
???? символы
☹️ .
???? БЭЭЭЭМ!

Наш словарь скоро начнёт требовать отдельное распределённое хранилище.

К какому же выводу мы приходим? Константный словарь спецсимволов – это пло что? павильно, хо. Плохо это... Поэтому наш герой-бэкендер достаёт из инвентаря пузырёк витаминов C++ зиплок с регулярками и пишет '/[^\w\d]/i', что в переводе с драугрского означает "Что угодно, кроме букв и цифр. Регистронезависимо."

Удивительно, но с этим даже эмоджи находятся

Не обращайте внимания, что матчей 3. Эмоджи – двухбайтовые символы, поэтому регулярка их воспринимает как "первая половина" и "вторая половина".

Итак, со спецсимволами разобрались. Но всё ли теперь в порядке с нашим алгоритмом?

Отдельный котёл для проверяющих регистр букв

Казалось бы, всё нормально:

<?php
$password = 'Bye, World!';
if (!preg_match('/[A-Z]/', $password)) {
  $errors[] = 'В пароле должна быть хотя бы одна большая буква';
}

if (!preg_match('/[a-z]/', $password)) {
  $errors[] = 'В пароле должна быть хотя бы одна маленькая буква');
}

Однако... Стоит сделать всего лишь вот так

<?php
$password = 'АБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ'
    . 'абвгдеёжзийклмнопрстуфхцчшщъыьэюя';

И наш пароль не пройдёт ни одну проверку на регистры букв. То есть, мы только что напали на проблему: наш алгоритм ищет только буквы англиского алфавита. Это значит, что пароли на французском (é, è, ê), испанском (ñ), немецком (ä, ö, ü), норвежском(ø, Æ) и я могу продолжать ещё очень долго – могут не пройти проверку, если там не будет ни одной буквы английского алфавита.

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

<?php
$password = 'АБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ'
    . 'абвгдеёжзийклмнопрстуфхцчшщъыьэюя';

if ($password === mb_strtolower($password)) {
  $errors[] = 'В пароле должна быть хотя бы одна большая буква';
}

if ($password === mb_strtoupper($password)) {
  $errors[] = 'В пароле должна быть хотя бы одна маленькая буква');
}

Вот так нужно проверять строки на наличие букв конкретного регистра.

Неожиданное заключение

Всё это хорошо, однако...

Существуют языки, в которых просто нет деления на большие и маленькие буквы. Моё исследование под названием "Спроси у ChatGPT" показало, что в мире чуть больше 7000 языков, из них около половины (3500) имеют уникальные алфавиты, и около 20-30% всех языков (1400-2100) не имеют разделения на маленькие и большие буквы. Например, китайский, японский, корейский, иврит, арабский (ChatGPT говорит, что в арабском всего несколько букв имеют разделение на маленькие и большие) и индоевропейские языки. А также почему-то латынь и греческий, с чем я в корне не согласен, ибо тексты на обоих этих языках я видел в большом количестве, и больших букв там ровно каждой маленькой по паре...

ОТРЕДАКТИРОВАНО:

Ранее тут был пассаж про существование букв, у которых нет формы "большая" или "маленькая". В пример я приводил букву эсцет (ß) из немецкого алфавита. И даже проводил некоторые тесты, а потом обнаружил, что я забыл использовать mb_*.

В чём проблема: если проверять буквы юникода и не использовать mb-аналоги обычных методов работы со строками, то результат будет странным. Например, в случае эсцет – буква просто не меняла свой шифт, и выглядела как в квантовой суперпозиции:

<?php
$eszett = 'ß';
var_dump(strtoupper($eszett) === strtolower($eszett)); //true

Однако потом меня поправили в комментариях, что у сей буквы в 2017-ом появился её аналог со шифтом. Промариновавшись в фоне где-то часочек эта мысль навела меня на то, что я дурак и забыл про mb. И тут вскрылось такое...

ẞ – большая, ß – маленькая. Как можно заметить, большая эсцет (ẞ) при её понижении спокойно превращается в маленькую (ß), но вот маленькая эсцет при вознесении её шифтом животворящим внезапно превращается в "SS". То есть применяется её написание до 2017 года.

И при том, каждая из этих "S" – это отдельный символ. То есть если потом опять понизить регистр – вы не получите исходный вариант:

Вот такие вот могут быть подводные камни при работе с регистрами.

/ОТРЕДАКТИРОВАНО

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

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

А пароль пользователя должен просто... быть?..

<?php
//...
if ($password1 === '')) {
  throw new ValidationError('Придумайте пароль');
}

if ($password1 !== $password2)) {
  throw new ValidationError('Пароли не совпадают. Проверьте внимательно и попробуйте ещё раз');
}

//encrypt password and do things

Комментарии (63)


  1. estet
    02.02.2023 17:01
    -1

    Выглядит так, будто вы изобретаете велосипед. Почему не использовать passwordqc?


    1. Lenald Автор
      02.02.2023 17:17
      +3

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

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


    1. eri
      03.02.2023 01:31
      +3

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


  1. petropavel
    02.02.2023 17:04
    +1

    вообще-то ß — вполне себе маленькая. В заглавном варианте заменялась на SS: gruß → GRUSS. И в 2017 ввели заглавную ẞ. https://en.wikipedia.org/wiki/ß


    1. Lenald Автор
      02.02.2023 17:06
      +1

      Тем не менее пхп счиатет её и маленькой и большой


      1. peacemakerv
        03.02.2023 12:16

        А в какой версии PHP проверяли ? Или не зависит ?


        1. Lenald Автор
          03.02.2023 12:17
          +1


        1. Lenald Автор
          03.02.2023 12:18

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


    1. Lenald Автор
      02.02.2023 19:10
      +1

      Спустя некоторое время додумался, что вы всё же правы. Я дурачок, который забыл mb_*. Однако, даже с ним реультаты оказались немного шокирующими, поэтому под корень выпиливать абзац не стал. Тем не менее, спасибо за то, что обратили внимание!


  1. kiriki
    02.02.2023 17:28
    +12

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

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


    1. iig
      02.02.2023 18:49
      +2

      мелком форуме

      Каждый мелкий форум считает себя большим и важным ;)


      1. a3or
        02.02.2023 20:33
        +2

        Плох тот солдат форум, который не мечтает стать генералом Хабром ;)


  1. eyeDM
    02.02.2023 17:28
    +2

    public static function isStrongPassword(
      string $password,
      string $login,
      string $email
    ): bool {
      return strLength($password) >= self::PASSWORD_MIN_LEN
        && !preg_match('/^\d+$/', $password)
        && stripos($password, $login) === false
        && stripos($password, $email) === false;
    }

    Я в своих проектах давным-давно запилил такую проверку и не парюсь


  1. Smashrock
    02.02.2023 18:15
    +1

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


    1. megaslowpoke
      02.02.2023 22:22
      +1

      Это какие, аналогично всем вот этим онлайн по Шеннону которые гуглятся? Тогда гляньте как это например в кипасе сделано. Но готовую либу не подскажу, просто вспомнилось что там всё норм с подсчётом.


      1. Smashrock
        02.02.2023 22:40
        +2

        О, спасибо! Я продакт и хочется отойти от ненавистных "кол-во маленьких букв, кол-во больших букв, кол-во спец. символов" - клиенты хоть и требуют, но колются об эти списки требований к паролям. А нам с ребятами хочется сделать более безопасно и удобно для клиентов - пришли к выводу, что можно сделать настройку с минимальными требованиями сложности пароля по энтропии, но клиентам об этом только в доках скажем - не надо им знать как всё работает. Просто выведем "минимально требуемая сила паролей - очень слабый, слабый, нормальный, сильный, очень сильный".


    1. izuck3n
      03.02.2023 10:33
      +1

      Ради интереса, если еще не видели, посмотрите на подход к примеру у zxcvbn (демо).


    1. batyrmastyr
      04.02.2023 21:58

      Так может заходить с другой стороны: придумывать пароль самим и показывать/высылать пользователю?

      Заодно проблема утечки пароля при взломе других сайтов отпадёт.


      1. johnfound
        04.02.2023 22:13

        Ну, пароль он такое дело, по определению должен быть известным только одному. Так что генерировать его для потребителя это дыра в безопасности размером с Москву. Да и пожелает ли потребитель пользоваться им или захочет сразу сменить. Или что намного хуже, забудет сразу и потом будет каждый раз использовать "Я забыл пароль."


        1. batyrmastyr
          05.02.2023 14:22

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

          Обоснуйте, пожалуйста. Напомню две вещи: 1) придуманный пользователем пароль передаётся сайту при регистрации 2) в обоих случаях он передаётся сайту при входе.

          В надёжности хранения между ними нет никакой разницы, постулат «пароль должен знать только один» не выполняется никогда.

          Можно ещё для авторизации использовать сертификаты - кажется единственный вариант, когда сайт не знает секретный ключ пользователя и не полагается на сторонние сервисы.

          Или что намного хуже, забудет сразу и потом будет каждый раз использовать "Я забыл пароль."

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

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


  1. Evengard
    02.02.2023 18:16
    +8

    Спасибо за вывод в конце. Осталось убедить в этом всех остальных... В конце концов пароль вида "Сорок тысяч обезьян в попу сунули банан" гораздо более устойчив чем "pA$s(W0rD)&С" (и да, "С" тут кириллическая... И такой пароль куча систем проверок пароля вообще не примут - из-за скобок ли, кириллицы ли или ещё чего).

    Вообще, правильней было бы рассчитывать уровень энтропии пароля. Но конкретных алгоритмов их расчёта нормального я увы не видел. И даже при расчёте энтропии не блокировать, а давать как справку.


    1. johnfound
      04.02.2023 22:19

      Вообще, правильней было бы рассчитывать уровень энтропии пароля. Но конкретных алгоритмов их расчёта нормального я увы не видел.

      Это потому что если пароль известен у него энтропия 0. Поэтому принципиально невозможно рассчитать энтропию конкретного пароля. Все алгоритмы которые я видел более или менее но неточные.


  1. nochkin
    02.02.2023 20:34
    +3

    В конце концов, безопасность пользователя – это дело пользователя.

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


    1. Lenald Автор
      03.02.2023 10:38
      +1

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


      1. iig
        03.02.2023 10:52

        нужно чтобы он придумал себе нормальный пароль, который не подберётся за три раза

        Откуда пользователь может знать, за сколько раз подберется его пароль?


        1. Lenald Автор
          03.02.2023 20:37

          Я полагаю, даже дети уже знают, что нельзя ставить паролем имена, даты, имейл, и штуки типа кверти, восьми единиц и 1..9. Остальное подбирается дольше трёх раз


      1. PhoenixRed
        03.02.2023 10:54

        … либо взломали сайт, в БД которого и хранился пароль. У меня так несколько хороших паролей утекло, и единственное, что в этом случае спасло — настроенная двухфакторка


        1. Lenald Автор
          03.02.2023 12:10

          Наша же задача ... обеспечить безопасность ... хранения (хотя бы захэшировать с солью)


        1. nochkin
          03.02.2023 19:03

          На каждом сайте должен быть свой пароль. Иначе пропадает смысл в паролях.


      1. Rukis
        03.02.2023 15:12

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


        1. Lenald Автор
          03.02.2023 20:32

          Тогда его только Господь Бог остановит. Или смерть. Какой выбирать себе пароль -- дело пользователя. Захочет -- придумет себе пароль, как последняя моя регулярка со словарём спецсимволов. Такое хрен отгадаешь. Захочет -- "послал дед бабку к морю ловить рыбу", захочет -- кверти. Если кверти -- пользователь сам себе враг, и конкретный сайт тут не виноват.


      1. nochkin
        03.02.2023 19:02

        Эти "три попытки на капчу" никак не помогут взламывать утёкшую базу.

        Да и как пользоватедю понять сколько попыток надо для взлома его пароля? Его задача "побыстрее пройти регистрацию", а не решать проблемы безопасности какого-то непонятного сайта.


        1. Lenald Автор
          03.02.2023 20:33

          От утекшей базы мы как бэкендеры можем озаботиться только защитой системы и, господи, в который раз: кто вообще хранит пароль не в виде хэша?


          1. nochkin
            03.02.2023 20:37

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


  1. acsent1
    02.02.2023 22:33
    +1

    У чат ЖПТ факты лучше не спрашивать. Он соврет и не покраснеет


  1. saboteur_kiev
    02.02.2023 23:30
    +2

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


    1. Deosis
      03.02.2023 07:02
      +2

      Химикам вообще просто, в качестве пароля можно использовать формулу реакции.

      Если формула не самая известная, то никакой словарь не поможет.

      Например: [RO-P(O)2-O-P(O)2-O-PO3]4− + H2O->[RO-P(O)2-O-PO3]3− + [HPO4]2− + H+


    1. centralhardware2
      03.02.2023 10:34

      Это вынуждает использовать очень маленькое количество паролей в мире где сервисов сотни, так что менеджер паролей must have


      1. Lenald Автор
        03.02.2023 10:34

        Главное, на хранить их в гугле :D


        1. centralhardware2
          03.02.2023 12:18

          Я использую Bitwarden который на rust self hosted


          1. Lenald Автор
            03.02.2023 12:20

            Тоже. Не сказать, чтобы прям очень удобно им пользоваться, но на работе выбрали его. Уверен, айти-отрасль исследовала рынок пассворд-манагеров, раз выбрала именно битварден...


      1. saboteur_kiev
        04.02.2023 02:45

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


    1. johnfound
      03.02.2023 12:59

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

      123456


  1. alexxisr
    03.02.2023 06:20
    +5

    Если вы хотите чтобы у ваших пользователей были надежные пароли — сгенерируйте их сами, а если пользователь захочет сменить пароль — предложите ему на выбор 3-5 вариантов вновь сгенерированных.
    А если давать вводить пароль самому, то зачем действительно ограничивать человека.


  1. xaosxaos2
    03.02.2023 10:35
    +3

    Правильный ответ, прозвучит грубо, отвалите от пользователей. Все Ваши выпердиши это потому что не даёте пользователю решать каким должен быть пароль, то добавьте Большие, то нету цифр, то спецсимволы не там, он пароль слишком длинный... Отстаньте! Все нормализуется со временем, да будут дураки, но как будто дураки не страдают даже с супер надежными паролями? :) Извините накипело.


    1. centralhardware2
      03.02.2023 12:20
      +3

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


      1. xaosxaos2
        03.02.2023 12:26
        +2

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


  1. Arhammon
    03.02.2023 10:58
    +1

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


  1. Mausglov
    03.02.2023 12:33

    Рекомендую автору для изучения функцию preg_quote


    1. Lenald Автор
      03.02.2023 20:40

      пасиб


  1. johnfound
    03.02.2023 12:57
    +1

    За конечный вывод – Браво! Именно так и никак иначе!


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


  1. event1
    03.02.2023 16:34
    +1

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

    Как пользователь — двумя руками за. Как разработчик с большим сожалением вынужден отметить, что если продукт придётся сертифицировать на безопасность, то придётся вводить требования к паролям.


    1. johnfound
      03.02.2023 18:05

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


      То есть, вводя правила, вы всегда уменьшаете безопасность системы. Больше и сложнее правил – меньше безопасности в системе.


      1. event1
        03.02.2023 18:19

        Если не вводить правил, то половина паролей будет "qwerty", а вторая половина — "12345". Как это не уменьшит безопасность системы — загадка.


        1. johnfound
          03.02.2023 18:48
          +1

          Даже если это и так, то это значит что для пользователей безопасность не важна. Надо сделать так, чтобы была важна.


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


          ЕДИТ: Кстати, с правилами все пароли будут "Qwe!@34" что выглядит получше, но по сути то же самое.


  1. klirichek
    03.02.2023 19:44

    Почему бы не ограничиться просто латиницей (без регистра), + несколькими пунктуациями (точка, запятая, точка с запятой, !, ?).
    Ну и требование к размеру пароля - пусть лучше +10-40 символов длины, чем +30 разных условий на спецы/эмодзи/регистр и т.д.

    Объективно - даже в кириллице, буква ё/й может быть как одним символом, так и двумя (е с диересизом). Причём это не всегда доступно для контроля пользователем (винда/линукс/мак - одни и те же клавиши нажаты; одно и то же на экране отобразилось, РАЗНОЕ в файл записалось).
    (если что - вот я сейчас с мака это набираю. И файлы на сетевой шаре с "одинаковыми именами" я уже наблюдал. В именах были ё/й)


  1. gurux13
    03.02.2023 19:56
    +1

    1. Lenald Автор
      03.02.2023 20:46

      :D


    1. johnfound
      03.02.2023 21:07

      Ну, не сомневаясь в верности самого комикса, все таки надо сделать 3 замечания:


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


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


      3. А как, если у нас не один пароль а десятки (сотни)? Смешались в кучу кони, люди, и батарейки с степлерами.



      1. Lenald Автор
        03.02.2023 21:11

        В одной из итераций моих паролей у меня был плюс-минус один пароль на несколько сервисов. Скажем, для простоты, "%1$s %2$s %3$s %4$s", но %3$s заменялся на название сервиса. Типа twitter, vk, fb и тд.

        В другой итерации моих паролей я начинал пароль с пробела. Потому что никто не юзает пробел в брутфорсе :D


        1. johnfound
          03.02.2023 22:26

          Ну да, знакомо, знакомо. Я тоже через такое проходил.


          А потом, наконец, завел менеджер паролей и теперь у меня только один очень сильный случайный пароль, а все остальные генерирует KeePassXC. Храню на локальном диске, синхронизирую через SSH.


  1. Didimus
    04.02.2023 15:50

    ЧадГБТ может проверить сложность пароля?


    1. johnfound
      04.02.2023 22:31

      Сисадмин желал подобрать себе стойкий пароль для централизованной авторизации через radius-сервер. Он обратился за советом к Инь Фу Во.

      – Как вы думаете, Учитель, пароль «史達林格勒戰役» стойкий?

      Нет, – ответил мастер Инь, – это словарный пароль.

      – Но такого слова нет в словарях…

      – "Словарный" означает, что это сочетание символов есть в wordlists, то есть "словарях" для перебора, которые подключаются к программам криптоанализа. Эти словари составляются из всех сочетаний символов, которые когда-либо встречались в Сети.

      – А пароль «Pft,bcm» подойдёт?

      – Вряд ли. Он тоже словарный.

      – Но как же? Это же…

      – Введи это сочетание в Гугле – и сам увидишь.

      Сисадмин защёлкал клавишами.

      – О, да. Вы правы, Учитель.

      Через некоторое время Сисадмин воскликнул:

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

      Инь Фу Во кивнул.

      – Я ввёл его в Гугле, – продолжал Сисадмин, – и убедился, что в Сети такого сочетания нет.

      – Теперь есть.