Pull to refresh

Comments 83

Пароль Aa1!Aa1!Aa1! удовлетворяет любым самым дурным правилам, и чем дурнее правила, тем больше людей будут пользоваться именно им. Особенно хорош при принудительной частой смене, на следующий месяц будет Bb2@Bb2@Bb2@ и так далее

И тут вводят правило: не более двух одинаковых символов в пароле...

По ссылке из поста вы определённо не ходили:

Пароль должен быть длиннее, чем 8 символов

Но короче, чем 13 символов

Можно использовать только цифры

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

Вы не можете повторять подряд один и тот же символ (если ваш пароль содержит 22 или 55, он будет отклонен).

какому из этих условий не удовлетворяет указанный пароль?

Откуда у вас мой пароль? (с) космобольцы

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

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

  • Треть символов должна быть буквенными, треть спецсимволами, треть числовыми.

  • ...

...

Извините такой пароль уже используется пользователем admin 😁

Моё любимое (причём встречалось не один раз). Максимальная длина пароля есть (тут уже вопрос, зачем). Но про это ограничение не пишут, молча принимают введённый мной длинный пароль (по умолчанию генерю 32 символа), а в итоге сохраняется его обрезанная до N символов версия. N потом подбирается экспериментально методом удаления по одному символу с конца пароля, пока не получится войти. К сожалению, не могу вспомнить, кто именно последний раз так отличился, если склероз отпустит :) - напишу.

Bricklink, например, так делает. Не сразу понял почему при автозаполнении с помощью парольного менеджера не могу войти, а если вручную делаю Ctrl+C/Ctrl+V, то могу. Оказалось, что пароль обрезали и при вставке в поле его тоже обрезают.
Дичь, конечно.

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

А представьте себе, какой жим-жим произошёл в один прекрасный день у меня, когда я опечатался в пароле — а он ПОДОШЁЛ! Я уж подумал было, что сервак сломали, но нет — он просто молча обрезал пароль до 8 симоволов, а я опечатался в десятом.

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

Было такое в банке Авангард. Кстати, там в логах все пароли хранятся.

будет здорово, если хэш посчитать по 32 символам, а сверять, допустим, с сохраненными 8ю ))

У Сбера была такая беда.

О да, мое любимое - самодеятельность в жанре "художественный регекс". Нельзя использовать сгенерированный менеджером паролей rigorously tight horse speculation parameter significantly butterfly mangling discourage, ведь в нем нет ни одной цифры, ни одного символа, ни одной заглавной буквы, и он еще и длиннее 20, атятя! Другое дело Password123-, который отвечает всем требованиям которые я собезъянил с гугл почты (а там ведь не дураки сидят).

К этой же категории бессмысленной траты долларов заказчика, нервов юзера, и циклов CPU относятся "валидаторы емейла". Если вам действительно так уж важно убедиться, что юзер действительно ввел реально рабочий емейл - для этого умными людьми давно изобретен хитромудрый способ под названием "отправить ссылку на этот емейл". Если же вы просто хотите проверить, что юзер понял, что от него требуется, и не ввел случайно в поле для почты свой телефон, вам поможет /^.*@.*\..*$/, а еще лучше /@/. Не надо лепить туда простыню с перечислением всех известных человечеству доменных имен, и цикломатической сложностью как у шахматного движка.

О да, верификация емейла - отдельная боль. Регулярно сталкиваюсь с тем, что мою почту с именем пользователя до @ длиной один символ какая-то очередная форма считает невалидной. Для таких есть alias подлиннее, конечно, но бесит.

Для верификации, кстати, можно ведь даже не отправлять письмо, а на лету проверять, что у домена MX запись есть, на 25 порту там нам отвечают и в ответ на RCPT TO:<email> не ругаются. Если пользователь нам важен, то так мы и страхуемся от опечаток в адресе, и исключаем лишний этап подтверждения аккаунта, который может пойти не так (письмо со ссылкой не дойдёт / попадёт в спам / пользователь забудет и т.п.)

Для верификации, кстати, можно ведь даже не отправлять письмо, а на лету проверять

А как застраховаться от того, что допустил опечатку (случайно либо намеренно), и вписал по факту ящик вообще другого человека?

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

Но, во-первых, так ли часто такая уверенность нужна?

Сбор ПД или данных основанных на ПД - золотая жила.

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

Если что-то пойдет не так с письмом верификации, то высока вероятность что те же проблемы возникнут и когда на этот е-мейл будет отправлена критически важная информация от сервиса (мы же для этого его запрашиваем?). Поэтому, ИМХО, лучше это сразу проверить на этапе регистрации.

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

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

Гениальные сберовцы в своём гигачате зарегистрироваться не дают, если в емейле встречается больше одного спецсимвола

и кто им сказал, что почты типа cber--bank@sbrf.ru не бывает ?

Почтовый сервер м.б. настроен так, что ошибка в [rcpt to] выдаётся после Data, из-за особенностей анти-спам системы. Или так, что ошибки на этапе smtp-сессии вообще не выдаются, чтобы не провоцировать спамеров на повторные попытки отправки. Если адресат ошибочен, в ответ потом отправится квитанция. Но потом. Да и без антиспама почтовый сервер имеет право не знать о существовании почтового адреса: данный mx может быть исключительно посредником, который только пересылает всю почту конечному почтовому серверу. Напрасно вы полагаетесь на ответ в [rcpt to].

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

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

И вот уже это не выглядит настолько бредовым. Хотя я не берусь судить насколько это эффективно.

На этот случай делают скриншоты экрана или даже запись видео

Ну из-за единиц ротозеев, которые имели неосмотрительность словить кейлоггер, заставлять ежедневно мучиться тысячи (а если это крупный банк - то и десятки/сотни тысяч) людей - так себе идея в любом случае. Лучше уж 2FA обязательную делать, тут один кейлоггер не поможет; а у кого и кейлоггер завёлся, и 2FA утекла - тому уже, скорее всего, не поможет вообще ничего...

Если бы ротозеев были единицы... Их же тысячи! И да, особо ушлые плохие парни явно целятся на обход 2FA, я правда, не знаю как они это делают. Но раз стараются - есть потенциал...

Вы недооцениваете количество ротозеев, сильно недооцениваете

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

Хорошая идея.
А пользователи кто с мобилок с тач-скринами — пусть ставят НашеПриложение.

Без хоть какого-то подтверждения того, что нажатие сработало, пользователь тоже не узнает, что он набрал. Хотя... есть же звук!

Ложные щелчки из динамика

Punto Switcher использовали в прежние времена как кейлоггер (при умелом конфигурировании). Причем, никакой антивирус на него не ругался.

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

* Лирика из песни или стихотворения

Классный совет: "как уменьшить энтропию, считая, что увеличиваешь её".

P.S. Хинт: количество стихотворений конечно и не так уж и велико.

P.P.S. У скольки хабровчан пароль "сОРОК ТЫСЯЧ ОБЕЗЬЯН В ЖОПУ СУНУЛИ БАНАН."?

о да, Чинга знает толк в придумывании паролей, хотя пароль Стрелка мне нравится больше. Интересно есть он в словаре?

Классный совет: "как уменьшить энтропию, считая, что увеличиваешь её".

"сОРОК ТЫСЯЧ ОБЕЗЬЯН В ЖОПУ СУНУЛИ БАНАН."?

Это ж база. А там можно и повыпендриваться.

$0R()k T1000_...

Удачи такое подобрать.

К тому же, если брать по первой букве от слова в случайном стихе, то получится почти случайная последовательность.

Вообще, общий совет такой: надо найти способ запомнить случайный набор символов. Или то, то запомнил превратить в случайный набор символов.

Надо найти способ запомнить случайный набор символов.

Есть такой способ, и вы его знаете!

Хм... Так-то поиск будет по словарям, так что энтропия будет меньше. Как правильно считать - не силён.

ЗЫ в интернете как-то не особо понятно, где сарказм, а где на серьёзных щах. Если я промахнулся - простите!

Если в языке всего 2048 разных слов — это 11 бит энтропии. Если слов четыре — то это 4 * 11 = 44 бита энтропии. Как Вы понимаете, в среднем человеческом языке сильно больше 2048 слов, так что это оценка снизу.

Секундочку! Давайте разбираться.

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

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

  2. Короткий пароль из большого алфавита.

Насколько большого? Ну, каждую букву мы можем представить в виде разных регистров (и, И), транслитерации (i, I) и замены по клавиатуре (b, B). Некоторые можем заменить на цифру( при желании можно и все). Итого имеем 11 * 6 = 66+ бит энтропии (это без учёта цифрового кодирования). Как видите, больше чем просто длинный пароль. Если ошибся - поправьте. И это я не говорю о других способах усложнения пароля (да хотя бы вставке). Правда пользователю придётся запоминать слово + паттерн преобразования, что действительно не так просто.

Из конструктива:

  1. Лучшая стратегия, безусловно, - быть не таким, как все. Правда 8 млрд человек не могут быть уникальными, так что это недостижимо впринципе.

  2. Что-то есть в подходе, когда у пользователя есть выбор: короткий сложный пароль или длинный попроще. Кому что проще запоминать, получается.

Проблема не в том, что "сложно придумать сложный пароль", а в том, чтобы "запомнить сложный пароль". Приснопамятный "верно батарея лошадь скрепка" запоминается гораздо легче, протому что оно элементарно визуализируется как ситуация, в отличие от "jWm8a&1X7".

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

Самую мякотку-то и не рассказали. Не уверен, что до сих пор актуально, но у Interbase/Firebird пароль мог быть любой длины, но использовались только первые 8 символов. В связи с чем даже дефолтовый пароль "masterkey" был не совсем верным, т.к. достаточно было "masterke".

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

Много лет назад столкнулся с этим, причём для доступа из консоли "masterkey" не подходил. Думал сменили дефолтный, пока на просторах интернета случайно не наткнулся на ограничение в 8 символов.

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

С 3 версии есть выбор: либо оставить старый формат с максимальной длиной пароля в 8 символов, либо перейти на новый, в котором максимальная длина пароля ограничена 20 символами. Если сервер установлен на Windows, можно использовать Windows-авторизацию. Ну и для каждой базы можно определить свои методы аутенификации: одной оставить старый формат, для другой – использовать Windows-авторизацию...

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

Насколько это вообще актуально про радужные таблицы? Баловался перебором лет 15 назад, уже тогда это казалось глупостью забивать диск хламом когда видеокарты перебирают миллиарды хэшей в секунду, а с тех пор так только ленивые и совсем злоумышленники не обновили еще алгоритмы или хотя-бы не засолили хэши. Да и вроде как 12 лет уж как все используют стратегию словарь+замены которая выявляет 95%+ паролей.

Хотел выразить несогласие, но по ходу написания понял что и нечего выражать. Для md5 со скоростью перебора в 50 миллиардов комбинаций вряд ли нужны радужные таблицы, а у тех кто использует что-то более новое скорее всего хэши солёные. Но подозреваю что могут быть кейсы, когда используется несолёный SHA2-512 или что-то еще круче.

Пару лет назад мы запускали на кикстартере похожий проект. Делали пластиковык карточки и стикеры с сеткой символов. Получилось неплохо. Я до сих пор пользуюсь

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

Подскажите, пожалуйста, далёкому от темы, что значит солёные хэши?

Приставка рандомная к паролю. Скажем, если у нас хранится просто хэш в поле password то у всех у кого одинаковый пароль - одинаковый и хэш будет. А там делаем что-то в стиле SELECT * FROM users WHERE password = hash('password') и получаем всех пользователей у которых пароль - password. Чтобы усложнить жизнь взломщикам, просто добавляем колонку salt где храним для каждой записи случайный набор символов который приклеиваем к отправленному юзером при сверке. И теперь у двух пользователей с паролем например тем же password, данные в базе будут выглядеть примерно вот так.

user_id   password                salt
1         (хэш от passwordJ9N%z)  J9N%z
2         (хэш от password4D#oR)  4D#oR

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

По большому счёту в базе просто хранится

user     password
wasya    J9N%z:(хэш от passwordJ9N%z)
petya    4D#oR:(хэш от password4D#oR)

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

Пароль должен значительно отличаться от предыдущих паролей пользователя

Получается, система хранит предыдущие пароли в открытом виде, чтобы сравнить "значительность"?

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

Опция, что солёные хеши предыдущих Х паролей хранятся и с ними происходит сравнение скорее всего-таки реализована. Вопрос был именно к слову "значительно". Вижу четыре варианта:
- Хранение хеша предыдущего пароля + хешей всех паролей, которые могут быть получены путём изменения одного символа в предыдущем. Маловероятно, ибо требует много излишнего места.
- Анализ пароля при помощи ИИ, который скажет какие наиболее вероятные изменения в его составе (например, вместо "Password1" будет "Password2") и хранение только этих хешей. Маловероятно, ибо требует излишней вычислительной работы с не очень внятным результатом.
- Ввод предыдущего пароля в плейнтексте и сравнение нового пароля именно с ним. Вероятно, но тогда перевод некорректный - не "от предыдущих", а "от предыдущего".
- Требование "должен значительно отличаться от предыдущих" прописано только в условиях и никак не проверяется. Максимум - проверяется совпадение с предыдущими Х паролями

Ну один предыдущий обычно запрашивают плейнтекстом вместе с 2 раза введенным новым в момент смены.

это решается простым сравнением хеша "плейнтекста" и того, который есть в базе

Необязательно в открытом. Хешируется новый пароль и уже хеш нового пароля сравнивается с хешом старого пароля.
Я бы так делал)

Вы бы так делали, потому что мало что знаете о хэше. Различие строки даже в одном знаке даст вам совершенно другой хэш. Вот md5-хэши двух "паролей", password1 и password2:

7C6A180B36896A0A8C02787EEAFB0E4C

6CB75F652A9B52798EB6CF2201057C73

Очень похожи?

Из классики:

Ваш пароль используется уже более 30 дней, необходимо выбрать новый!
- Розы.
- Извините, в вашем новом пароле слишком мало символов!
- Розовые розы.
- Извините, пароль должен содержать хотя бы одну цифру!
- 1 розовая роза.
- Извините, не допускается использование пробелов в пароле!
- 1розоваяроза.
- Извините, необходимо использовать, как минимум, 10 различных символов в пароле!
- 1гребанаярозоваяроза.
- Извините, необходимо использовать, как минимум, одну заглавную букву в пароле!
- 1ГРЕБАНАЯрозоваяроза.
- Извините, не допускается использовать несколько заглавных букв, следующих подряд!
- 1ГребанаяРозоваяРоза.
- Извините, пароль должен состоять более чем из 20 символов!
- 1ГребанаяРозоваяРозаБудетТорчатьИзТвоейЗадницыЕслиТыНе ДашьМнеДоступПрямо**дьСейчас!
- Извините, но этот пароль уже занят!

Зашла проверить наличие этого комментария.

Последняя строчка должна быть - Ваш пароль используется уже более 30 дней, необходимо выбрать новый!

Некоторые требуют вводить пароль только мышкой

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

Еще у них все интернет-провайдеры устанавливают пароли в 16-20 символов на маршрутизаторах, передаваемых клиенту при подключении. И по барабану, что те почти поголовно сразу же меняют их на гораздо более простые.

выбирая шесть из десяти цифр

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

  • Пароль должен значительно отличаться от предыдущих паролей пользователя

И как это можно контролировать если хранить хеш?

как вариант — хранить десяток/другой хешей по частям пароля. И при совпадении скажем половины — ругать за "похожий" пароль. Ну и общий хеш для сравнения само собой остается.

А хеши к таким половинкам пароля подбирать не проще будет?

а где их взять и зачем это делать? Если слили базу? Да, вероятно это могло бы помочь, не спорю. Хотя вы изначально не знаете их порядрок, так что врядли поможет сильно… Да и если слили базу — то всеравно пароль рекомендуется менять

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

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

Помню после регистрации на одном сайте, мне мой введённый пароль на почту прислали.

На одном??? "Да их тут тысячи!!!" (c)

Вот как нужно:


openssl rand -base64 64


GvdSQ/9N8UY8fecl0si6LnsJWmuPA1U4ryjI/MEyZHF25s74e6uDkYBMotikGfCO
YRpUVG21RbRnVQZt5ahZMA==

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

На счёт похожести с предыдущим паролем верно заметили - а как хранить-то.

Решение давно найдено: меняем пароль на "старыйпароль1", тут же на "старыйпароль2", потом на "старыйпароль3" и так далее, и в конце обратно на "старыйпароль"

Наиболее упёртые сайты сдавались итерации так на восьмой.

"Меня зовут О и Капитан Смек молодец а кто не согласен тот пумп1"

И в конце единичка...

В статье правильно упоминается cost factor и соль, поэтому все остальные требования попросту избыточны. А если юзер выбирает 123, то он сам себе злобный буратина.

Sign up to leave a comment.