Это утверждение безосновательно в общем случае, но на первый взгляд впринципе да.

Ну если при этом накладывать требование не минимальную длину то да

Хотя так юзер вообще взбесится если не поймет критерии

Тоесть такие функции определяют какая СУБД используется?

Потому что энтропия короткого простого пароля меньше чем короткого сложного

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

Если не хотим оказаться сожранными конкурентами :)

зачем вообще пароль заставлять ставить, пусть об этом пользователь думает

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

Я не понял смысла утверждения если честно ☺️

паролем может быть ascii art, пароль записанный вертикально и эмоджи ? ♨️ ?

брутфорс

На скорость брута все равно влияет

потому, что защиту от перебора пароля писать тебе.

Ну ты ненавидишь, а сотни хомячков были спасены :)

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

а я как пользователь пользуюсь менеджером паролей

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

а настолько ли для пользователя был ценным этот ресурс?! ты смотришь только с 1 стороны.

а настолько ли для пользователя был ценным этот ресурс?! ты смотришь только с 1 стороны.

Не всякий пользователь может осознавать ценность ресурса

для этого нужно знать, что украли

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

а я думаю о всем и сразу, а не надеюсь на что-то одно

> это последнее о чем вы должны думать Вот да, а это читается как "если у нас украдут базу то мы просто поднимем лапки а остальное пусть дяди в руководстве разгребают"

Время на брут будет существенно выше для сложных паролей и больше данных будет спасено. Мы выигрываем время.

Не всякий пользователь может осознавать ценность ресурса

самообман думать, то что ты умнее пользователя.

во-первых, ты не сразу узнаешь, во-вторых, у пользователей часто одинаковые пароли на разные ресурсы

самообман думать, то что ты умнее пользователя.

самообман думать, что пользователи в массе умнее

время подбора, говорят дек

если он подбирается за день - хреново, если за пару лет - норм

> мы про это не знаем Тут надо думать в терминах "не знаем в течение часа, недели, месяца, года"

самообман думать, что пользователи в массе умнее

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

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

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

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

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

Думать что любая бабулька в сбербанке при вписывании пароля просчитывает его энтропию тоже странно, и более того мы уверенно знаем, что не просчитывает :)

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

так и разработчики тоже не владеют всеми необходимыми знаниями

а соль и должна быть индивидуальна, но это не защищает от подбора одного пароля

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

печаль :(

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

Или так или длина в 25 символов :)

Ссылка на источник экспертизы - картинка с лошадью :D

можешь считать меня и Павла экспертами :) если недостаточно - то гугл

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

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

Или так или длина в 25 символов :)

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

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

вообще я страдаю

вообще я страдаю

просто приложи :-Р

ну там лимит... и опротестование по разному идёт

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

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

опротестование с пином ты почти гарантированно проиграешь

ну и да, это по сути двуфакторка

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

все прекрасно ибо магазин на себя риски берет

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

я тебе показываю то, что мир чуть сложнее и быстрые, простые советы "бери Х символов" не применимы

я тебе показываю то, что мир чуть сложнее и быстрые, простые советы "бери Х символов" не применимы

Не, это я тебе показываю :)

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

ERROR: S client not available

опротестование с пином ты почти гарантированно проиграешь

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

опротестование с пином ты почти гарантированно проиграешь

опротестация может быть проведена дважды если что

Народ а когда вы последний раз в phpStorm делали Tools -> Analyze XDebug Profiling results? Кто нибудь знает как сделать так чтобы JUMP TO Source работал?

Не, это я тебе показываю :)

кажется в твой голове ты споришь с виртуальным Я и естественно мое Я проигрывает )

Народ а когда вы последний раз в phpStorm делали Tools -> Analyze XDebug Profiling results? Кто нибудь знает как сделать так чтобы JUMP TO Source работал?

давно, вроде там от уровня профайлинга (вроде их 4) зависило. не помню детали.

давно, вроде там от уровня профайлинга (вроде их 4) зависило. не помню детали.

спасибо буду рыть сейчас

кажется в твой голове ты споришь с виртуальным Я и естественно мое Я проигрывает )

Чего ты хочешь доказать то? Что не нужно давать ограничения на длину пароля и это будет статистически безопаснее чем с ограничением?

спасибо буду рыть сейчас

возможно путаю с xdebug.collect_params

давно, вроде там от уровня профайлинга (вроде их 4) зависило. не помню детали.

https://xdebug.org/docs/profiler блин чтото тут нету ничего про "уровень профайлинга"

Чего ты хочешь доказать то? Что не нужно давать ограничения на длину пароля и это будет статистически безопаснее чем с ограничением?

только то, что длина пароля не определяет безопастность пароля сама по себе.

Спасибо кэп, прямо как в анекдоте про математиков на воздушном шаре ?

Точнее вне воздушного шара :D

https://xdebug.org/docs/profiler блин чтото тут нету ничего про "уровень профайлинга"

в самом файле должна быть информация о расположении файлов в файловой системе. cat делал?

Спасибо кэп, прямо как в анекдоте про математиков на воздушном шаре ?

если я кэп - то почему на очевидну мысль пришлось столько сообщений?! (можно не отвечать - в любом случае ответ будет скучным)

если я кэп - то почему на очевидну мысль пришлось столько сообщений?! (можно не отвечать - в любом случае ответ будет скучным)

Ну потому что эта мысль идет параллельно с дискуссией и ее и так все знают. Вопрос не в том, определяет ли ТОЛЬКО длина пароля его безопасность, а совсем в другом - кому больше нужно вводить ограничения на пароль - пользователю или сервису.

Ну потому что эта мысль идет параллельно с дискуссией и ее и так все знают. Вопрос не в том, определяет ли ТОЛЬКО длина пароля его безопасность, а совсем в другом - кому больше нужно вводить ограничения на пароль - пользователю или сервису.

к сожалению эту мысль от начала и до конца можно увидеть только сейчас.

Не только лишь все могут смотреть в эту мысль от начала и до конца.

Ну потому что эта мысль идет параллельно с дискуссией и ее и так все знают. Вопрос не в том, определяет ли ТОЛЬКО длина пароля его безопасность, а совсем в другом - кому больше нужно вводить ограничения на пароль - пользователю или сервису.

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

в общем контекст важен, это факт

Но думать контекстом - это сначала просто думать нужно научиться, в смысле понять что и зачем

хреново сделать всегда просто, сначала хорошо делать научиться нужно

Значит нам нужно обрисовать контекст сперва (в конце концов). У нас есть проект с веб-интерфейсом, где может аутентифицироваться пользователь. Пользователей много, от миллиона и больше. Причем пользователи в своей массе некомпетентные, им плевать на длину пароля и энтропию, в случае чего они выписывают пароль на бумажку и клеят рядом с монитором. Пароли могут быть записаны в ворде, вставляться оттуда, еще пароль надо набирать с мобильного телефона. Если пользователь не может залогиниться весь день, то он оставляет гневный отзыв на яндексе, перестает платить 5$ в месяц и навсегда уходит с сервиса. Базу данных иногда крадут, и выясняется это только через неделю, после того как безопасник вернулся из отпуска на мальдивах. Если базу данных украли то пароли начинают брутить, а затем заходить в аккаунты и перекидывать цифровые товары на другого перса (броню, мечи или там шкурки для оружия). Алгоритм хеширования - sha512 с солью, а соль хранится в соседней колонке в таблице. Вопрос - надо ли позволять таким пользователям вводить непечатаемые символы и эмодзи, и надо ли ограничивать минимальную длину пароля? Вопрос со звездочкой - при изменении каких вышеперечисленных условий становится надо или не надо это делать?

ребята, подскадите как в Ларавел сделать авторизацию (ту, что из коробки artisan make:auth), но на кастомных урл (/customer-account /manager-account) и как назначить тип пользователя - клиент или менеджер и клиентам позволять авторизироватся только в /customer-account, а менеджерам в /manager-account и если кто-то из них будет авторизироватся не на своих урл - то выдавать ошибку, что данному пользователю не позволено авторизация по данному урл. Наверное там много правок нужно вносить и это сложный процесс(

ребята, подскадите как в Ларавел сделать авторизацию (ту, что из коробки artisan make:auth), но на кастомных урл (/customer-account /manager-account) и как назначить тип пользователя - клиент или менеджер и клиентам позволять авторизироватся только в /customer-account, а менеджерам в /manager-account и если кто-то из них будет авторизироватся не на своих урл - то выдавать ошибку, что данному пользователю не позволено авторизация по данному урл. Наверное там много правок нужно вносить и это сложный процесс(

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

я не прошу кого-либо писать за меня код.. сам разбирусь.. просто может кто-то уже сталкивался.. могли бы подсказать направление где копать..

я не прошу кого-либо писать за меня код.. сам разбирусь.. просто может кто-то уже сталкивался.. могли бы подсказать направление где копать..

гитхаб - там и копай