Какие атаки возможны в отношении моей концепции уровня безопасности?
Несмотря на все советы по использованию 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
Я не обнаружил дыры в этой цепочке - ни закрытый ключ, ни пароль входа никогда не отправляются на сервер как открытый текст (я не использую файлы cookie, чтобы исключить возможность того, что заголовок HTTP Cookie может содержать конфиденциальную информацию) ... но я предубежден, поэтому я спрашиваю - обеспечивает ли моя реализация безопасности достаточную ... безопасность?
6 ответов
Я никоим образом не эксперт по криптографии или безопасности, но я вижу один серьезный недостаток:
Клиент никак не может знать, что он использует правильный криптографический код. Для SSL/TLS существует согласованный стандарт, который реализован как вашим поставщиком браузера, так и поставщиком серверного программного обеспечения. Вам не нужно сообщать браузеру, как работает SSL, он встроен, и вы можете быть уверены, что он работает правильно и безопасно. Но в вашем случае браузер узнает о правильном протоколе, только получив обычный текстовый JavaScript с вашего сервера.
Это означает, что вы никогда не можете быть уверены, что клиент на самом деле использует правильный криптографический код. Любой посредник может доставить JavaScript, который ведет себя так же, как сценарий, который вы обычно обслуживаете, за исключением того, что он отправляет все расшифрованные сообщения на серверы злоумышленника. И у клиента нет возможности защититься от этого.
Это самый большой недостаток, и я подозреваю, что он фатальный для вашего решения. Я не вижу способа обойти это. Пока ваша система полагается на доставку вашего криптографического кода клиенту, вы всегда будете подвержены атакам «человек посередине». Если, конечно, вы не доставили этот код по SSL :)
Похоже, вы сделали больше сложности, чем нужно, что касается "доморощенного". В частности, я не вижу необходимости использовать асимметричные ключи. Если сервер уже знает хешированный пароль пользователя, то просто попросите клиента сгенерировать идентификатор сеанса, включенный в дайджест сообщения (симметрично), зашифрованный с помощью хешированного пароля клиента.
Лучшее, что может сделать злоумышленник, это перехватить этот первоначальный трафик и попытаться ответить на атаку... но злоумышленник не поймет ответ сервера.
Имейте в виду, что если вы не используете TLS/SSL, то вы не получите аппаратно-ускоренное шифрование (оно будет медленнее, наверное, заметно).
Вам также следует рассмотреть возможность использования HMAC, с изюминкой простого использования пароля пользователя в качестве криптографического ключа.
SSL/TLS обеспечивают безопасность на транспортном уровне, и то, что вы сделали, не делает ничего, кроме повторения всего этого только для процесса авторизации. Вам лучше сосредоточиться на методах авторизации, таких как клиентские сертификаты, чем добавлять дополнительный уровень шифрования на уровне строки. Вы также могли бы представить ряд вещей, которые вы не упомянули, например, зашифрованные столбцы в SQL Server 2008, IPSec, аппаратные решения уровней 4 и 7 и даже настройку доверительных отношений между сервером и клиентскими брандмауэрами. Больше всего меня беспокоит то, как вы создали такую глубокую зависимость от имени пользователя и пароля, которые со временем могут измениться в любой системе.
Я бы настоятельно рекомендовал вам пересмотреть этот подход и использовать более стандартные методы для обеспечения того, чтобы учетные данные никогда не хранились в незашифрованном виде на сервере и не передавались в открытом виде от клиента.
Основная проблема, с которой вы столкнулись, заключается в том, что криптографический код вашего клиента доставляется в виде Javascript через неаутентифицированный HTTP.
Это дает «Человеку посередине» множество возможностей. Он может изменить код так, чтобы он по-прежнему аутентифицировался на вашем сервере, но также отправлял ему пароль/закрытый ключ/открытый текст разговора.
Шифрования JavaScript может быть достаточно, когда ваш противник является перехватчиком, который может видеть ваш трафик, но не изменять его.
Пожалуйста, обратите внимание, что я имею в виду не вашу конкретную идею (на полное понимание которой у меня не было времени), а общую концепцию шифрования Javascript.
Хотя я бы также рекомендовал использовать SSL/TLS для подобных вещей, нет ничего плохого в том, чтобы заново изобрести велосипед; это приводит к инновациям, таким как серия веб-сайтов по обмену стеками.
Я думаю, что ваша модель безопасности вполне достаточна и достаточно интеллектуальна, хотя что вы используете на стороне клиента? Я предполагаю, что javascript, так как вы пометили этот пост «веб-разработкой»? Или вы используете это для связи с каким-то плагином? Сколько накладных расходов производит ваша реализация?
Некоторые проблемы, вызывающие озабоченность:
-Как вы обрабатываете первоначальные сообщения, такие как: вход пользователя в систему, регистрация?
- А как насчет атак «человек посередине» (уверение клиента в том, что он разговаривает с авторизованным сервером)?