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

Question

Несмотря на все советы по использованию SSL / https / и т.д.Я решил реализовать свой собственный уровень безопасности поверх http для моего приложения ... Концепция работает следующим образом:

User registers -> a new RSA Keypair is generated
the Private Key gets encrypted with AES using the users login Password
(which the server doesnt know - it has only the sha256 for authentication...)

Server stores the hash of the users password
 and the Encrypted Private Key and Public Key

User logs in -> authenticates with nickname+password hash
(normal nick/password -> IP-bound sessionid authentication)
Server replies: sessionid, the Encrypted RSA Private Key
    and an Encrypted randomly generated Session Communication Password

Client decrypts the RSA Private Key with the users Password
Client decrypts the Session Communication Password with the RSA Private Key

---> From this point on the whole traffic gets AES-encrypted
     using that Session Password

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

Answer 1

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

Помните, HTTPS также включает аутентификацию (например: возможность узнать, что вы на самом деле говорите с тем, о ком вы думаетеto), поэтому существует PKI, и браузеры поставляются с корневыми CA.Это просто чрезвычайно сложно (если не невозможно) изобрести заново и склонно к дырам в безопасности.Чтобы ответить на ваш вопрос, как вы защищаетесь от MITM-атак ?

TLDR: Не делайте этого.SSL / TLS работают просто отлично.

/endrant.

Answer 2

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

Нет способа узнать, что клиент выполняет крипто-код right . С SSL / TLS существует согласованный стандарт, который реализовали как ваш поставщик браузеров, так и поставщик серверного программного обеспечения. Вам не нужно сообщать браузеру, как работает SSL, он встроен, и вы можете быть уверены, что он работает правильно и безопасно. Но, в вашем случае, браузер узнает о правильном протоколе, только получая текстовый JavaScript с вашего сервера.

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

Это самый большой недостаток, и я подозреваю, что это фатальный недостаток для вашего решения. Я не вижу способа обойти это. Пока ваша система полагается на доставку своего крипто-кода клиенту, вы всегда будете подвержены атакам типа «человек посередине». Если, конечно, вы не доставили этот код по SSL:)

Answer 3

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

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

Имейте в виду, если вы неЕсли вы не используете TLS / SSL, то вы не получите аппаратно-ускоренное шифрование (оно будет медленнее, вероятно, заметно).

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

Answer 4

SSL / TLS обеспечивают безопасность транспортного уровня, и то, что вы сделали, ничего не делает, но делает это снова и снова только для процесса авторизации.Лучше сосредоточиться на методах авторизации, таких как клиентские сертификаты, чем добавлять дополнительный уровень шифрования на уровне линии.Вы также можете рассказать о некоторых вещах, которые вы не упомянули, например о зашифрованных столбцах в SQL Server 2008, IPSec, аппаратных решениях уровня 4 и 7 и даже о настройке отношений доверия между брандмауэрами сервера и клиента.Меня больше всего беспокоит то, как вы создали такую ​​глубокую зависимость от имени пользователя и пароля, которые могут со временем меняться в любой системе.

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

Answer 5

Хотя я бы также выступал за использование SSL / TLS для такого рода вещей, нет ничего плохого в том, чтобы заново изобретать колесо;это приводит к инновациям, таким как серия веб-сайтов обмена стеками.

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

Некоторые проблемные области:

-Как вы обрабатываете первоначальное общение, например: логин пользователя, регистрация?

-Что оатаки типа «человек посередине» (заверение клиента в том, что он общается с авторизованным сервером)?

Answer 6

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

Обратите внимание, что я имею в виду не вашу конкретную идею (которую я не нашел времени, чтобы полностью понять), а общую концепцию шифрования Javascript.

Answer 7

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

Это дает Man-In-The-Middle множество вариантов.Он может изменить код так, чтобы он все еще аутентифицировался на вашем сервере, но также отправил ему пароль / закрытый ключ / открытый текст разговора.