За десятилетия айтишки сложилась практика ограничивать пользователей в сложности их паролей. Сейчас пароль пользователя должен:
быть не меньше 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 клавиатуры на своём телефоне. Буквально два нажатия: открыть клавиатуру символов и перейти на вторую страницу. Это уже не говоря о различных альтернативах вроде длинного и очень длинного тире (также известные как – (–) и — (—)). Что, опять словарь дополнять? Кстати, если переключить перед этим раскладку клавиатуры – то гборд даже поменяет некоторые символы. То есть мы уже видим проблему множества раскладок. А теперь ещё можно вспомнить про то, что есть другие клавиатуры, и даже другие операционые системы, у которых свои клавиатуры. Ну и на сладенькое...
???? Эмоджи
???? тоже
???? символы
☹️ .
???? БЭЭЭЭМ!
Наш словарь скоро начнёт требовать отдельное распределённое хранилище.
К какому же выводу мы приходим? Константный словарь спецсимволов – это пло что? павильно, хо. Плохо это... Поэтому наш герой-бэкендер достаёт из инвентаря пузырёк витаминов 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)
petropavel
02.02.2023 17:04+1вообще-то ß — вполне себе маленькая. В заглавном варианте заменялась на SS: gruß → GRUSS. И в 2017 ввели заглавную ẞ. https://en.wikipedia.org/wiki/ß
Lenald Автор
02.02.2023 17:06+1Тем не менее пхп счиатет её и маленькой и большой
peacemakerv
03.02.2023 12:16А в какой версии PHP проверяли ? Или не зависит ?
Lenald Автор
03.02.2023 12:18Однако, как вы могли заметить, изначально я проверял не правильно. С другой стороны, я немного не ожидал, что эсцет это юникод...
Lenald Автор
02.02.2023 19:10+1Спустя некоторое время додумался, что вы всё же правы. Я дурачок, который забыл mb_*. Однако, даже с ним реультаты оказались немного шокирующими, поэтому под корень выпиливать абзац не стал. Тем не менее, спасибо за то, что обратили внимание!
kiriki
02.02.2023 17:28+12Стоило дочитать до конца, чтобы снизить уровень возмущения, копившегося с первых строк.
Мало что раздражает так же сильно, как бессмысленное требование "безопасности" пароля. Особенно когда речь о каком-нибудь мелком форуме, требующем регистрацию для просмотра ссылок или вложений.
eyeDM
02.02.2023 17:28+2public 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; }Я в своих проектах давным-давно запилил такую проверку и не парюсь
Smashrock
02.02.2023 18:15+1Ну когда вы пишите коммерческий софт, то вам будут прилетать требования сложности пароля. Мы с ребятами пока думаем, чтобы простынку из настроек "кол-во маленьких букв, кол-во больших букв" превратить в скроллер парольной энтропии. Правда и тут встаёт затык с правильным подсчётом энтропии в либах - попробуйте прочекать пароли типа "passwordpassword" и "ааааааааааааа" в таких энтропийных калькуляторах - они вас разочаруют.
megaslowpoke
02.02.2023 22:22+1Это какие, аналогично всем вот этим онлайн по Шеннону которые гуглятся? Тогда гляньте как это например в кипасе сделано. Но готовую либу не подскажу, просто вспомнилось что там всё норм с подсчётом.
Smashrock
02.02.2023 22:40+2О, спасибо! Я продакт и хочется отойти от ненавистных "кол-во маленьких букв, кол-во больших букв, кол-во спец. символов" - клиенты хоть и требуют, но колются об эти списки требований к паролям. А нам с ребятами хочется сделать более безопасно и удобно для клиентов - пришли к выводу, что можно сделать настройку с минимальными требованиями сложности пароля по энтропии, но клиентам об этом только в доках скажем - не надо им знать как всё работает. Просто выведем "минимально требуемая сила паролей - очень слабый, слабый, нормальный, сильный, очень сильный".
batyrmastyr
04.02.2023 21:58Так может заходить с другой стороны: придумывать пароль самим и показывать/высылать пользователю?
Заодно проблема утечки пароля при взломе других сайтов отпадёт.
johnfound
04.02.2023 22:13Ну, пароль он такое дело, по определению должен быть известным только одному. Так что генерировать его для потребителя это дыра в безопасности размером с Москву. Да и пожелает ли потребитель пользоваться им или захочет сразу сменить. Или что намного хуже, забудет сразу и потом будет каждый раз использовать "Я забыл пароль."
batyrmastyr
05.02.2023 14:22генерировать его для потребителя это дыра в безопасности размером с Москву
Обоснуйте, пожалуйста. Напомню две вещи: 1) придуманный пользователем пароль передаётся сайту при регистрации 2) в обоих случаях он передаётся сайту при входе.
В надёжности хранения между ними нет никакой разницы, постулат «пароль должен знать только один» не выполняется никогда.
Можно ещё для авторизации использовать сертификаты - кажется единственный вариант, когда сайт не знает секретный ключ пользователя и не полагается на сторонние сервисы.
Или что намного хуже, забудет сразу и потом будет каждый раз использовать "Я забыл пароль."
Если вы не доверяете почте, то функцию «я забыл пароль» нужно срочно удалять.
Парочка хостеров ради усиления безопасности ввела беспарольный вход - на почту отправляют одноразовый код/ссылку. Это в целом безопасно, но куда менее удобно, чем автозаполнение в браузере.
Evengard
02.02.2023 18:16+8Спасибо за вывод в конце. Осталось убедить в этом всех остальных... В конце концов пароль вида "Сорок тысяч обезьян в попу сунули банан" гораздо более устойчив чем "pA$s(W0rD)&С" (и да, "С" тут кириллическая... И такой пароль куча систем проверок пароля вообще не примут - из-за скобок ли, кириллицы ли или ещё чего).
Вообще, правильней было бы рассчитывать уровень энтропии пароля. Но конкретных алгоритмов их расчёта нормального я увы не видел. И даже при расчёте энтропии не блокировать, а давать как справку.
johnfound
04.02.2023 22:19Вообще, правильней было бы рассчитывать уровень энтропии пароля. Но конкретных алгоритмов их расчёта нормального я увы не видел.
Это потому что если пароль известен у него энтропия 0. Поэтому принципиально невозможно рассчитать энтропию конкретного пароля. Все алгоритмы которые я видел более или менее но неточные.
nochkin
02.02.2023 20:34+3В конце концов, безопасность пользователя – это дело пользователя.К сожалению, это зачастую не так. Если пользователя взломали и что-то там натворили в его аккаунте, то пользователь будет всё валить на глючный сервис, который не в состоянии починить свои проблемы, но уж точно не на себя.
Lenald Автор
03.02.2023 10:38+1Чтобы пользователя не взломали -- нужно чтобы он придумал себе нормальный пароль, который не подберётся за три раза. А чтобы нельзя было заабьюзить наш сайтик брутфорсом -- мы как бэкендеры должны повесить рекапчу на "после трёх попыток". Вот и всё. Если после этого пользователя взломали -- дело либо в социальной инженерии, либо его пароль просто утёк откуда-то, вроде гугл-пассворд-манагера или листочка, или файла на компьютере, либо у него троян
iig
03.02.2023 10:52нужно чтобы он придумал себе нормальный пароль, который не подберётся за три раза
Откуда пользователь может знать, за сколько раз подберется его пароль?
Lenald Автор
03.02.2023 20:37Я полагаю, даже дети уже знают, что нельзя ставить паролем имена, даты, имейл, и штуки типа кверти, восьми единиц и 1..9. Остальное подбирается дольше трёх раз
PhoenixRed
03.02.2023 10:54… либо взломали сайт, в БД которого и хранился пароль. У меня так несколько хороших паролей утекло, и единственное, что в этом случае спасло — настроенная двухфакторка
Lenald Автор
03.02.2023 12:10Наша же задача ... обеспечить безопасность ... хранения (хотя бы захэшировать с солью)
Rukis
03.02.2023 15:12А если брутфорс распределенный? А если используют средства обхода рекапчи? А если атакующий готов подождать успеха пару месяцев?
Lenald Автор
03.02.2023 20:32Тогда его только Господь Бог остановит. Или смерть. Какой выбирать себе пароль -- дело пользователя. Захочет -- придумет себе пароль, как последняя моя регулярка со словарём спецсимволов. Такое хрен отгадаешь. Захочет -- "послал дед бабку к морю ловить рыбу", захочет -- кверти. Если кверти -- пользователь сам себе враг, и конкретный сайт тут не виноват.
nochkin
03.02.2023 19:02Эти "три попытки на капчу" никак не помогут взламывать утёкшую базу.
Да и как пользоватедю понять сколько попыток надо для взлома его пароля? Его задача "побыстрее пройти регистрацию", а не решать проблемы безопасности какого-то непонятного сайта.
Lenald Автор
03.02.2023 20:33От утекшей базы мы как бэкендеры можем озаботиться только защитой системы и, господи, в который раз: кто вообще хранит пароль не в виде хэша?
nochkin
03.02.2023 20:37При чём тут хеш? Сейчас почти все утекшие базы имеют пароли в виде хеша. Но если пароль словарный, то наличие хеша -- это почти то же самое, что и пароль в чистом виде. Особенно если учесть, что вроде как почти все знают про хеш, но почему-то не все его солят. Это достаточно распространено на разных сайтах (друг рассказал).
saboteur_kiev
02.02.2023 23:30+2Я давно пришел к выводу, что хороший пароль - который ты в принципе сможешь вспомнить наизусть, и самое главное ввести с любой клавиатуры (домашней, эргономной, рабочей), а также с телефона/планшета
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+
centralhardware2
03.02.2023 10:34Это вынуждает использовать очень маленькое количество паролей в мире где сервисов сотни, так что менеджер паролей must have
Lenald Автор
03.02.2023 10:34Главное, на хранить их в гугле :D
centralhardware2
03.02.2023 12:18Я использую Bitwarden который на rust self hosted
Lenald Автор
03.02.2023 12:20Тоже. Не сказать, чтобы прям очень удобно им пользоваться, но на работе выбрали его. Уверен, айти-отрасль исследовала рынок пассворд-манагеров, раз выбрала именно битварден...
saboteur_kiev
04.02.2023 02:45Эм. для сервисов можно использовать сертификаты, ссш ключи и так далее.
А вот вводить пароль руками - ну не знаю. навскидку я за месяц максимум 10 сервисов таких знаю. Ну в записном менеджере может 100 наберется, но я их редко использую, могу добраться до настольного компа с менеджером паролей.
johnfound
03.02.2023 12:59Я давно пришел к выводу, что хороший пароль — который ты в принципе сможешь вспомнить наизусть, и самое главное ввести с любой клавиатуры
123456
alexxisr
03.02.2023 06:20+5Если вы хотите чтобы у ваших пользователей были надежные пароли — сгенерируйте их сами, а если пользователь захочет сменить пароль — предложите ему на выбор 3-5 вариантов вновь сгенерированных.
А если давать вводить пароль самому, то зачем действительно ограничивать человека.
xaosxaos2
03.02.2023 10:35+3Правильный ответ, прозвучит грубо, отвалите от пользователей. Все Ваши выпердиши это потому что не даёте пользователю решать каким должен быть пароль, то добавьте Большие, то нету цифр, то спецсимволы не там, он пароль слишком длинный... Отстаньте! Все нормализуется со временем, да будут дураки, но как будто дураки не страдают даже с супер надежными паролями? :) Извините накипело.
centralhardware2
03.02.2023 12:20+3Все таки правильный ответ дайте вход через ВК, Гугл или что либо еще. 99 сервисов вообще не нужно иметь своих регистраций
xaosxaos2
03.02.2023 12:26+2Согласен, мне проще выполнить вход через сервис где я уже есть, чем придумывать ники пароли и на какую почту всё это будет приходить.
Arhammon
03.02.2023 10:58+1А потом одинаковые пароли на всех ресурсах, или двойная смена пароля чтоб обойти регулярную смену паролей - пользователи придумают, как сделать все усилия по обеспечению безопасности сделать бесполезными...
johnfound
03.02.2023 12:57+1За конечный вывод – Браво! Именно так и никак иначе!
Я бы добавил еще, что каждое ограничение на содержание пароля всегда уменьшает его надежность и облегчает брутфос, исключая огромное множество возможных паролей из пространства перебора.
event1
03.02.2023 16:34+1Поэтому, на самом деле правильным будет никак не ограничивать пользователя в его паролях. В конце концов, безопасность пользователя – это дело пользователя
Как пользователь — двумя руками за. Как разработчик с большим сожалением вынужден отметить, что если продукт придётся сертифицировать на безопасность, то придётся вводить требования к паролям.
johnfound
03.02.2023 18:05Невозможно придумать такие правила, чтобы увеличивали надежность пароля. Всегда можно придумать по сути словарный пароль который соответствовал бы требованиям. И этот пароль будет легко брутфорсить как бы сложно он и не выглядел.
То есть, вводя правила, вы всегда уменьшаете безопасность системы. Больше и сложнее правил – меньше безопасности в системе.
event1
03.02.2023 18:19Если не вводить правил, то половина паролей будет "qwerty", а вторая половина — "12345". Как это не уменьшит безопасность системы — загадка.
johnfound
03.02.2023 18:48+1Даже если это и так, то это значит что для пользователей безопасность не важна. Надо сделать так, чтобы была важна.
Кстати, единственный метод контроля за паролями, который реально повышает безопасность, это просто брутфорсить пароли пользователей (конечно со словарем) и если брутфорсятся быстро (ну, не знаю, примерно за неделю), то требовать смену. Так рано или поздно, все пользователи придумают хорошие пароли.
ЕДИТ: Кстати, с правилами все пароли будут "Qwe!@34" что выглядит получше, но по сути то же самое.
klirichek
03.02.2023 19:44Почему бы не ограничиться просто латиницей (без регистра), + несколькими пунктуациями (точка, запятая, точка с запятой, !, ?).
Ну и требование к размеру пароля - пусть лучше +10-40 символов длины, чем +30 разных условий на спецы/эмодзи/регистр и т.д.Объективно - даже в кириллице, буква ё/й может быть как одним символом, так и двумя (е с диересизом). Причём это не всегда доступно для контроля пользователем (винда/линукс/мак - одни и те же клавиши нажаты; одно и то же на экране отобразилось, РАЗНОЕ в файл записалось).
(если что - вот я сейчас с мака это набираю. И файлы на сетевой шаре с "одинаковыми именами" я уже наблюдал. В именах были ё/й)
gurux13
03.02.2023 19:56+1johnfound
03.02.2023 21:07Ну, не сомневаясь в верности самого комикса, все таки надо сделать 3 замечания:
-
Это работает только и если только слова подобраны случайно. И не факт, что случайно подобранные слова будет легко запомнить да и в правильном порядке (кстати, заметьте что в комиксе тоже в конце порядок как-то замят).
-
Это очень долго и нудно вводить. Примерно 30 нажатий на кнопки клавиатуры может быть очень досадно, если часто приходится делать.
-
А как, если у нас не один пароль а десятки (сотни)? Смешались в кучу кони, люди, и батарейки с степлерами.
Lenald Автор
03.02.2023 21:11В одной из итераций моих паролей у меня был плюс-минус один пароль на несколько сервисов. Скажем, для простоты, "%1$s %2$s %3$s %4$s", но %3$s заменялся на название сервиса. Типа twitter, vk, fb и тд.
В другой итерации моих паролей я начинал пароль с пробела. Потому что никто не юзает пробел в брутфорсе :Djohnfound
03.02.2023 22:26Ну да, знакомо, знакомо. Я тоже через такое проходил.
А потом, наконец, завел менеджер паролей и теперь у меня только один очень сильный случайный пароль, а все остальные генерирует KeePassXC. Храню на локальном диске, синхронизирую через SSH.
-
Didimus
04.02.2023 15:50ЧадГБТ может проверить сложность пароля?
johnfound
04.02.2023 22:31Сисадмин желал подобрать себе стойкий пароль для централизованной авторизации через radius-сервер. Он обратился за советом к Инь Фу Во.
– Как вы думаете, Учитель, пароль «史達林格勒戰役» стойкий?
Нет, – ответил мастер Инь, – это словарный пароль.
– Но такого слова нет в словарях…
– "Словарный" означает, что это сочетание символов есть в wordlists, то есть "словарях" для перебора, которые подключаются к программам криптоанализа. Эти словари составляются из всех сочетаний символов, которые когда-либо встречались в Сети.
– А пароль «Pft,bcm» подойдёт?
– Вряд ли. Он тоже словарный.
– Но как же? Это же…
– Введи это сочетание в Гугле – и сам увидишь.
Сисадмин защёлкал клавишами.
– О, да. Вы правы, Учитель.
Через некоторое время Сисадмин воскликнул:
– Учитель, я подобрал хороший пароль, которого не может быть в словарях.
Инь Фу Во кивнул.
– Я ввёл его в Гугле, – продолжал Сисадмин, – и убедился, что в Сети такого сочетания нет.
– Теперь есть.
estet
Выглядит так, будто вы изобретаете велосипед. Почему не использовать passwordqc?
Lenald Автор
Существует и правда достаточно сторонних сервисов проверки пароля, у некоторых из них есть API, у некоторых системные либы, но какие-то из них патные, какие-то -- не удобные. К тому же, сложно себе представить, скажем, какой-нибудь фреймворк-CMS, который бы из коробки шёл с проверкой пароля через сторонний сервис. Потому что тогда получается, что это нужен очень отказоустойчивый сторонний сервис...
Цель же данной статьи была в том, чтобы раскрыть несостоятельность сложившихся на данный момент обязательных ограничений к паролям и их типовые проверки, основанные на том, что мы ожидаем, что все в случае паролей пользуются исключительно английской раскладкой компьютерной клавиатуры
eri
для проверки попала ли ваша банковская карта в руки мошейников введите цифры указанные с 2х сторон.