Какова оптимальная длина пароля?

Автор оригинала: Tamás Sallai
  • Перевод
Конечно, чем больше, тем лучше. И с помощью менеджера паролей можно очень легко генерировать и автоматически заполнять пароли любой длины. Но нужно ли делать пароли длиной в сотни символов, или есть какой-то эмпирический разумный минимум?

Вот интерфейс типичного генератора паролей:


Обратите внимание на ползунок Length: здесь он может менять длину пароля от 8 до 100 символов, а в других инструментах — гораздо больше. Какое же значение оптимально для паролей?

Хороший пароль — это всё, что у вас есть, когда вас взламывают


Чтобы понять, что такое хороший пароль, посмотрим, что происходит в стане врага!

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

  • MD5
  • SHA-1
  • Bcrypt
  • Scrypt
  • Argon2

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


Хранение хэшей.

Взлом пароля


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


Взлом пароля.

И здесь важен выбор хорошего алгоритма. SHA-1 разрабатывался с учётом быстрого хэширования, это облегчает жизнь взломщикам. Bcrypt, Scrypt и Argon2 разрабатывались с учётом высоких вычислительных затрат, чтобы как можно больше замедлить взлом, особенно на специально выделенных машинах. И это очень важный аспект.

Если ориентироваться только на скорость, то пароль SHA-1, который невозможно взломать, выглядит так: 0OVTrv62y2dLJahXjd4FVg81.

А безопасный пароль, созданный с помощью правильно сконфигурированного Argon2, выглядит так: Pa$$w0Rd1992.

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

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

Думаете, в компаниях серьёзно относятся к безопасности и используют хорошие алгоритмы хэширования? Посмотрите на список взломанных баз данных, особенно на использованные в них хэши. Во многих случаях применялся MD5, чаще всего — SHA-1, и кое-где использовали bcrypt. Некоторые хранили пароли в виде простого текста. Такова реальность, которую нужно учитывать.

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

Пароль выбираете вы


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

При правильно сконфигурированных алгоритмах сложность вашего пароля тоже не важна, он может быть 12345 или asdf.

Однако в промежуточных случаях, особенно при использовании SHA-1, сложность пароля имеет значение. Функции хэширования в целом не предназначены для паролей, но если вы используете сложный пароль, то это компенсирует недостатки алгоритмов.


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

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

Уникальности пароля недостаточно


Ладно, но с какой стати вам думать о том, чтобы использовать менеджер паролей и генерировать уникальный пароль для каждого сайта? В этом случае вы неуязвимы для credential stuffing — когда известная пара почтового ящика и пароля проверяется на разных сервисах в надежде, что человек использовал эти данные в разных местах. Это серьёзная угроза, потому что повторное использование паролей одна из главных проблем безопасности. От этого вас защитит генерирование уникального пароля для каждого сайта.


Credential stuffing.

А если базу украдут и всё её содержимое станет известно хакерам, то зачем вам всё ещё защищать свой пароль?

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


Использование сервиса после взлома.

Как оценить силу пароля с помощью энтропии


Сила пароля характеризуется энтропией — числовым представлением количества случайности, которая содержится в пароле. Поскольку речь идёт о больших числах, то вместо 1 099 511 627 776 (2^40) нам проще сказать «40 бит энтропии». И поскольку взлом пароля — это перебор вариантов, то чем их больше, тем больше времени нужно затратить на взлом.

Для случайных символов, сгенерированных менеджером паролей, энтропия считается по формуле: log2(<количество разных символов> ^ <длина>).

С длиной понятно, а что такое количество разных символов? Оно зависит от классов символов, входящих в пароль.


Например, пароль из 10 случайных строчных и прописных букв имеет log2(52 ^ 10) = 57 бит энтропии.

Чтобы вычислить удельную энтропию (её количество в одном символе заданного класса), можно использовать уравнение log2(n ^ m) = m * log2(n). Получаем: <длина> * log2(<количество разных символов>), где вторая часть является удельной энтропией. Пересчитаем по этой формуле предыдущую таблицу:


Для вычисления силы пароля нужно взять классы символов, которые входят в пароль, взять значения энтропии для этих классов и умножить на длину. Для приведённого выше примера пароля из 10 строчных и прописных букв мы получили 5.7 * 10 = 57 бит. Но если увеличить длину до 14, то энтропия скакнёт до 79,8 бит. А если оставить 10 символов, но добавить класс специальных символов, то общая энтропия будет равна 64 бит.

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

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

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

Руководство по энтропии


Чем больше в пароле энтропии, тем сложнее его взломать. Но сколько энтропии будет достаточно? В целом, около 16 символов будет за глаза, у такого пароля 95—102 бита энтропии, в зависимости от классов символов. А какой минимальный порог? 80 бит? 60? Или даже 102 бита слишком мало?

Есть алгоритм, который по скорости соперничает с плохим алгоритмом хэширования, но зато изучен гораздо лучше: это AES.

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

Национальный институт стандартов и технологий определил размеры ключей, которые будут достаточны в обозримом будущем. Там рекомендуют использовать AES-128 в период «2019—2030 и позже». Как понятно из названия, речь идёт о 128 битах энтропии.


В другой рекомендации советуют делать ключи размером не меньше 112 бит:

Для обеспечения криптографической стойкости для нужд Федерального правительства сегодня требуется не меньше 112 бит (например, для шифрования или подписи данных).

Чтобы получить 128 бит энтропии с использованием прописных и строчных букв, а также чисел, нужен пароль длиной 22 символа ((5.95 * 22 = 131 бит).

Другие соображения


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

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

Что делать, если есть ограничение по длине? На некоторых сайтах длина пароля не может достигать 22 символов. Иногда пароли могут быть только очень короткими, например, не больше 5 цифр. Тогда остаётся только использовать пароль максимально возможной длины.

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

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

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

Заключение


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

Это защитит вас в том случае, если сервис взломают и применялся слабый, но не взломанный алгоритм хэширования.
ДомКлик
Место силы

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

    +6
    Странно что не рассказали о самом лучшем и надежном методе генерирования паролей — использование нескольких случайных слов:

    Примеры:
    bytes-mail-chimp-hat
    pizza-sloth-car-banana

    Главное только, чтобы слова не были явно связаны между собой

    Плюсы:
    — Легко запомнить («шимпанзе в шляпе» легче запоминается, чем «H4v$#.!4a!3»)
    — Не требует «заглавных букв, цифр, символов»
    — Вводится быстрее, и шанс ошибиться меньше, чем при вводе пароля из случайных символов, где нужно постоянно нажимать shift, и есть шанс ошибиться в регистре
    — Очень высокий уровень энтропии
    — В отличии от паролей из «случайных букв, цифр, и символов», не вызывает желание забить на все и использовать простой пароль вроде: qwerty123

      0
      Странно что не рассказали о самом лучшем и надежном методе генерирования паролей — использование нескольких случайных слов:

      Идем, скажем, на список случайных слов от EFF. В длинном списке их 7776 штуки или 12.9248… бит на слово. Чтобы набрать 128 бит энтропии нужно 10 слов. А десять случайных слов запомнить — тоже проблема.


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

        +1

        а если использовать слова с грамматическими ошибками?
        что-нибудь меняется при использовании пароля "шемпанзе в шляпи"?

          +5

          Это становится заметно труднее запомнить. Ту часть которая "а какую именно ошибку тут сделать надо?".

            +3
            И вариантов легко запоминаемых ошибок не так много как кажется.
              0
              Делать можно ошибки, например, в стиле деревенского дурачка или в стиле шепелявого логопеда из советского кино или в стиле интернет-падонка или в «одесском» стиле. Будет легко запомнить. Или использовать придуманные слова в стиле С. Лема.
              Сам спользую для пароля пару «ненастоящих» русских слов, напечатанных в английской раскладке. Ненастоящих в смысле самопридуманных и слегка искаженных. Плюс первые три буквы доменного имени ресурса и любимую цифру. С экранной клавиатуры смартфона, правда, метод становится неудобным…
                0

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

                0

                Есть такой опыт. :) Пароль нужно запомнить с неверным произношением "на иностранный манѣръ". Вышеуказанный пример будет звучать как "шЕмпанзе в шляпИ" (ударения показаны заглавными буквами).
                p.s. По ходу написания комментария родилась мысль, что никто не запрещает указать ошибки в верхнем регистре в самом пароле.

                  0

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

                    0

                    О том и речь. Запомнить проще, когда искажаешь ударения и фраза звучит неестественно. Заглавные буквы в моём примере — это ударения.

                      0

                      Теперь берем три случайных прилагательных из 512 самых частых (т.е. 9*3=27 бит) и получаем "шимпанзе в древней густой счастливой шляпе".


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

              0
              В русском языке используется склонение и спряжение, что несколько увеличивает энтропию. А недостаток грамотности (что легко заметить в первом предложении) добавляет еще несколько бит.
                0
                А как же классика: «40000 обезьян в рот засунули банан?»
                Делал лабораторные по взлому, пароли а-ля «admin-123» при наличии SAM взламывались в пару минут, а вот в боевых условиях, когда потребовалось узнать забытый пароль родственницы, состоящий только из русских букв и нескольких цифр, программа трудилась часов 12. Безрезультатно.
                ИМХО, безопасный пароль — это веселое словосочетание и пара цифр. + замена раз в 2 месяца.
                0
                Сразу вспоминается писатель Лукьяненко со своей знаменитой фразой-паролем в одной из книг: «Сорок тысяч обезьян в жопу сунули банан...»)
                P.S. кстати не известно «сорок тысяч» или «40 000»)))
                  0
                  Всё известно ;)
                  Это фраза, первая буква строчная, все остальные прописные. Пробелы значимы. В конце должна стоять точка. Набирай… и повторяй по буквам.
                    +2
                    Интересно, сколько админов боролись с искушением поставить этот пароль на свой сервер?
                      0
                      Сорок000
                      0
                      повтореный шесть qwerty123 уже не выглядит таким уж безобидным для брутфорса
                        0
                        По учебе в лабораторной работе несколько минут взлом занял.
                          0

                          это если заранее знать, что длина пароля 54 символа. Не верю что "6 раз кверти123" так легко крякнется.

                            0
                            За сколько времени взломаете мой архив с повторяющимся паролем?
                        0
                        Почему-то все забывают про проверки на HaveIBeenPwned и zxcvbn от DropBox.
                        Есть даже готовое решение с красивой графикой, которое оценивает пароль по самым современным метрикам
                        image
                          +11
                          По тому, что созданный на этих ресурсах словарь, будет намного эффективней простого перебора.
                            –1
                            Крайне странная мысль. Насколько намного, вы считали?
                            Не позволяя пользователю выбрать пароль из подмножества слабых, мы заставляем его задать пароль из гораздо большего множества возможных вариантов. Где тут логика?
                            Если бы вероятность попадания пароля в HaveIBeenPwned и zxcvbn была большая, то проблем у пользователей было бы гораздо больше
                              +1

                              Я полагаю, оппонент намекает, что люди добровольно сливают свои пароли этим сервисам. Я, например, не поленился выкачать базу havebeenpowned, т.к. ссу отправлять им свой пароль, и даже хэш от него (они ведь простой sha1, а не scrypt/argon просят)

                                –1

                                Чего именно вы опасаетесь? Вот мой реальный пароль от одного из аккаунтов на одном из сайтов (нет, не хабра) — 58CNTCzzL9Ls5hWZ — что вы с ним сделаете, не зная логина и собственно сайта? И это с учётом того что оставляя его здесь я рискую гораздо больше чем на каком-то сервисе который про меня знает только мой динамический IP, ОС и браузер.


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

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

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

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


                                    На действительно важные сайты (банки, paypal etc) у меня к тому же 2FA, а с запоминанием всего этого проблем нет благодаря KeePass.

                                  –1
                                  Вы что, не в курсе как работает их API? k-means? Реально думаете, что туда отправляется пароль в чистом виде?
                                    –1
                                    Если у них база SHA, значит туда можно отправлять SHA. Ок. Но если пароль не такой сложный, как у Tangeman, то подобрать его offline проще паренной репы.

                                    Просто ждём, пока накидают 10 миллионов ненайденных в базе SHA, и запускаем переборщик. Даже если ему придётся работать месяц, и он отыщет десятую часть, всё равно это будет 1 миллион новых паролей. Чем не профит?
                                      0
                                      Чукча не читатель? Туда отправляется не SHA
                                        –1
                                        Ок, проверил, что посылает HaveIBeenPwned. Выглядит действительно более-менее безопасно: посылается 20битный хэш в виде части пути. В ответ уже приезжают SHA, из которых нужный проверяется на клиенте. Я был не прав.
                                        Важно было не SHA/не SHA, а сколько бит. 20бит явно не достаточно для идентификации пароля.
                            +2
                            Раньше был у меня некий алгоритм формирования паролей на различных сайтах, но со временем понял, что по некоторым причинам это не всегда подходит.

                            В итоге перешел полностью на keepassxc. Файл синхронизирую через ядиск, защиен паролем + файл ключ на устройствах (win, linux, andr).
                            И для всех генерирую пароли вида: i_óälÝgíldjâ-¸+¼np@:º.

                            Один большой минус — на некоторых сайтах стоит дурацкая регулярка с запретом ASCII и\или спецсимволов.

                            P.S. Жду когда добавят в автогенератор эмодзи)
                              0
                              Не знаете, можно ли делать что-то на подобии скрытых томов в keepassx? Когда под разными ключами открываются разные базы?
                                0
                                К сожалению, нет. Но при большом желании можно было бы хранить базу в скрытом томе Veracrypt.
                                  0
                                  Жаль. По мне Veracrypt — это оверкилл.
                                +8

                                удачи вам ввести такой пароль на устройстве без copy/paste :)

                                  –2
                                  KeePass сам вводит пароли без copy/paste. Хотя умеет и с copy/paste, но предупреждает, что буфер обмена небезопасен.
                                    0
                                    Не во всех случаях. Если не ошибаюсь (в терминологии разбирался давно при Outpost-е ещё, сейчас на z-oleg посмотрел, вроде правильно), при автовводе (Auto-Type) действительно KeePass подключается к очереди потока и пишет прямо туда. Если используется двойное усложнение набора (Two-Channel Auto-Type Obfuscation), то пароль делится на две части, одна из которых вводится так же, а другая именно через буфер обмена. При этом есть некоторая несовместимость с «Безопасными платежами» Касперского: к очереди потока Касперский подключиться не даст. Тогда и работает copy/paste (Ctrl-B, Ctrl-C и Ctrl-V — немного не стандартно, в соответствии с инструкцией). По умолчанию буфер обмена очищается через 12 секунд, вроде. Что касается kepass2android, то там в составе приложения входит своя клавиатура, которая вводит информацию не через copy/paste, а напрямую, хотя и через буфер обмена возможность ввода остаётся, но не рекомендуется.
                                    0
                                    Вот-вот. По это же причине, даже пользуясь вышеупомянутым Keepass, генерирую пароли без спецсимволов, ориентируясь, как и автор статьи на необходимую длину пароля. Единственное чтобы я добавил, не на всех символах дабл-клик запинается, подчеркивание вполне себе подходит (на самом деле не только оно) и с ним вполне можно задавать усложненные пароли.
                                      0
                                      На старых андроидах FullKeyboard или ХакерКейбоард.
                                      На новых есть глюки, если верить 4pda.
                                        0

                                        Я про всевозможные железки, требующие ввод пароля какой-либо учётки при первоначальной инициализации, будь то Playstation, iphone или разнообразные сервера. не везде разработчики предусматривают безпарольную аутентификацию на такой случай.

                                          0
                                          Айфон — это просто.
                                          А вот железка, где две аппаратных кнопки… — ввести что-то длинней 3-5 символов, уже подвиг, а бывает серийник символов на 50. И он не навсегда.
                                            +1

                                            А как вы введёте в новый айфон при активации строку, которую человек выше приводил в качестве примера? i_óälÝgíldjâ-¸+¼np@:º
                                            Ладно, в любом случае всё сводится к тому, что увеличивая алфавит парольной строки мы увеличиваем основание, а увеличивая её длину — степень сложности подбора. Другими словами эффективнее добавить лишнюю букву, чем заменять в строке "а" на "а с апокрифом" или 4 на 1/4.

                                      +1
                                      Уж очень высок риск компроментации сразу всего и вся, если этим проектом завладеют недоброжелатели. Разве что скомпилить из сырцов самому, и никогда не обновлять.
                                      +1
                                      Для паролей стал использовать KeePass, везде либо стандартные 30 символа автогенератора (буквы, цифры, символы, например 7?iVEqD&hplw=;QX4$@jQ«ezUO`j0,) либо иногда приходится тюнить под сайт (бывает максимальная длина в 8 паролей, собрал шаблоны генератора для таких сайтов).
                                      Ставить разные стойкие пароли даже для десятка популярных сайтов уже проблема, если их запоминать, а завязывать всё на условный гугл и входить через него — тоже так себе затея.
                                        0
                                        У Эпла довольно удобно сделано, сафари при заполнении формы для пароля во время регистрации предлагает сгенерировать уникальный пароль и сразу вносит в keychain из-за чего становится доступным на всех устройствах. Уже забыл когда последний раз придумывал пароль.
                                          0
                                          Подтверждаю. Очень удобно, пароли генерит сложные, запоминать не надо, Сафари их сама подставляет. Хранит в защищенном месте. Можно синхронизировать с другими устройствами. Одна из удобнейших функций на маке. И вообще — Сафари отличный браузер.
                                            +3
                                            Хром и огнелис тоже умеют это делать, притом тоже достаточно давно. Другое дело, что этим сервисам я не доверяю, вместо них использую GNU pass с шифрованием и синхронизацией через свой гит-репозиторий, который хостится на собственном сервере.
                                            +1

                                            Mozilla Firefox тоже так умеет. Удобно для одноразовых сайтов которые нужны, но требуют регистрации на совершение действия. Одноразовая почта + какой-то рандомно сгенерированный пароль который мне даже не интересен и voila

                                              0
                                              хром аналогично делает
                                                0
                                                Не стоит забывать их фейлы с проверкой подлинности сертификатов, пустым админовским паролем и недавней лажой с логином через Apple ID. Похвально их стремление к приватности и безопасности, но при этом удивляет какие детские ошибки они иногда допускают.
                                                –1
                                                есть разница между SHA-1 и SHA-256?
                                                  0

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

                                                  0
                                                  а реально ли встречается 5,6,7 бит энтропии на символ? разве все не будет кратно 8 битам? пароль то пользователь все равно вводит символами, а символ в простом представлении это 8 битное число. хотя есть кодировки и 7 битные, но кто будет заморачиваться? так что даже если взять только одни цифры, то злоумышленнику все равно придется перебирать все 256 вариантов(если рассматривать стандартную ACII таблицу) на символ.
                                                    +1
                                                    разве все не будет кратно 8 битам?

                                                    Удачи Вам ввести в пароле символ 0x07 (Backspace) или 0x0D (возврат каретки). Да и вообще пусть не большую, но значительную часть возможных битовых сочетаний.

                                                      0

                                                      Иногда такая возможность все же есть. Например ввод пароля для зашифрованного тома luks при загрузке linux.

                                                    0
                                                    Не хватает хорошего парольного алфавита, чтобы не было 1 и I, O и 0, u и v, i и j, nn и m, vv и w, и так далее.
                                                      +2
                                                      Берёте случайный текст или лучше файл и в base56 его.
                                                      Все символы подходящие, энтропия в норме, если забыли/потеряли пароль — можно попробовать вспомнить сид
                                                        0
                                                        Действительно base58 — любопытнейшая штука. Всё что могло быть изобретено, уже изобретено ). Спасибо.
                                                        0
                                                        Во многих генераторах есть опция исключения похожих символов.
                                                          +1
                                                          KeePassXC, опция «не использовать визуально схожие символы» – примерно это и делает.
                                                          0
                                                          Для того чтобы получить 256 бит энтропии в пароле из букв и чисел нужно 43 символа.
                                                          P.S. кажется во Вселенском компьютере индексация начинается с 0 :)
                                                            +1
                                                            Преимущество хранения хэшей вместо самих паролей заключается в том, что паролей в БД нет. И это правильно, потому что вам нужно только доказать, что вы знаете свой пароль, но сам он не имеет значения.

                                                            В плане аутентификации по паролю есть два подхода: PAP и CHAP. Так вот вы их смешали: при PAP пользовательский пароль передаётся как есть, а в БД хранится хэш для сверки. А вот при CHAP как раз пользователь передаёт лишь признак знания пароля, но на стороне сервиса он должен хранится в обратимом виде.

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

                                                            Не совсем так: обращение вспять хэш-функции — частный случай взлома пароля.
                                                              0
                                                              Если совпадение произойдёт, значит, пароль восстановлен из хэша.

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

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

                                                              «Хранители паролей» это складывание яиц в одну корзину, к тому же часто не свою…

                                                              Все «мнемотехники» это сразу нестойко, притом сильно нестойко.

                                                              Биометрию сложно сменить в случае утечки.

                                                              Я бы копал в сторону центров выдачи ЭЦП с возможностью отозвать + пропускать через биометрию. Какой нибудь IRIS-сканер с пин-кодом и смарт-картой содержащей ЭЦП. То есть мы имеем три составляющие, одна жестко привязывает к человеку, другая обеспечивает возможность сменить пароль в случае утечки, третья (пин-код) служит признаком добровольности и обеспечивает отзыв ЭЦП в случае серии подбора или ввода тревожного кода.
                                                                0
                                                                Компрометацию центров выдачи ЭЦП вы кажется не учли. Более того, за последнюю пятилетку ситуаций связанных именно с этим было предостаточно, начиная от выдачи левых сертификатов мошенникам в России для всяких кадастров и реестров, заканчивая недавней историей с SSL.
                                                                Причём риск в данном случае ещё выше, т.к. с такой структурой сразу понятно к кому идти и утечка базового сертификата гораздо страшнее, чем взлом любого сайта или менеджера паролей, которые, если нормальные, не видят данные своих клиентов, т.к. они зашифрованы.
                                                                Я уже не говорю что в такой структуре можно выпустить «дубликат» кредов через «дружественный» центр.
                                                                  0
                                                                  Ок, если центр ЭЦП скомпрометирован, это во первых станет довольно быстро известно, во вторых остается фактор биометрии и пинкода (защита для ранее получивших там ЭЦП людей). Собственно скомпрометировав ЭЦП можно нагенерить спамеров с фейковой биометрией. Но их сразу будет видно и все подозрительные ЭЦП отзовут.
                                                                0
                                                                Впервую очередь надо забыть порочную практику использовать логин как имя, и детеоменированный логин в виде мыла или номера телефона.
                                                                у тинькова у меня логин и пароль случайные строки по 25 символов.
                                                                раньше это мог ок.ру, но там теперь и номер телефона работает.
                                                                  0
                                                                  я конечно всего-навсего юзер и не обладаю всей полнотой знания в данном вопросе, во всех статьях которые я читал почему-то нигде не предлагали ввести сложный короткий пароль несколько раз v31T# согласитесь 5-6 значных сложный пароль запомнить гораздо легче чем 25-36 значный.
                                                                    0

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

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

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

                                                                    пример карточки и инструкция к использованию
                                                                    image
                                                                    image

                                                                    Моя демка для генерации собственной карточки sansys.github.io/cryptocard
                                                                      0

                                                                      Все преимущество — что электроники нет. В современных условиях лучше купить самый дешевый (можно даже БУ) китайский смарт, поставить на него CryptoPass, вбить мастер-пароль и генерировать пароли для сайтов в нем.


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

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

                                                                        Далее, как бакапить такие пароли? А то китайский смарт умер, дальше что?

                                                                        Как обеспечить невозможность восстановления пароля путем социнженерии, взлома почты и смены симкарты?
                                                                          0

                                                                          есть ли драйвер для смартфона чтобы прикинуться клавиатурой
                                                                          Я тоже искал. Сам по себе Linux эмулировать HID умеет. Но в том же андроиде это умение с самых ранних версий выключено. Правда, когда Android Pie был на стадии слухов — были статьи, что HID эмуляция таки будет. Но ее, похоже, так и не включили.


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


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


                                                                          Далее, как бакапить такие пароли? А то китайский смарт умер, дальше что?


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


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


                                                                          PBKDF2 вроде бы это и гарантирует.


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


                                                                          Никак. Это за пределами обсуждения. Если сервис позволяет по почте и телефону пароль сбросить и восстановить — то этот риск от способа хранения и генерации пароля не зависит.

                                                                            0
                                                                            Есть убунтофоны всякие, да собственно зачем этому устройству быть вообще телефоном то? Всякие RPI0 и ему подобные подойдут наверное. Возможно я не понял вашу схему, что происходит при вводе мастер-пароля? Если мы бакапим только его, то где хранятся сами пароли? PBKDF2 это стандарт, метод генерации паролей. Как проверить его корректную реализацию?

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

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

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


                                                                              Возможно я не понял вашу схему, что происходит при вводе мастер-пароля?

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


                                                                              Если мы бакапим только его, то где хранятся сами пароли?

                                                                              Нигде. Они каждый раз генерируются из мастер пароля и прямо тут же введенного имени учетной записи. (Собственно, все это написано в описании CryptoPass, которым я предлагал заменить qwertycards, которые делают похожее, но ручным алгоритмом):


                                                                              password = base64(pbkdf2(secret, username@url))

                                                                              PBKDF2 это стандарт, метод генерации паролей. Как проверить его корректную реализацию?

                                                                              Ссылка CryptoPass была на f-droid. Что означает что исходники доступны. Возможно, что PBKDF2 прямо в этих исходниках нет, но тогда реализация системная и ищется в исходниках андроида или используемой библиотеки.

                                                                      0
                                                                      Кто-нибудь знает, какую хэш-функцию использует контроллер домена на Windows Server 2012 R2?
                                                                        0
                                                                        В большой компании сисадмины очень часто сталкиваются с тем, что пользователи забывают свои пароли (привыкли люди, что браузеры и почтовые клиенты запоминают пароли за них); и приходится каждый раз сбрасывать пароли пользователей и заводить их заново (и заставлять пользователя записать в свой блокнот). А еще хуже, когда пользователи держат свои пароли на виду. В своей госбюджетной организации мы боролись с пользователями, наклеивающими стикеры с паролями на мониторы, и все равно не могли это побороть окончательно: обязательно у кого-то где-то проявится (хотя и стало значительно реже). Кто-то иконки со святыми клеит на монитор, а кто-то — стикеры с паролями и также молится на эти листочки — типа как бы не ошибиться при вводе пароля. Хотя бы листочки клали под клавиатуру, а не вешали на самом видном месте! Представьте себе, например, кабинет бухгалтера, каждый день — куча посетителей (своих сотрудников и извне), а на мониторе бухгалтерши висит стикер со всеми паролями (АД, вход в БД, Интернет, почта, банк-онлайн и т.д.) И не мудрено, что периодически какие-нибудь недохакеры (все пароли-то известны) получают нелегальный доступ к БД и пр. авторизованным сервисам, и отследить такие заходы не так просто. Не так давно зашел к одному начальнику отдела, настраивал ему компьютер, а когда он вышел, взял со стола открыто лежащий листок с паролями сотрудников его отдела и тут же отксерил на его МФУ. Потом разбирался с ними и их начальством; ведь так и любой их др. посетитель мог поступить, т.к. посетителей к нему всегда было довольно много.

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

                                                                        Самое читаемое