Comments 31
2) Жена знает секретное слово — его можно оставлять прежним. А пароль можно менять и сообщать публично. Но только в троллейбусе, и только если Вашу жену зовут Галя :) Шучу, конечно. Я просто пытался обыграть ситуацию, что простой пароль как будто бы уже известен.
Предположим самое худшее — хакер решил брутфорсить не пароль, а секретное слово. Логин он знает, пароль тоже. Ему осталось зашифровать пароль и отправить его на сервер. Алгоритм хэширования у него тоже есть. Остался сущий пустяк — соль. Но какая соль правильная? Придется ее перебирать и проверять — но это возможно только если вы точно знаете, что пароль правильный.
Как этому можно противостоять? Усилить алгоритм ALG2 сложными расчетами, чтобы максимально усложнить перебор секретного слова с заведомо известным паролем.
Но даже без этого, скомпрометированным паролем воспользоваться сразу не удастся.
Жаль, выглядело неплохо, но действительно моя идея ничем не отличается от пароля, который слепили из двух частей.
С точки зрения хакера, он делает запросы «слово + пароль» для каждого аккаунта и получает все комбинации. Единственное, что его стесняет это дополнительные запросы к серверу для получения соли для каждого из пользователей вместо того, чтобы сразу получить ответ на нужную склеенную пару. А это и наши расходы в том числе. Их можно создать и без дополнительных солей.
Жаль, что не увидел это сразу.
Остался сущий пустяк — соль. Но какая соль правильная? Придется ее перебирать и проверять — но это возможно только если вы точно знаете, что пароль правильный.Если взломщику известны логин и пароль, то перебор секретного слова почти ничем не отличается от обычного перебора пароля. Просто вместо одного запроса к серверу нужно делать два: 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 символов, от пароля пользователя, а дальше "шифруем ими" оставшуюся часть пароля".
Технически Вам нужно перебрать все простые секретные слова по словарю и получить от сервера хэши. А потом перебрать со всеми этими хешами один простой пароль. Потом взять второй простой пароль и перебрать с ним все хэши опять. Потом третий, и так далее.
Зачем так сложно? Беру первую позицию из словаря, использую ее в качестве секретного слова, потом вторую — в качестве пароля. Не подошло? Вторую и третью. Третью и четвертую. Первую и третью. Это ничем не отличается от брут-форса пароля, о котором известно, что он состоит из двух слов.
Это не тоже самое, что слепить две строки в одну и сказать, что пароль стал якобы сильнее.
Но он же стал сильнее. Его вторая часть будет верной только если вы передадите с ней верную первую, а вариантов первой части у вас — весь словарь.
С точки зрения взломщика, перебор конечно усложняется, но не становится невозможным. Просто вместо N паролей из словаря придётся перебирать N*N паролей из того же словаря. И для каждой пары будет делаться два запроса: сначала запрос на получения соли, потом запрос на вход с паролем.
Идея интересная, но боюсь будет сложно объяснить среднестатистическому пользователю зачем ему вводить два пароля, когда на всех других сайтах достаточно одного.
Технически секретное слово может быть как пустым, так и идентичным паролю. Но это, конечно, серьезно упростит перебор паролей.
Субъективно, я не считаю дополнительное поле сложным, хотя опыта в этой сфере у меня маловато (я про юзабилити и UI). Ведь есть, например, галочка «сохранить пароль», которая тоже потенциально отнимает внимание пользователя.
Вспомнил, где я это видел: логин в облачный 1Password. Мастер-ключ (вводится один раз при подключении хранилища на устройство) + пароль (вводится каждый раз при открытии хранилища).
Знаете, в чем отличие? Пароль все равно рекомендуют делать сложным.
Моя задача — попытаться усложнить жизнь мошенникам.
Для этого достаточно использовать хорошие пароли. Там, где все совсем плохо — второй фактор (который не пароль, понятное дело).
заведомо плохие примеры — короткие пароли и нарочито неосторожное поведение пользователей.
...удобное вам поведение. Потому что ваш пользователь кричит "мне дали пароль", но почему-то не кричит "я выбрал ключевым словом имя нашей кошки". Хотя вероятность обоих событий приблизительно одинакова.
Отдельный, кстати, любопытный вопрос в сторону криптостойкости при атаке на конкретного юзера: если послать на сервер ключевое слово P, мы получим в ответ ALG1(P, S), где S — соль для этого юзера. Поскольку P нами контролируется, сервер отвечает всегда, а ALG1 известен, дальше можно узнать S (либо локальным перебором, либо по предрассчитанной таблице). После этого можно вычислять все соленые пароли (т.е. то, что шлется на сервер в последнем шаге) локально, и слать их на сервер, не заморачиваясь предварительным запросом с ключевым словом.
честно говоря ерунда какая-то.
Во-первых данный способ пытается защититься от достаточно специфических случаев: когда злоумышленник в публичном месте услышал пароль и метода перебора. Но вероятность того что он (злоумышленник) окажется в нужном месте в нужное время и поймет о каком сайте идет речь стремится к нулю. Но даже в таком случае если пароль просто менялся, то муж жене продиктует один пароль без логина (так как жена уже знает логин), что само по себе бесполезно. Если же это новая инф-ция для жены, то мужу придется опять же продиктовать и логин и пароль и кодовое слово. Т.е. профит = 0.
Дальше, как пользоваться мужу и жене одним браузером на разными аккаунтами? Как логиниться мужу после жены? Чистить куки?
Против перебора уже есть куча отработанных методов, начиная с требований к сложности пароля и заканчивая счетчиками неудачных попыток
Вряд ли здесь можно придумать что-то новое, над чем тысячи светлых умов уже думали неоднократно.
Кто-то вводит пароли?! Они либо в браузере сохранены, либо в хранилке. Какая разница что будет копипаситься или автоподставляться?
В нормальных сервисах двухфакторная авторизация.
В совсем нормальных ещё и защита по IP. Но это редкость.
Так зачем нам пароль 12345 вообще?
Сейчас для важных сайтов есть SMS и Google Auth, а менее важные сайты могут завязаться на авторизацию того же гугла/фейсбука и иже с ними, которые могут проверить с помощью SMS.
То есть пользователь может иметь любой удобный пароль типа 12345, но теперь есть требования к соли? А в чем профит?
Вы на верном пути! Скоро придумаете сделать второй фактор более сложным, сменяемым во времени. И вот уже TOTP аутентификация недалеко!
Концепт — как усилить защиту паролей «12345» от bruteforce атаки (попытка вторая)