это не шутка

Это новые NIST-овские рекомендации. Кроме последнего - одинаковости. Для этого нужно ещё повсеместное внедрение Secure Remote Password. Почему за 20 лет он не взлетел не очень понятно(типа 2 конторы сказали «патентовано», и хотя ни разу не сказали что именно, все дружно испугались); похоже на заговор.

15-символьный полностью случайный пароль

7 слов из словаря в 13 тысяч(без падежей/родов/склонений и других whatewero-ов) как раз эквивалентны 15 полностью случайному ascii паролю. И его можно запомнить. Ожеговскому достаточно 6ти, но подозреваю, что большинство слов оттуда «никому» не понятны, т.ч. последнее исчезает.

10 млрд переборов

Всегда можно потребовать 1 секунду какого-то аргона на перебор, и это уже 31 год/размер твоей сети. 3 слова - 70000 лет/C. Сколько ботов стоит твой пароль?

1. Полностью безопасных способов хранения паролей не существует. С этим надо просто смириться.

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

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

хакер

Не употребляй это слово в таком смысле. Пожалуйста.

Для параноиков есть е-токены, RSA secureid, многофакторная верификация. В качестве шифр-блокнота для бедных можно использовать какую-нибудь книжку. Ключ - номер страницы, строки.

Для сайтов типа соцсетей и форумов можно не париться и восстанавливать пароль по мере необходимости по e-мейлу/телефону.

Для интернет-магазинов - в зависимости от того, светили ли вы на ней свою карту. Если там оплата через paypal, qiwi и подобные сервисы, которые требуют подтверждения при оплате, то можно тоже не заморачиваться.

Не нужно ничего хранить на бумаге либо где-то еще.

Схема простая, наверняка у тебя есть 5-7 значная комбинация цифр, которую ты помнишь «с детства» или типа того, это конечно не дата рождения и в таком духе, а, например, номер телефона первой любимой или старого места жительства.

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

Базу ты помнишь всегда, а там, где нужно применять эту базу очевидны следующие подсказки и схема, например твоя база это '1234567':

• пароль для linux.org.ru это: lin1234567ux (первые 3 символа домена + база + оставшиеся символы домена)
• пароль для gmail это: Goo_1234567_glE (то же самое, но с усложнением _ и регистром)
• пароль синхронизации firefox: fir1234567EFOX

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

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

Т.е. ты вообще ничего не запоминаешь, ведь базу помнишь, а остальное дело 1-2 ошибочных вводов пока не запомнишь схему.

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

1. 2-е бумажки. в 1-ой столбиком название ресурса
2. на 2-й пароль в отзеркаленном виде.
Правда кацкер догадается, что отзеркаленные символы, но даже если не отзеркаленные, то сделать фотографию смартфоном с листочка и следить по каким сайтам ползает оператор сколько влезет никому не мешает.
Без 1-го листочка он может долго гадать что это и куда это.
Удобнее, т.к. пароли время от времени меняются, а названия сайтов нет.
Хранить в разных местах. Время от времени списки перемешивать.
Это я описал, чтобы топикстартеру конвейер операций сократить до минимума.
Можно сделать какой-нибудь шифр в виде перфокарт, накладываемых на текст Уильяма, нашего, так сказать, Шекспира.

15-символьный полностью случайный пароль

7 слов из словаря в 13 тысяч(без падежей/родов/склонений и других whatewero-ов) как раз эквивалентны 15 полностью случайному ascii паролю.

Так я и не спорил, что 7 слов — не хуже (а на самом деле даже лучше), чем 15 случайных байт. Я говорил про пароли одинаковой длины.

10 млрд переборов

Всегда можно потребовать 1 секунду какого-то аргона на перебор

Речь про перебор паролей в он-лайне? Этот вариант я даже не рассматриваю. Тут можно сделать так, чтоб и перебор 1000 вариантов происходил неприемлемо долго, всё зависит от хостера. Я говорил про случай, когда взломщик уже добрался до хэшей.

Сколько ботов стоит твой пароль?

А при чём тут конкретно мой пароль? Взломщик сломал какой-то ресурс и выкачал базу паролей. Что он делает дальше? Пытается взломать все подряд хэши за разумное время. Что получится взломать, тем и будет пользоваться.

Это новые NIST-овские рекомендации.

А что за рекомендации?

за 20 лет он не взлетел не очень понятно(типа 2 конторы сказали «патентовано»

Так долго патенты не живут. Если оно и было патентовано 20 лет назад, то уже нет.

Не факт...

это не шутка. Это новые NIST-овские рекомендации.

То что этот бред является новыми NIST-овскими рекомендациями я в курсе. Но я надеялся что хотя-бы Вы пошутили.

взломщик уже добрался до хэшей

Для этого и придуманы pbkdf-ы. Оно «гарантирует», что каждая попытка займёт «много» ресурсов. То же, кстати, происходит, скорее всего, с паролем твоего файла с паролями, потому не стоит пытаться запоминать 15 действительно случайных символов, стоит потребовать больше времени на вычисление ключа из пароля.

А что за рекомендации

Коротко: следует убрать из парольных политик требование спецсимволов, цифр, разных регистров и частой смены паролей, т.к. это провоцирует простоту взлома оных. Детали гуглить.

Так долго патенты не живут

Может потому и начали появляться реализации. Впрочем, может это только в узком поле моего личного зрения.

То что этот бред

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

взломщик уже добрался до хэшей

Для этого и придуманы pbkdf-ы. Оно «гарантирует», что каждая попытка займёт «много» ресурсов.

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

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

А что за рекомендации

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

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

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

Детали гуглить.

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

Сходу ничего не нагуглилось

Первая ссылка по nist password policy. https://pages.nist.gov/800-63-3/sp800-63b.html В конце обоснование. Осталось 2 требования - минимум 8 символов без ограничения сверху и отсутствие в словарях.

Ничего оно не гарантирует, ... всё зависит от ... аппаратных возможностей взломщика

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

от пользователя не зависит ... адекватность администрации

Это может зависеть только от используемого клиента. Скажем, можно встроить вычисление SRP-верификатора в бровзер, авторам которого мы и так уже доверяем. Немного осталость-то. TLS-SRP уже в openssl-ях, и апачах. Немного непонятно, как они предлагают менять пароль - передача его на сервер убивает половину вкусностей.

https://pages.nist.gov/800-63-3/sp800-63b.html

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

1. Не согласен с тем, что 2 и более пробелов подряд должны удаляться. При назначении пароля случайный ввод 2 пробелов можно предотвратить повторным вводом строки, если она не копипастится. Кроме того, при задании такого пароля можно предупредить об этом пользователя. Но если тихо убирать лишние пробелы, то пользователь может даже не догадываться об этом и считать, что его пароль Hello World, в то время как на самом деле его пароль Hello World. Пока программа аутентификации не меняется, это скорее всего не вызовет проблем. Они начнутся при обновлении программы (например, старая не удаляла пробелы, а новая удаляет или наоборот).
2. По похожей причине я против использования любых не ascii-символов в паролях, за исключением локалхоста. Да, сейчас юникод стал фактически стандартом. Но далеко не всегда. В той же Windows всё ещё широко распространены 8-битные кодовые страницы, а в Unix кое-кто использует koi8-r. У того же saahriktu unicode-пароли могут вызвать проблемы. Ну и не думаю, что абсолютно все сайты в Сети перешли на юникод. Если на каком-то сайте всё вводится и выводится в koi8-r, то и пароль тоже будет переводиться в эту кодировку перед хешированием, но если в будущем кодировка будет изменена, то все кириллические пароли станут недействительными. Ещё сложнее дела могут обстоять на сайтах, которые в зависимости от юзер-агента, предпочитаемого языка и каких-то других факторов предоставляют разным пользователям разные кодировки. Пароли не должны быть на это завязаны.
3. С тем, что при навязывании пользователю буквенно-цифровых паролей, это может вылиться в создание паролей типа «Password1», что не намного сложнее, чем «password», согласен. Но всё-таки даже такой вариант немного, но сложнее. Если же речь идёт не о тупом навязывании, когда пользователь негодует «какого ... я должен вводить какие-то циферки», а о разъяснении, для чего это нужно, и добровольном выборе пользователя, вооружённого новыми знаниями, то он не будет создавать пароли password1 или abc123. А тому, кто сам себе злобный буратино, насильно не поможешь.
4. Про 6- и 8-символьные пароли там в конце оговорка, что они приемлемы при онлайн атаках, но не при оффлайн:

   the threat model being addressed with memorized secret length requirements includes rate-limited online attacks, but not offline attacks.
   

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

Вот же. Гарантирует зависимость от аппаратных возможностей взломщика. Да, за счёт аналогичого у сервера

Если рассматривать проблему комплексно, то полностью согласен. Но если речь идёт о пользователе, заинтересованном в надёжности своих данных и не имеющем возможности контролировать политику всех ресурсов, которыми он пользуется, то исходить ему лучше из худшего варианта (ну, может не самого худшего, когда всё бесполезно, но как минимум не идеального).

адекватность администрации

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

Тут как в песне: «на дурака не нужен нож, — ему покажешь медный грош и делай с ним, что хош.» :-) Все эти усовершенствования рассчитаны на админов, которые и так заботятся о безопасности, но хотят её ещё больше усилить. А от админов на том ресурсе сие вряд ли спасёт:

Нажал на восстановление пароля, мне пришел тот пароль, что я ввел еще нцать лет тому назад, а не новый пароль. Храните пароль открытым текстом? Ну спасибо [Mamut, Member]

В базе, пароли не лежат в открытом виде. Это мой пароль. 0xCB4C23127361DEC138C35EFE77A1D6C267EE5367AE2727CF Все равно с этим ничего не сделаете. То что хеш надежнее - спорить не буду. Действительно так. [judge, Администратор]

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

База и алгоритм на разых серверах. Я думаю, для форума этого вполне достаточно. Переход на хешированые пароли в планах давно, но не с высоким приоритетом.

Вот адекватный это админ? А сколько ещё таких же на разных ресурсах?

от админов на том ресурсе

Повторяю. Если смена пароля будет происходить без передачи оного на сервер(например, запретить бровзерам передавать содержимое неотображаемых полей без pbkdf-ления оных в течени 3х секунд вкупе с названием сервера и полученной оттуда или случайной солью), админы сервера не смогут ничего испортить(разве что сделать пароль видимым, что клиент уже должен заметить).

Если смена пароля будет происходить без передачи оного на сервер(например, запретить бровзерам передавать содержимое неотображаемых полей без pbkdf-ления оных в течени 3х секунд вкупе с названием сервера и полученной оттуда или случайной солью), админы сервера не смогут ничего испортить

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

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

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

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

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

принципиально не будет переходить

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

Я шифрую свои пароли в сообщениях на лоре

3 секунды это не задержка, это процессорные ресурсы. Взломщик может это распаралелить на ширину своего кармана. Но соперничать так с экспоненциальным ростом кол-ва вариантов непросто.

Тогда это может оказаться слишком тяжело даже для жирных серверов. Представь себе какой-нибудь яндекс или мэйл.ру, обрабатывающих по 3 секунды, в течение которых целиком грузится одно ядро одного проца, хотя бы 10 тыс. логинов в день. Это 30 тыс. сек./ядро в день или 8 с лишним часов полной загрузки одного ядра в день только на логины. А DDoS атаки против сервисов, использующих такие тяжёлые алгоритмы, вообще будут плёвым делом: собрать логины нескольких сотен или тысяч пользователей (логины — не пароли, для их сбора большого ума не надо) и залогиниться одновременно всем ботнетом.

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

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

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

Да, тут согласен. От взлома на других ресурсах, где используется такой же пароль, защищает.

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

принципиально не будет переходить

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

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

Там достаточно 2им сговориться, и все сразу станут секурными.

Думаю, как минимум 4-ым: разрабам хрома, файрфокса, оперы и сафари. Ну, может один из последних 2 можно было бы проигнорировать при условии, что трое пришли к консенсусу.

DDoS атаки против сервисов, использующих такие тяжёлые алгоритмы

Никто не обещал бесплатной доступности в интернетах.

если админ лох

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

хороший хэш, генерируемый сервером

Как ты убедишь клиента, что сервер сделает именно это, а не разошлёт его пароль всем ботам? Потому осторожный клиент должен будет придумывать уникальный пароль к каждому серверу. А память у него не магниторезистивная. С другой стороны клиент может это обеспечить(выбрав ПО/настройки). Потому оно именно там должно быть.

кто больше от всего этого потерял бы: Симантек или хром

Сайты тюнятся под особенности бровзеров или наоборот? Как говаривали в прошлом тысячелетии «Клиент всегда прав».

хороший хэш, генерируемый сервером

Как ты убедишь клиента, что сервер сделает именно это, а не разошлёт его пароль всем ботам? Потому осторожный клиент должен будет придумывать уникальный пароль к каждому серверу. А память у него не магниторезистивная. С другой стороны клиент может это обеспечить(выбрав ПО/настройки). Потому оно именно там должно быть.

Я же не спорил с тем, что такая схема защищает пароль на других сайтах, если он одинаковый. Я говорил о другом: что сервер тоже должен хэшировать пароль (или хэш, присланный клиентом, но для него это тот же пароль), чтобы взломщик, даже заполучив базу паролей/хэшей, не смог «законно» залогиниться от имени пользователя. Одно другому тут не мешает.

кто больше от всего этого потерял бы: Симантек или хром

Сайты тюнятся под особенности бровзеров или наоборот?

Я думаю, тут двустороннее движение.

Как говаривали в прошлом тысячелетии «Клиент всегда прав».

Да, но под клиентом подразумевали человека, а не инструмент. И было это в прошлом тысячелетии. В наше время веб-макака всегда права. :-)

Т.е. получается, что ты выложил пароль?

получается, что ты выложил пароль?

Нет, только хэш. :-)

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

Ну ты упорный. Говорят же:

Even if the host's password database were publicly revealed, the attacker would still need an expensive dictionary search to obtain any passwords.

Всё уже придумано! Не сможет он залогиниться зная хеши!

Even if the host's password database were publicly revealed, the attacker would still need an expensive dictionary search to obtain any passwords.

Всё уже придумано! Не сможет он залогиниться зная хеши!

Цитата отсюда: https://tools.ietf.org/html/rfc2945. Спасибо, почитаю.

Почитал. И не только этот rfc. Там уже вышла 6-я версия протокола, в то время как в rfc описывается 3-я. Но по протоколу не только клиент вычисляет хэш, но и сервер делает то же самое, а потом они на основе своих хэшей создают общий ключ. Т. е. это что-то вроде ssl, но без удостоверяющего центра и предназначен в основном только для идентификации, хотя и шифрование данных с его помощью тоже возможно. И в этом смысле там нет противоречий с тем, что я говорил, т. к. сервер не просто пассивно принимает какой-то хэш от клиента, а происходит обмен сгенерированными на обеих сторонах ключами.

Протокол действительно мог бы заменить аутентификацию, традиционно принятую в Linux и вообще в разных ОС (а принцип везде один), сделав её безопаснее.

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

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

Ещё раз раз спасибо за наводку.

Вот сейчас написал и подумал, а от чего, собственно, он дополнительно защищает? От передачи пароля открытым текстом уже предохраняет ssl. А при утечке базы паролей, всё так же перебором по словарю слабый пароль может быть взломан, после чего взломщик, воспользовавшись этим же алгоритмом, спокойно войдёт на сервер под чужим именем. Так что нет, мы были не правы. Можно сравнивать надёжность srp с ssl (я не исключаю, что в чём-то он может его превосходить, хотя отсутствие сертификации — явно слабое место), но принципиально по сравнению с существующими схемами использование этого алгоритма ничего не даёт.

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

От передачи пароля открытым текстом уже предохраняет ssl

Это ложь. SSL защищает только от перехвата пароля в промежутке между клиентом и владельцем ключа. 1. squid sslbump - и все внешние пароли всех сотрудников конторы(обеспокоенной утечками инфы - и потому поставившей этот сервис), на совести сысадминов(и привет службам, способным заставить CA выдать любой сертификат во временное пользование). 2. https прокси перед кластером из томкетов - и все пароли у админов тамошнего езернета(и привет ddos-protector-ам). 3. При смене пароля хозяева(законные или нет) сервера точно знают, кто из пользователей не хочет играть в «надёжные пароли».

Короче, если говорить про безопасность, zero knowledge всегда защищает, минимум от утечки knowledg-а. Если ты испольуешь оное для чего-то ценного(пароли в случае удостоверения личности), уже плюс.

От передачи пароля открытым текстом уже предохраняет ssl

Это ложь. SSL защищает только от перехвата пароля в промежутке между клиентом и владельцем ключа.

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

3. При смене пароля хозяева(законные или нет) сервера точно знают, кто из пользователей не хочет играть в «надёжные пароли».

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

Отправляете хэшированные пароли мне, возьму на хранение.

все пароли будут в одну строчку, без пробелов. Это безопасно?

Это небезопасно. Эта опасность называется отказ в обслуживании. Если, к примеру, таким способом будет заполнен 128-страничный блокнотик, а с вами не дай Бог что-то случится, и вы играете в команде, то возникает риск утерять доступ по этим паролям к нужным ресурсам. Да даже и не в команде, за несколько лет, если постоянно не пользуетесь чем-то из записанного, то большая вероятность забыть от чего конкретно тот или иной пароль.

https://www.themooltipass.com/

/thread

Эта опасность называется отказ в обслуживании. Если, к примеру, таким способом будет заполнен 128-страничный блокнотик

А если не 128-страничный блокнотик, а только одна страница этого блокнотика, то можно относительно легко перебрать разные варианты.

при смене пароля в обоих случаях он попадёт на сервер

SRPека не требует генерации верификатора на стороне сервера. Извини, на безосновательные утверждения больше не реагирую.

при смене пароля в обоих случаях он попадёт на сервер

SRPека не требует генерации верификатора на стороне сервера.

Как же не требует, если это чёрным по белому написано в процитированном тобой rfc2945:

The host stores user passwords as triplets of the form

        { <username>, <password verifier>, <salt> }

Password entries are generated as follows:

        <salt> = random()
        x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
        <password verifier> = v = g^x % N

[skip]

Host

[skip]

                                         v = <stored password verifier>
                                         b = random()
                                  <--    B = (v + g^b) % N

[skip]

The client generates a random number, raises g to that power modulo the field prime, and sends the result to the host. The host does the same thing and also adds the public verifier before sending it to the client. Both sides then construct the shared session key based on the respective formulae.

Извини, на безосновательные утверждения больше не реагирую.

Извини, но ты что-то попутал. У меня всё обосновано. А вот на чём основана твоя уверенность, что «SRPека не требует генерации верификатора на стороне сервера», совершенно непонятно.

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

Немного облегчит. Но если например известно что нет в пароле спецсимволов, то это гораздо серьезнее облегчит задачу перебора чем знание того что есть всё.

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

Если произошел факт взлома, то злоумышленник уже на сервере. И ни что ему не может помешать просто добавить в базу акк и дать этому акку нужные права. :)

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

Но если например известно что нет в пароле спецсимволов, то это гораздо серьезнее облегчит задачу перебора чем знание того что есть всё.

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

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

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

Если произошел факт взлома, то злоумышленник уже на сервере. И ни что ему не может помешать просто добавить в базу акк и дать этому акку нужные права. :)

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

А потом приходят говносайты (привет банкам) которые говорят, что твой пароль устарел и создавай давай новый. И так каждый квартал.

Такого еще не было за 23 года пользования интернетом.

The host stores user passwords as triplets of the form ...
Password entries are generated as follows

Вопрос в том, где они «are generated». Я не нашёл ничего, препятствующего выполнению этого у клиента и отсылку серверу готового верификатора.

Я не нашёл ничего, препятствующего выполнению этого у клиента и отсылку серверу готового верификатора.

Да, о таком варианте я не подумал.

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

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

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

В автоматически сгенерированном пароле?

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

В автоматически сгенерированном пароле?

да. Сравните стойкость пароля в 15 символов при генерации которого были использованы большие и маленькие буквы, цифры и спецсимволы. И 15-и символьный пароль в котором использованы только маленькие буквы.

Авторучка (они тоже разные бывают)

Простой карандаш (мягкий, твердый)

Цветной карандаш

Фломастер (маркер)...

Сравните стойкость пароля в 15 символов

У меня на бесплатной почте http://www.yandex.ru ящик: kursakov.1972@yandex.ru пароль длиной в 74 символа...