Pull to refresh

Comments 31

Вы упустили момент, что TLS защищает только трафик между клиентом и сервером, но при этом, он не сильно защищает от атаки Man-in-the-middle, если вы будете доверять атакующему.

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

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

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

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


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

Это не совсем делает затею бессмысленной, есть варианты атак от которых схема valve защищает. Например если ты такой гос-MITM и просто записываешь трафик, то у тебя не получится узнать пароль в ретроспективе. Тебе нужно провести подобны reverse-engineering для касмотной системы авторизации, подготовить атаку и ждать новой авторизации. Можно усложнить reverse engendering если использовать не известные RSA JS библиотеки, а что-то вроде WASM.


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

Это, скажем так, сводит всю затею к "злоумышленнику будет лень ковырять", т.е. security via obscurity.


Думаю в случае с valve или любой другой крупной компании государев mitm уже заранее будет сконфигурирован как надо. А неуловимые Джо — они и в Африке такие. И никакой WASM не защищает от скрипта, который просто повесит глобальный хук на onkeydown. Ну и если у вас в канале сидит MITM — очевидно, он может предоставляться тем же IP, что и у клиента.

«Цена атаки» в этой ситуации станет дороже «цены защиты».

Т.е. да, можно, а что дальше? Что ты получишь? Только доступ к стиму для данного аккаунта? Зачем это нужно государству?
Посмотреть в какие игры ты играешь? Они могут данные потребовать у стима напрямую.

Я думаю что это больше защита от разного уровня script kiddie, и от автоматических логгеров трафика которые будут анализировать весь трафик на ключевые слова «username + password» и записывать данные.

Ну как же. Взломав и получив доступ к одному ресурсу, можно попытаться получить доступ к другим, более интересным для «определенных человечков».

"злоумышленнику будет лень ковырять", т.е. security via obscurity.

Нет абсолютных способов защиты, есть лишь достаточные для той или иной ситуации.

Это, скажем так, сводит всю затею к "злоумышленнику будет лень ковырять", т.е. security via obscurity.

Obscurity это нормальный дополнительный уровень к security (в данном случае TLS). Государеву mitm нужно решать на что тратить ресурсы, obscurity может отпугнуть если это не особо важно, или алгоритм меняется раз в месяц.


И никакой WASM не защищает от скрипта, который просто повесит глобальный хук на onkeydown

Раньше на сайтах банков были OnScreenKeyboard. Я согласен, но это все равно уже активная атака, когда вы не можете узнать пароль просто по трафику. Это кстати может не только на стороне клиента, на стороне серверной архитектуры там где вы делаете TLS-termination и пакеты ходят в открытом виде внутри серверной сети, они остаются в закрытом виде не утекают дальше.


Ну и если у вас в канале сидит MITM — очевидно, он может предоставляться тем же IP, что и у клиента.

Верно, но лимит все равно есть: пароль так и не узнали и использовать аккаунт с другого IP невозможно.


Javascript-based криптография выглядит с точки зрения теории действительно не надежной. CrypoAPI насколько я знаю Chrome/Firefox отключают в скриптах когда к нему обращаются со странички полученной не по https.

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

Имея mitm, все эти "идеи" решаются тривиально. Достаточно отдать слегка модифицированный скрипт, который перед отправкой всей этой трахомудной rsa, просто добавит в заголовок:
X-NSA-Submit: steam_password_in_plain_text


А mitm-прокси всё передаст как есть, но вырежет X-NSA заголовок. А вот теортическая возможность коду в браузере проверить свою целостность — это вопрос удивительной глубокой философско-математической природы, не решённый в настоящий момент.

Похоже на упрощенную версию SRP-6, в которой пароль не покидает браузер и при регистрации тоже. Защищен от MITM, и от дыр в старом TLS и через HTTP можно, если нужно.

Каким образом это защищает от mitm? Если я на каждую страницу дописываю <script src='mitm.js'>, то каким образом танцы в одном js защитят от другого?

Ну да, только от подслушивающего MITM.

Это не mitm, а просто "перехват трафика". Mitm подразумевает возможность модификации трафика.

Вообще mitm.js тут ни при чем. SRP-6 про аутентификацию, а не доставку контента. Доставить код клиенту можно разными способами — подписанный exe, apk из google play, в конце концов можно попросить его написать код самому, на протокол аутентификации это не влияет.
А во время аутентификации по SRP-6 mitm не сможет прикинуться сервером не имея БД или прикинуться юзером, пронаблюдав за предыдущими сессиями. Так что да, защищает.
Возможно перекрытие ключей по времени нужно чтобы небыло ошибок авторизации при входе в конце часа. Думаю он несколько первых секунд часа должен позволять войти по старому ключу, чтобы компенсировать сетевые задержки.
Да нет, там же таймштамп ключа передается вместе с шифрованным паролем и если вы получили таймштамп ключа прошлого часа, то вы понимаете что попали на границу.

Интересно, чем их HTTP Digest Auth не устроила.

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


Ещё лучше — если после регистрации для того чтобы залогиниться нужно было сначала спросить у сервиса соль для логина и отправлять ему hash(hash(login+password)+salt). Тогда сервер может убедиться, что пользователь знает пароль, но если этот хеш логина будет перехвачен злоумышленником — ничего полезного он не получит, т.к. при следующем логине сервис выдаст уже другую соль для авторизации и перехваченный хеш не поможет.


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

Сомнительно…
Чем это эффективнее SSL?


Это помогало бы от того, что сервисы в итоге ломают и пароли утекают
так на сервере это и надо так хранить с солькю и спец. шешированием для паролей. но рутина с запрашиванием хеша у сервера сомнительна.
Как-то сделал на одном сервисе подобный логин через HTTP.
Единственный плюс: пароль пользователя дальше браузера не уплывает. Но толку-то? Если сервис взломают, или при MiM-атаке, могут вставить JS скрипт, а там уже все пароли уплывут.
Гораздо привычнее использовать обычный HTTPS с хешами и солью + двуфакторная авторизация, если кому надо.

В таком случае нужно хранить пароль в открытом виде, что само по себе так себе идея. Да, можно хранить условный hash(login+password), но это эквивалетно хранению пароля в открытом виде, т.к. для аутентификации в таком случае нужно знание не пароля, а этого самого hash(login+password).

Соль используют для защиты от быстрого перебора радужными таблицами.
По этому в предлагаемом варианте более верным и чуть более полезным будет вариант такой: hash(hash(login+pass+salt1)+salt2)
salt1 генерируется при создании/обновлении пароля
salt2 генерируется на каждую аутентификацию
При аутентификации передаются обе соли.
Что мешает использовать простое XOR шифрование?
pass = 512bit
k_user = rand(512bit)
to_server = pass XOR k_user
k_server = rand(512bit)
to_user = to_server XOR k_server
to_server_clear = to_user XOR k_user
pass = to_server_clear XOR k_server

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

Автор сильно удивится что обычный md5 вместо пароля с меткой времени полученной с сервера и логином для повышения уникальности хешей сработал бы точно также

выяснил, что 3600000000 микросекунд равно одному часу

Жаль, не раскрывается, каким образом автор это выяснил

Такая методика конечно помешает получить пароль в открытом виде, но она же совершенно не защищает от Man-in-the-middle, только от перехвата трафика? То есть полностью TLS эта система всё равно не заменит.
UFO just landed and posted this here
Sign up to leave a comment.

Articles