Как стать автором
Обновить

Комментарии 26

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

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

Полностью согласен. В данном случае пароли пришлось генерировать для MySQL с плагином validate_password.


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

Вообще, даже для людей, необходимость ограничивать содержание пароля очень спорна.


Потому что требования выполняются (обманываются) просто, а проконтролировать сложно. Например пароль "Qwer12!@" выполняет все требования, но не безопасен.


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

Не рекомендую идти таким путем, т.к. пользователи идут по пути наименьшего сопротивления. Будут всегда максимально простые, а-ля Anna1981, Moscow2014 и др. Казалось бы хорошие пароли и цифры есть и символы из разных регистров, но вот словарная атака, которую так любят при брутфорсах очень быстро найдет!
Справедливости ради, словарные атаки и брутфорсы имеют смысл только когда есть хэш, онлайн это сделать исключительно трудно — вводим ограничение на три попытки с интервалом не менее 3х секунд, потом даём ещё две попытки с интервалом в 15 минут (этого обычно хватает чтобы память у забывчивого пользователя прояснилась), потом лочим аккаунт (и все IP которые пытаются в этот аккаунт) на сутки и уведомляем пользователя. Если это был он сам, забывший пароль — либо использует функцию восстановления, либо обратится в поддержку, зато всякие ботнеты идут в пень.
НЛО прилетело и опубликовало эту надпись здесь

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

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

пфф… Вам просто не попадались сервисы, которые требуют пароль не длиннее какого-то кол-ва символов (а значит под капотом скорее всего хранят в plain-text в базе)

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

Разумное ограничение на длину должно быть, всё же — 50-60 символов хватит на небольшую фразу, пусть 100 (если учесть utf8) — но выше уже как-то слишком много, особенно если учесть что реально рандомный пароль в 16-20 символов напрочь убивает возможность перебора за адекватное время.
Вам просто ещё не попадались люди которые пытаются в качестве пароля отправить строку в пару килобайт, причём иногда даже с кодами ниже пробела — отсюда и ограничения.

А в чем проблема??? Включительно с кодами ниже пробела. Нормальный софт должен обрабатывать такое нормально. И если пароль совпадает, просто предоставить доступ.

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

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

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

И генераторов не пришлось бы особо писать.

Поддерживаю, политики безопасностей для паролей:


  • плохи для микросервисов, потому как как сказали выше, полностью случайный пароль лучше чем пароль с ограничениями
  • плохи для пользователей, потому что получаем пароли вида vasya98A!
(~30 знаков lowercase и пробелы)

33 кириллических знака и 6 пробелов? Я знаю этот пароль, и он — словарный.
У Чингиза был лучше. Это и есть Чингиза… но кто-то точно упоминал монгольское сено.

Нет, он не словарный.
Но отсылка хорошая, да.
702 килограмм?
Мне ещё нравится генератор «произносимых» паролей, чтобы их можно было читать и произносить без сложностей и не спотыкаясь на спецсимволах и сложночитаемых сочетаний. Всегда стараюсь такие придумывать пользователям. Например 'Swood-Rende0202'.

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

Жаль не весь софт (привет, keepass) умеет генерировать такие.
Да, мне тоже. Лет -дцать назад такое сделал, до сих пор пользуюсь. Особенно, если для всех спецсимволов подразумевать какую-нибудь мнемонику (например, "_lets" — подлец — тут знак подчеркивания читается как «под», восклицательный знак, понятно, как «не» итд), плюс пароль генерится с учетом фонетики, т.е. чередование гласных/согласных, редко где больше 2-3 гласных/согласных подряд. В общем, при очевидной потере чистой рэндомности, можно делать пароль в разы длиннее при отличной запоминаемости.
Vipnet Password Generator так умеет, раздаётся бесплатно :))
Keepass (вторая версия) вполне себе умеет, через аддоны. Их там несколько вариантов.
1. Выбираем некоторое к-во (не меньше 1, но так, чтобы осталось достаточное место для других символов) строчных букв.
2. По тому же принципу выбираем прописные буквы и цифры.
3. Остаток заполняем спецсимволами.
4. Тасуем последовательность символов.

Только зачем? Для людей такой пароль будет незапоминаем. Для машины — бесполезен.

Возможно, предсказуемые и легко подбираемые пароли получаются. Ведь предупреждают об этом.
Warning The pseudo-random generators of this module should not be used for security purposes. For security or cryptographic uses, see the secrets module.


Если не хочется secrets, тогда лучше использовать класс SystemRandom.
The random module also provides the SystemRandom class which uses the system function os.urandom() to generate random numbers from sources provided by the operating system.

Хм. А вызывать apg с парой ключей не было-бы проще?
В принципе я за прикладное велосипедостроение, но...

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации