Основы безопасности на основе строковых протоколов - PullRequest
5 голосов
/ 28 января 2010

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

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

Аутентификация транзакции: Клиент подключается, и сразу же ответ на вызов отправляется с шестнадцатеричной строкой из 16 символов. Клиентская сторона принимает имя пользователя и пароль, пароль преобразуется в sha1 (соль + sha1 (пароль)), а учетные данные отправляются обратно на сервер как {имя пользователя, пароль}. На стороне сервера аутентификация выполняет стандартный шаблон поиска (если пользователь существует и имеет пароль, равный вводу, то предоставляет).

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

Я что-то упустил? Есть ли лучший / более безопасный подход для протокола на основе символьного потока?

Ответы [ 2 ]

6 голосов
/ 28 января 2010

Протокол, который вы описали, направлен на одну атаку, то есть атаку с повторным воспроизведением. Тем не менее, вы очень уязвимы для атак MITM. Соединение TCP не будет разорвано, когда атакующий переместится по протоколу. Более того, все, что передается по этой системе, может быть обнаружено. Если вы используете беспроводную связь в кафе, все в этом районе смогут прослушивать все, что передается, а затем MITM аутентифицированный сеанс. Другое дело, что sha1 () оказывается небезопасным, вы должны использовать sha256 для всего, что связано с безопасностью.

НИКОГДА НЕ ПОВЫШАТЬ КОЛЕСО, особенно когда речь идет о безопасности.

Используйте SSL! Каждый использует SSL, и у него долгая история доказанной безопасности, и это то, что вы не можете построить. SSL Не только решена атака «Человек посередине», но вы также можете использовать сертификаты вместо паролей для аутентификации клиента и сервера, что делает вас невосприимчивым к грубой силе. Солнце сгорит, прежде чем злоумышленник сможет перебить 2048-битный сертификат RSA. Отец, тебе больше не нужно беспокоиться о том, что пипетка накануне нюхает передачу.

Имейте в виду, что OpenSSL БЕСПЛАТНО, генерация сертификатов БЕСПЛАТНА, а пение сертификатов БЕСПЛАТНО. Хотя единственная причина, по которой вы хотите подписать сертификат, заключается в том, что вы хотите реализовать PKI, что, вероятно, не является необходимым. У клиента может быть жесткий код открытого ключа сервера для проверки соединения. Сервер может иметь базу данных открытых ключей клиента. Эта система будет автономной и не потребует OCSP или CRL или какой-либо другой части инфраструктуры открытого ключа.

1 голос
/ 28 января 2010

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

Я бы предложил вместо этого реализовать протокол SRP 6 . Доказано, что он безопасен, обеспечивает целостность соединения и даже создает общий секрет, который можно использовать для установления симметричного шифрования. Протокол выглядит немного сложным на первый взгляд, но на самом деле его довольно легко реализовать. На веб-сайте проекта также имеется демонстрация JavaScript, содержащая ссылки на несколько реализаций на разных языках.

...