Pull to refresh

Comments 31

Поясните чем это отличается от двух паролей сразу или от префикса пароля? Вы в начале говорите, что человек не боится рассказать пароль. Но ведь если он расскажет два пароля, то его взломают. А если жена не знает второго пароля (соль/префикс) или его сменить тоже, то она не сможет зайти по одному паролю.
1) Два простых пароля — это пароль чуть сложнее. В моем примере простое секретное слово превращается в хэш, который используется, чтобы солить сам пароль. Это не два пароля вместе. Хэш секретного слова солится на сервере солью, которая нигде не публикуется.

2) Жена знает секретное слово — его можно оставлять прежним. А пароль можно менять и сообщать публично. Но только в троллейбусе, и только если Вашу жену зовут Галя :) Шучу, конечно. Я просто пытался обыграть ситуацию, что простой пароль как будто бы уже известен.
На мой взгляд это просто реализация пароля. То же самое, что брать у каждого пароля первых три символа и солить ими остальную часть пароля. Но это технически. А практически думаю это может быть полезно. Для тех, кто любит поля ввода и боится сделать что-то не так. Про соль объяснить им сложнее. Так что пример с женой весьма рабочий :)
Если Вы берете первые три символа у пароля, тоже самое сделает и скрипт хакера. В моем случае хакер не знает чем солить. Он не может сгенерировать соль, не зная секретного слова. А подставлять просто секретное слово тоже не получится. Его должен захэшировать сервер своей солью, которую хакер не знает.

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

Как этому можно противостоять? Усилить алгоритм ALG2 сложными расчетами, чтобы максимально усложнить перебор секретного слова с заведомо известным паролем.

Но даже без этого, скомпрометированным паролем воспользоваться сразу не удастся.
Представьте, что у меня пароль SaltMypas. Я говорю жене, что любой мой пароль на любых сайтах начинается всегда с Salt, потом идёт Mypas. Потом не боюсь ей в маршрутке сказать, что было Mypas, а стало Mysuperpas. Вот такой префикс я имел в виду. Его хакер по вашей логике тоже не знает. И брутфорс будет такой же по смыслу. Но не придётся делать лишнее поле, и этот способ уже работает везде. А сложность соления и алгоритмы можно делать на любой реализации.
Да, согласен.
Жаль, выглядело неплохо, но действительно моя идея ничем не отличается от пароля, который слепили из двух частей.

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

Жаль, что не увидел это сразу.
Остался сущий пустяк — соль. Но какая соль правильная? Придется ее перебирать и проверять — но это возможно только если вы точно знаете, что пароль правильный.
Если взломщику известны логин и пароль, то перебор секретного слова почти ничем не отличается от обычного перебора пароля. Просто вместо одного запроса к серверу нужно делать два: 1) запрос соли по логину и секретному слову 2) запрос на вход с посоленным паролем.

Современные алгоритмы хеширования достаточно быстрые. Можно генерировать 70 000 SHA-512 хэшей в секунду. Сервер будет дольше обрабатывать запросы, чем хакер отправлять варианты. Можно взять медленную функцию ALG2, но всё равно если пароль известен, то слабое место — это секретное слово.
Современные алгоритмы хеширования достаточно быстрые.

Современные алгоритмы хеширования паролей (KDF) медленные by design, как раз чтобы усложнить взлом (а еще используют много памяти чтобы мешать брутфорсу на GPU). SHA-512 использовать для этой цели некорректно, а скажем, 10000 проходов SHA-512 — уже лучше.
Сервер присылает форму логина с двумя полями: логин + секретное слово, чтобы дать пользователю возможность получить соль.
Пользователь вводит login — alice, secret — cat и нажимает кнопку "Отправить".

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


PS А нет, перечитал внимательнее. Три: login, secret, password. Так?

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

В таком случае ваша задача "Пользователь хочет на сайте иметь пароль «12345»" не выполнена. Потому что пароль в контексте того, что хочет пользователь — это то, с чем он может на этот сайт залогиниться, а в вашем случае для этого нужно два элемента. Вот их оба и надо считать.


Так что в вашем случае пароль у пользователя "cat:12345". Ну и, собственно, вся стойкость вашей системы не сильно меняется по сравнению со стойкостью системы с таким паролем, разве что время на подбор увеличивается за счет того, что надо лишний запрос делать — так и ресурсы вашего сервиса съедаются быстрее.

Вы ошибаетесь.
Если вы возьмете на подбор строку cat12345 — это одно.
Если вы берете cat и шифруете им 12345, то у вас получается вложенная зависимость.
Более того, вы не сообщаете нужно ли брать cat. А может и dog. А может и 42.

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

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

Я не знаю, что такое вложенная зависимость, но я не понимаю, чем ваша схема отличается от "берем первые 30%, но не менее 4 символов, от пароля пользователя, а дальше "шифруем ими" оставшуюся часть пароля".


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

Зачем так сложно? Беру первую позицию из словаря, использую ее в качестве секретного слова, потом вторую — в качестве пароля. Не подошло? Вторую и третью. Третью и четвертую. Первую и третью. Это ничем не отличается от брут-форса пароля, о котором известно, что он состоит из двух слов.


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

Но он же стал сильнее. Его вторая часть будет верной только если вы передадите с ней верную первую, а вариантов первой части у вас — весь словарь.

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

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

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

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

Вспомнил, где я это видел: логин в облачный 1Password. Мастер-ключ (вводится один раз при подключении хранилища на устройство) + пароль (вводится каждый раз при открытии хранилища).


Знаете, в чем отличие? Пароль все равно рекомендуют делать сложным.

Я полностью согласен. Моя задача — попытаться усложнить жизнь мошенникам. Поэтому в концепте заведомо плохие примеры — короткие пароли и нарочито неосторожное поведение пользователей. Мне надо понять слабые места, и вообще определить не ошибся ли я. В реальности я никому не посоветую устанавливать пароль «12345».
Моя задача — попытаться усложнить жизнь мошенникам.

Для этого достаточно использовать хорошие пароли. Там, где все совсем плохо — второй фактор (который не пароль, понятное дело).


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

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

В этот момент где-то тихо всплакнул Intel: а мы же давно предлагали PSN и никакой соли не нужно было бы… а рядом злорадно рассмеялся Google.

Отдельный, кстати, любопытный вопрос в сторону криптостойкости при атаке на конкретного юзера: если послать на сервер ключевое слово P, мы получим в ответ ALG1(P, S), где S — соль для этого юзера. Поскольку P нами контролируется, сервер отвечает всегда, а ALG1 известен, дальше можно узнать S (либо локальным перебором, либо по предрассчитанной таблице). После этого можно вычислять все соленые пароли (т.е. то, что шлется на сервер в последнем шаге) локально, и слать их на сервер, не заморачиваясь предварительным запросом с ключевым словом.

честно говоря ерунда какая-то.
Во-первых данный способ пытается защититься от достаточно специфических случаев: когда злоумышленник в публичном месте услышал пароль и метода перебора. Но вероятность того что он (злоумышленник) окажется в нужном месте в нужное время и поймет о каком сайте идет речь стремится к нулю. Но даже в таком случае если пароль просто менялся, то муж жене продиктует один пароль без логина (так как жена уже знает логин), что само по себе бесполезно. Если же это новая инф-ция для жены, то мужу придется опять же продиктовать и логин и пароль и кодовое слово. Т.е. профит = 0.
Дальше, как пользоваться мужу и жене одним браузером на разными аккаунтами? Как логиниться мужу после жены? Чистить куки?
Против перебора уже есть куча отработанных методов, начиная с требований к сложности пароля и заканчивая счетчиками неудачных попыток
Вряд ли здесь можно придумать что-то новое, над чем тысячи светлых умов уже думали неоднократно.

Мне вообще в статье видится одно большое нарушение первого правила криптографии — не изобретать свои методы криптографии.

Непонятно в чем проблема генерить нормальный пароль.

Кто-то вводит пароли?! Они либо в браузере сохранены, либо в хранилке. Какая разница что будет копипаситься или автоподставляться?

В нормальных сервисах двухфакторная авторизация.

В совсем нормальных ещё и защита по IP. Но это редкость.

Так зачем нам пароль 12345 вообще?
Ранее, когда моб. телефоны еще не были обязательными для всех, сайты некоторых банков и даже Яндекс.Денег тех же использовали именно два пароля. И чем-то похожая схема — первый пароль вводился редко, как бы на его основе создавали кукис. А второй пароль для подтверждения важных действий.

Сейчас для важных сайтов есть SMS и Google Auth, а менее важные сайты могут завязаться на авторизацию того же гугла/фейсбука и иже с ними, которые могут проверить с помощью SMS.
Больше всего меня расстраивает даже не то, насколько ваши статьи наивны, а то что в профиле у вас написано «Software Engineer». Если бы не эта надпись я бы мог тешить себя надеждой что вы студент, ну или там гениальный художник например…
Подытожу все отзывы о вашей задумке — вы заменяете один запрос к серверу во время перебора, на два последовательных. Теоретически, это не плохо, но не надо писать, что пароль и второй пароль могут быть простыми.

То есть пользователь может иметь любой удобный пароль типа 12345, но теперь есть требования к соли? А в чем профит?

Вы на верном пути! Скоро придумаете сделать второй фактор более сложным, сменяемым во времени. И вот уже TOTP аутентификация недалеко!

Only those users with full accounts are able to leave comments. Log in, please.