Pull to refresh

Comments 47

А я использую старую программу ADvanced Password Generator, которая генерит запоминаемые пароли.
а можно попросить выложить ее куда нибудь?
Не совсем понятно — название статьи «Как сделать пароль надежным и запоминающимся», при этом у вас все пароли сводятся к «nsmsms=3-25=j3», что, безусловно, надежно, но не запоминаемо. «bananaapple» — запоминаемо, но совершенно ненадежно…
Получается, вывод к заголовку статьи — никак (что, в общем-то истинно, хотя у вас другой посыл был).
Получается, вывод к заголовку статьи — никак (что, в общем-то истинно


Нет, не истинно.
Вы считаете, что correcthorsebatterystaple, который подбирается за 8 часов — надежный?
Больше всего в этой картинке, которая непонятно почему-то разошлась огромными тиражами по интернетам, нравиться «да взлом украденного хеша быстрее, но среднестатистический пользователь не должен об этом беспокоиться» — пользователь именно об этом и должен беспокоиться, т.к. чаще всего тащут именно базы хешей.
Пользователь не может повлиять на выбор алгоритма хеширования, поэтому его беспокойство об этом будет бесполезно.
Многие из этих советов ломаются о «заботу веб-ресурса о безопасности пользователей». Когда в ответ на предложенный пароль поочерёдно выскакивает:
— пароль слищком короткий, должно быть не менее 8 символов
— пароль слишком простой, должна быть хотя бы одна буква
— должен быть хотя бы один диакритический знак

а потом ещё до кучи:
— пароль слишком длинный
и т.п.

Вроде как о безопасности заботятся, но тем самым вынуждают меня ломать собственный паттерн генерации паролей. Так что почти гарантированно я его забуду — и какая же тут нафиг безопасность?
Ага, разработчики, которые ставят ограничение на длину пароля, или ставят запрещенные символы в нем, должны гореть в аду.
Да и городит каждый свой велосипед. Неужели нет какого-нибудь стандарта, предписывающего правила безопасных паролей, которые все должны использовать на сайтах по умолчанию?
На Юниксах уже давно такой стандарт имеется — cracklib.
Вариант, когда нужно много сложных и разных паролей решается программой, где можно генерировать и хранить все нужные пароли.

И крайне надежный и простой вариант — использование в качестве пароля словосочетания или даже предложения.

Например пароль «Рождественское утро 2015» (294 bits). Запоминается элементарно, подбирать сложно. Единственная проблема остается — различные пароли для разных сайтов. Но тут можно выкрутиться «Рождественское утро 2015 нф.кг», например. Вот такие способы нужно продвигать в массы активнее всего. Да и вариант «banana-16-q1» тоже по словарю не подобрать уже и придется перебором действовать. Единственное, что некоторые сервисы умудряются еще ограничить максимальную длину пароля. Словно они собираются хранить его в сыром виде и им важно знать длину.

Стандарт бы на эту тему какой-то сделать общепринятый.
Добавление к своему сложному паролю окончания сайта (сервиса) мне кажется плохой практикой. Если один из паролей будет уведен, то остальные могут быть подобраны. Например, забылись и залогинились в кафе с вайфая на vk.com c паролем «Рождественское утро 2015 vk.com». Злоумышленник будет очень рад когда обнаружит, что «Рождественское утро 2015 gmail.com» то же работает.

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

Всего в памяти два пароля: база keepass и Gmail (с двухфакторной авторизацией).
Согласен, что тут стоит еще поломать немного голову над тем, чтобы уменьшить распознавание. Я бы сам не стал вводить обычный адрес сайта (хотя даже на этом уровне большинство получит огромный прорыв по сравнению со своими простыми паролями, используемыми везде в неизменном виде). Логику привязки к сайту можно немного доработать, как предложено в топике. А можно брать только какую-то часть — «2 символа + зона». Но в случае попадания такого пароля в руки злоумышленника, мы действительно сильно упрощаем задачу как минимум для перебора. Если известная статичная часть, то подобрать небольшой хвостик не сложно.

Про KeePass абсолютно согласен. У меня паролей 300 и все разные. Ни один я сам не знаю. Единственное узкое звено — сама база.
Хватит вводить людей в заблуждение этой картинкой! correcthorsebatterystaple подбирается за 8 часов на стандартном железе.
Можно назвать это стандартное железо, способное перебирать 36 миллиардов паролей в секунду?

В статье выше, если что — более слабые пароли.
Если основываться на zxcvbn, то за 8 часов подбирается хеш для «correcthorsebatterystaple» со скоростью 10 млрд. в секунду (а эту скорость перебора может обеспечить даже среднего уровня GPU) — пруф (описание кластера из 25GPU мощностью 348 лярдов\сек).

Вы можете сослаться на «пробел» между словами. Но в специальной атаке на данный тип паролей это не играет никакой роли. Тогда мы начнем заменять пробелы спец-символами, но тогда мы уходим от постановки «надежный и запоминающийся пароль» в «надежный и не запоминающийся».
Я не про железо клиента. Я про железо сервера, способного выдержать 36 миллиардов запросов в секунду. Да, база может утечь, но тогда ломать bcrypt. Пример с windows-паролями не сильно применим к нормально реализованным системам.

Пробелы между словами роли в correct horse battery staple не играют. Это — случайные 4 слова из словаря в 2048 слов, по символам они не подбираются (иначе время подбора было бы астрономическим). Комикс предполагает, что у атакующего точно тот же словарь и он знает алгоритм составления пароля.

В статье алгоритм чуть сложнее, но если атакующий узнает алгоритм (например, утекут plaintext пароли с 2-3 сайтов) — он запросто подберёт пароль к остальным, поскольку бит случайности около нуля. Это security through obscurity.
Комикс призывает пользователей использовать пароли из, как вы сказали, «случайных 4 слов из словаря в 2048 слов».
При этом отмечая, что «взлом украденного хеша быстрее, но среднестатистический пользователь не должен об этом беспокоиться».
Но по печальной тенденции, именно об этом пользователю и нужно беспокоиться больше всего.

Вариант с перебором отправкой запросов серверу вообще кажется дикостью, едва ли данный метод вообще используется «серьезными кибер-преступными сообществами».
По печальной традиции пользователю стоит еще беспокоиться о том, что его пароли могут лежать в базе в открытом виде, вообще. Но какой смысл в этом, действительно? Если база утекла, то все, очевидно, что пароль нужно менять в любом случае. А чтобы подобные проблемы не вызвали катастрофические последствия, нужно позаботиться, чтобы пароли на всех сайтах были разные.
По поводу bcrypt — далеко не всегда даже просто соль используется при хранении, не говоря уже об адаптивных свойствах шифрования. Тот же Drupal, например, использует по умолчанию просто SHA с солью, утверждение «тогда ломать bcrypt» — весьма далеко от реальности.
zxcvbn как-то странно считает энтропию.
Например, пароль fmbftpcntp — это 10 симвловов, мощность 26^10 ~ 10^14
А калькулятор этот пишет guesses_log10: 10
Сам спросил — сам ответил:
github.com/dropbox/zxcvbn/commit/d20704b7328b10ec6eef0e4b204893c1a8e6ed0a
Цифра занижена, т.к. на практике придумываются не случайные пароли, а пароли, которые выглядят случайными. А брутфорсеры строят статистические модели и активно используют их при подборе. Простейший вариант — таблица вероятности появления символа от его положения в пароле (многие любят добавлять число в конец) или таблица вероятности появления символа от значения двух предыдущих символов (да-да, так называемые человеко-читабельные пароли)
Кажется такое мог нарисовать только гуманитарий. Не представляю, как можно запоминать сотни диких историй про говорящую лошадь и батарею со скобой. Неужели слово «правильно» в начале примера очевиднее замены символов? Расчёты сложности подбора тоже выглядят бредово, одно словарное слово должно примерно соответствовать двум символам из первого примера. Т.к. кто сказал, что общее слово в нём полное и осмысленное? Почему дополнение обязательно двузначное? Шаблонов может быто очень много, поэтому перебирать их в реальности бессмысленно и сложность будет 2^6^11 на самом деле.
Слово в первом примере считается словарным, ибо несловарное запомнят только роботы. Отсюда и расчёт числа бит: сейчас практически любой переборщик умеет искажать словарные слова подобным образом вместо того, чтобы делать честный брутфорс.

Вообще, этот комикс разобран десятки раз.
«сорок тысяч обезьян в жопу сунули банан» (с)
Сам генерирую разные пароли на всё и другим советую. KeePass отлично справляется с этой задачей, остается выучить и запомнить лишь один сложный пароль от базы данных с остальными.
Да. Но — работает до тех пор, пока не словишь трояна, заточенного на воровство паролей из KeePass.
Если словишь трояна, то и запоминание не поможет.
Есть разница между потерей вводимых паролей и потерей всех паролей. Поэтому я никогда не сохраняю пароли в браузере. Тем более, что большинство троянов не ставят кейлоггер, а просто собирают сохраненные пароли из известных мест.
Не понял, при чем тут браузер, мы говорили о KeePass.
А как троян похитит шифрованную базу паролей?
Да никто, из тех, кто пользуется менеджерами паролей, не сохраняет пароли в браузере.
Самый простой метод — пропатчить KeePass. Или exe-шник, или образ в памяти. Или, как вариант, все-таки использовать кейлоггер, который распознает окно аутентификации KeePass.
Самый простой?
Так для этого надо админские права, как минимум.
Исследователи использовали группы видеокарт, чтобы взломать восьмизначные пароли и пришли к выводу, что для этого достаточно двух-трех часов.

Да, но только для ресурсов, к которым есть полный и быстрый доступ (зашифрованные файлы/etc).
Сложная логика… Я делаю проще (раньше пользовался тоже apg, потом стало легче делать пароли самому): Берем любую программу по генерации pronounceable passwords (FIPS181 например умеет APG или LastPass), генерим 10-15 паролей длины 10 и более — нам нужны просто «pun» кусочки слов (которые звучат похоже на нормальные слова, но пишутся немного по другому):

veromytoribu *
aingernomper
omislectokah
roantermense *
oventiestute
isauncerinym
gularafghnol
stoadarymind *
inderidequac *

Копируем их в любой текстовый редактор и просматриваем — нам надо выбрать 3-4 понравившихся или ассоциирующихся с чем-то кусочка, длиной от 3 до 5 (или что вам удобно запоминать). Например из списка выше:

verom
quac
mense
darym

Потом составляем пароль следуя неким придуманым простым правилам типа:
1. Первое слово всегда с заглавной буквы.
2. Слова разделяются одной цифрой,
3. Если цифра четная или 7 — следующая буква тоже заглавная,
4. В конце ставим заглавную цифру (запоминаем как цифру но нажимаем с шифтом)

некоторые слова можно отредактировать немного для удобства запоминания изи заменить цифры на простые символы. Итого получаем:
Verom2Quac-mense1darym(

ну или если есть квакерское прошлое:
Veerom2Qaud-mense1daril(

Итого
0. Стойкий, проходит все проверки т.к. есть 4 типа символов, длина подбирается персонально, обычно получается не меньше 12-16 символов

1. Удобно произносится, легко продиктовать по телефону
«Veerom (two) Quad dash mense (one) daril (NINE with shift)»

2. Довольно легко запоминать, через 2-3 пароля вырабатывается ритм пароля при произношении в уме. Я помню некоторые пароли 2-3хлетней давности, которые уже не использую давно. Также создается некий набор ассоциаций в виде странного предложения, типа того же CorrectHorseBatteryStaple.

3. Можно некоторые слова или начала слов записать в password hint без особого компромиса безопасности имхо, я бы вписал что-то типа «v=>q-m1d9» — не дает много знаний о пароле но дает ключевые подсказки и позволяет быстро вспомнить пароль по составным словам.

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

5. Через некоторое время вырабатываются любимые pun слова, из которых собираете throw-away пароли для всяких сайтов на один раз.

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

Удачи и безопасности в сети.
Одна беда только.
Когда придумаешь хороший пароль со спецсимволами типа «DdfwW@A-gfFGH%*brfF),///\mnNc», то тебе тут же прилетает «Извините, ваш пароль недостаточно стойкий, потому что там нет цифр». Или: «Ваш пароль слишком длинный», или — «Извините, используются запрещённые символы»
И тогда все эти пароли из статьи типа «banana-16-q1» или «nsmsms=3-25=j3» не имеют смысла
Из-за того, что один сайт не даёт поставить удобный и надёжный пароль, не следует совсем отказываться от таких паролей.
Чтобы сделать пароль уникальным для каждого сайта (без необходимости его записывать) можно добавить название веб-ресурса в его конец.
Достаточно одного скомпрометированного пароля и все остальные станут пустышкой.
и все остальные станут пустышкой

Остаётся найти акки человека на других сайтах. Не все используют один ник везде.
… до тех пор, пока название веб-ресурса добавляется к сайту в неизменном виде.
Если производить какое-нибудь преобразование — желательно такое, которое легко выполняется, и при этом сложно разгадать алгоритм, зная только одну пару — тогда один утёкший пароль не скомпрометирует остальные.
Не нужно увлекаться преобразованиями. Сколько их можно придумать? Ну пусть 4000. Это равносильно дописыванию в конец пароля двух случайных символов.
Я вот чего не понимаю — почему все проблемы с безопасностью паролей валят на пользователей, а не на разработчиков сайтов?

Почему вместо использования стойкого алгоритма хеширования паролей (того же bcrypt) пользователей заставляют придумывать пароли от 8 символов с заглавными-строчными-цифрами-спецсимволами?
Почему я не могу использовать пароль из 4 символов для сайта, где ничего ценного нет и никогда не будет?
Почему мало кто делает систему обнаружения взлома аккаунта?

В качестве дешевого и сердитого метода можно использовать тот же OAuth2, где провайдеры сами управляют аккаунтами, а некоторые из них (тот же гугл) предлагают и двухфакторную аутентификацию.
Потому что единственная вещь, в которой может быть уверен пользователь — это то что он сам позаботился о своей безопасности. В большинстве случаев никаких методов контроля за тем, что делает разработчик у пользователя нет, поэтому сваливать безопасность паролей на разработчиков хоть и привлекательно, но совершенно неконструктивно. Кроме того, было бы странно читать рекомендации для разработчиков использовать OAuth2 в статье для пользователей, особенно учитывая то, что разработчики, не собирающиеся использовать OAuth2, никуда не исчезнут, равно как и то, что их сайты, тем не менее, могут быть полезны.
По первым буквам в любимом четверостишии стихотворения/песни. На другом сайте — другое четверостишье. А если еще с капсом и в английской раскладке — вообще секурно.
Sign up to leave a comment.