Yeah, I agree that aspect of it seemed quite problematic to me as well from the beginning. And he obviously cannot include the email in the hash. So it’s better to just disallow the top x most common passwords, which we already have. (Though it’s not updated on the fly as the list changes over time.)
2 лайка
What would really solve the issue here, in my humble opinion, would just to apply best practices like preventing an IP to try to login more than X times without success, don’t let people try passwords at non human time ( humans don’t try a password every 1 sec ) would fix the security issue without forbidding all the passwords.
The way I see is, someone can make a list that gives all the combinations of A-Z 1-9 up to X length. This means nothing if you can’t brute force the target, unless it’s a targed attack and then there’s not much you can do.
Is anything like that currently implemented?
Yes, there is extensive rate limiting across the whole of Discourse. By default login attempts are limited to 6 per minute and 30 per hour (per IP).
9 лайков
Hmm, can you extrapolate here though? It would seem to me that the distribution of lengths might be quite different if you focus on the 1 mil most common ones since those will obviously tend to be shorter.
1 лайк
I think it’s a good idea to alert the user but maybe not prevent them from using the password if they insist. Explain it better, maybe something along the lines of
“The encrypted version of this password has been found in a public database of stolen user information and may put your account at increased risk of being hacked by brute force attacks. If you use this password across multiple web services we strongly recommend changing them to unique passwords to stay secure, especially for mail accounts.”
And let them hit submit a second time to use it anyway.
hopefully webauthn will make passwords a thing of the past someday 
2 лайка
Для меня это не имеет смысла (отсюда и поднятие темы): как только известно, что пароль был взломан (или найден в открытом виде), его безопасность значительно снижается. Это представляет собой огромное снижение энтропии даже при очень мягких допущениях:
- случайный пароль из 10 символов, даже с очень ограниченным набором символов (пример-страшная история: только строчные буквы: Pr = 1/26^10 = 1/1,4e14)
- пароль, который, как известно, присутствует в списке HIBP (Pr = 1/5e8)
В ту же секунду, когда кто-то другой его использовал и он также был скомпрометирован и/или расшифрован — это ключевое различие.
В чём практическая проблема запрета пароля, который встречался лишь в одном списке? Как пользователь, я определённо хотел бы об этом знать, чтобы не использовать этот пароль снова. Как администратор сайта, я не хочу, чтобы мои пользователи использовали скомпрометированные пароли. Это, по-видимому, стоит того компромисса с удобством использования.
Нет, это не ключевое различие, потому что статистически все пароли со временем будут скомпрометированы.
Помните, что мы уже блокируем топ-миллион самых распространённых паролей и делаем это уже несколько лет, поэтому вы уже защищены в тех аспектах, которые действительно важны.
3 лайка
Статистически все криптографические алгоритмы и алгоритмы хеширования со временем будут взломаны. Как только появляются первые признаки того, что алгоритм близок к взлому, мы прекращаем его использование.
Почему пароли должны быть исключением? Вся безопасность — это ставка на то, что используемая энтропия достаточна для поставленной задачи, и всегда есть предположение о длине или интенсивности атаки, которую можно выдержать.
Учитывая, что при первом появлении пароля в списке теряется как минимум 6 порядков энтропии (в реальности — вероятно, ещё больше), это кажется лёгким решением.
Да, это гораздо более выгодная ситуация по сравнению с тем, что предлагают многие другие программные пакеты на сегодняшний день. HIBP всё ещё является хорошим улучшением для сайтов, которые хотят дополнительных гарантий поверх этого.
Похоже, это возможность добавить кнопку «Сгенерировать парольную фразу» через плагин, если это технически осуществимо…
Это исключало бы всё из списка pwned, а пользователь мог бы выбрать создание собственного пароля, в который уже встроён «базовый» список исключений из 1 млн записей. Метод с кнопкой позволяет обойтись без необходимости объяснять пользователю, что такое списки pwned и энтропия, на что у них обычно нет времени.
Хотя, на мой взгляд, Discourse уже справляется с этим вполне неплохо.
Зачем генерировать пароль на сервере?
Если пользователю всё равно нужно его сохранить, не логичнее ли доверить генерацию пароля самому пользователю? Его менеджер учётных данных, скорее всего, уже выполняет эту функцию.
2 лайка
Потому что это может быть лучше, чем постоянно сообщать пользователям, что варианты вроде apple, apple1, apple 123, apple 12345 недопустимы согласно списку из 1 миллиона запрещённых паролей. Лично я не очень ожидаю наличие такой функции в Discourse, но если это позволит более изящно решить проблему с скомпрометированными паролями и оставит решение на усмотрение пользователя в случае сбоев, то, возможно, стоит это рассмотреть.
И вы предлагаете, что менеджеры паролей на стороне клиента будут генерировать пароли вроде этого?
Рекомендовать пользователям использовать менеджер паролей будет гораздо эффективнее, чем требовать пароль от одного конкретного сайта. Последнее лишь приведёт к тому, что они будут использовать этот пароль повсюду, что ускорит его компрометацию.
Исправить глупость сложнее, чем исправить взломанное. Предложение, похожее на https://www.useapassphrase.com/, даёт тем, кого не интересуют академические аспекты, хоть какую-то возможность, на мой взгляд.
Я создал системы, которыми пользуются десятки миллионов человек, и мы опробовали различные подходы к паролям, включая те ужасные требования вроде «должен содержать символы x и y».
Если вы не обучаете пользователей управлению паролями, вы лишь повышаете вероятность усталости от паролей, их повторного использования и пресловутого «стикера под клавиатурой».
Генерация паролей на стороне сервера также создаёт новый вектор атаки и поверхность, которую необходимо защищать. Лично я мог бы обойтись без всего вышеперечисленного.
3 лайка
Мне казалось, что JS будет генерировать парольную фразу случайным образом на стороне клиента, затем хешировать её и сравнивать со списком. Часть про обучение может быть заглушкой над кнопкой «Создать пароль». Честно говоря, мне не кажется, что Discourse вообще должен заниматься подобными вещами, но, возможно, стоит это рассмотреть, пока люди продолжают приписывать свой гнев, вызванный собственным поведением, бренду.
В таком случае, думаю, вам лучше всего разработать или заказать плагин, который делает то, что вы предлагаете.
1 лайк
Это именно то, для чего и предназначен этот плагин.
Я поразмыслил над этим некоторое время после написания этого плагина и в итоге согласился с Джеффом.
«Взломан» означает, что где-то кто-то придумал эту фразу, которая появилась в «списке». Представьте, если бы кто-то создал инструмент, который:
- Публиковал список строк.
- Систематически генерировал уникальные строки и добавлял их в этот список.
Аргумент Джеффа заключается в том, что в конечном итоге все строки станут «небезопасными», потому что они появятся в каком-то публичном списке, и рано или поздно ваша «супербезопасная» парольная фраза тоже окажется в этом постоянно расширяющемся списке.
Сама идея паролей опирается лишь на «статистическую невозможность» того, что кто-то не сможет угадать пароль от вашего аккаунта. Атакующему технически не нужно знать пароль — ему нужно просто сделать очень хорошее предположение. Они могут сыграть себе на руку, используя то, что значит сделать «хорошее предположение»:
- Если у них есть данные утечки, попробуйте тот же пароль для того же аккаунта.
- Если у них есть список утечек, попробуйте пароли, которые используют многие люди.
Мы уже обсуждали, что Discourse хорошо справляется с пунктом №2 выше. Я полагаю, вы пытаетесь решить проблему пункта №1, но внедрение чего-то подобного в ядро (предполагая, что любой пароль, не привязанный к имени пользователя, не должен использоваться) — это излишество и кошмар для удобства использования. Однако если вы хотите реализовать описанное вами для своего сайта, этот плагин именно для вас.
4 лайка
Да. Честно говоря, это ужасный аргумент, поскольку он полностью оторван от любого понятия вероятности, которое является единственным правильным способом рассуждать об этом.
К счастью, мы говорим о частном случае, который возникает уже после исключения наиболее часто используемых паролей, что само по себе является довольно хорошей стратегией.
1 лайк