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

Несмотря на все советы по использованию SSL/https/etc. Я решил реализовать свой собственный уровень безопасности поверх 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

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

Ответы

Ответ 1

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

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

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

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

Ответ 2

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

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

TL;DR: Не делайте этого. SSL/TLS работает нормально.

/endrant.

Ответ 3

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

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

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

Вы также должны рассмотреть возможность использования HMAC с твистом простого использования пароля пользователя в качестве ключа криптографии.

Ответ 4

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

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

Ответ 5

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

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

Некоторые проблемы, вызывающие озабоченность:

-Как вы обрабатываете начальную связь, такую ​​как: вход в систему, регистрация?

-Что насчет атак типа "человек-в-середине" (заверив клиента, что он разговаривает с авторизованным сервером)?

Ответ 6

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

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

Ответ 7

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

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