Основы безопасности строкового протокола

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

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

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

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

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


python networking encryption cryptography twisted
person David    schedule 28.01.2010    source источник
comment
Это в основном ietf.org/rfc/rfc2617.txt Digest Authentication?   -  person S.Lott    schedule 28.01.2010
comment
@ S.Lott На самом деле довольно близко, потому что я частично смоделировал свою текущую реализацию.   -  person David    schedule 28.01.2010
comment
@ Дэвид: Почему ты просто не используешь его полностью? Почему вы опускаете qop и одноразовый номер клиента?   -  person S.Lott    schedule 28.01.2010
comment
Как создается 16-символьная шестнадцатеричная строка (я предполагаю, что это то, что вы позже назовете солью)?   -  person caf    schedule 29.01.2010
comment
@caf uuid.uuid4 (). hex [: 16] - усечено до 16, потому что я использую функцию makeID () из централизованного служебного модуля, который представляет собой просто код, для которого я не нашел подходящего дома, или аналог Python Макро. Очень легко можно было бы сделать его полноценным 32.   -  person David    schedule 29.01.2010
comment
@ S.Lott в качестве единственной разумной рекомендации, относящейся к моему протоколу, не могли бы вы задать вопрос, обобщающий ваши комментарии, чтобы я мог отметить вас как правильного.   -  person David    schedule 30.01.2010

Ответы (2)


arrow_upward
6
arrow_downward

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

НИКОГДА НЕ ИЗОБРАЖАЙТЕ КОЛЕСО, особенно когда дело касается безопасности.

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

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

person rook    schedule 28.01.2010
comment
+1 SSL. Использование SSL - это не волшебная палочка, и уязвимости будут (и были). Однако многие люди обращают внимание на SSL и исправляют эти уязвимости за вас. Когда вы изобретаете новую схему безопасности, весьма вероятно, что единственные люди, которые ищут в ней уязвимости, - это люди, пытающиеся атаковать вас. Они не собираются исправлять ваши уязвимости, когда обнаруживают их, они собираются их использовать. - person Jean-Paul Calderone; 28.01.2010
comment
Ааа, да, я вижу многообещающие дебаты о безопасности в безвестности. Вы не знаете, насколько что-то безопасно, пока оно не сломается. Чем больше вы будете смотреть на проблему, тем лучше будет система. - person rook; 28.01.2010
comment
Я полагаю, вы считаете, что сам протокол работает, если предлагаете дополнения к транспортному уровню? - person David; 28.01.2010
comment
Если вы используете SSL, помните, что клиент должен проверить правильность сертификата сервера. Это не обязательно делается автоматически вашей библиотекой SSL! Слишком много приложений пропускают это, но TLS / SSL полностью уязвим для атак MITM, если вы принимаете любой случайный сертификат. - person Baffe Boyois; 28.01.2010
comment
@Baffe, да, вы могли бы использовать полную PKI, и это сексуально. Но более простой реализацией было бы жестко закодировать открытый ключ сервера в клиенте. На сервере также должен быть список открытых ключей клиентов, если вы хотите аутентифицировать клиентов с помощью асимметричной криптографии. - person rook; 28.01.2010
comment
SSL может быть очень дорогостоящим решением, если вы работаете с большим количеством отдельных узлов. - person jathanism; 28.01.2010
comment
SSL-сертификаты бесплатны, если вы их подписываете. Их подписание необходимо только в том случае, если вы идете по маршруту PKI, что, вероятно, является излишним. Я не думаю, что Synack или Baffe когда-либо использовали SSL вне https. - person rook; 28.01.2010
comment
Я не имел в виду, что вам нужен сертификат, выданный каким-либо конкретным органом, который поддерживается вашим браузером. Вы, безусловно, можете настроить свой собственный CA и принимать только сертификаты, подписанные им. Я хотел отметить, что вы можете слишком легко принять ЛЮБОЙ сертификат, не заметив, что вы злоупотребляете библиотекой SSL. - person Baffe Boyois; 29.01.2010

arrow_upward
1
arrow_downward

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

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

person x4u    schedule 28.01.2010
comment
Как ты думаешь, что со мной не так? Думаю, если бы SSL был вариантом, Дэвид не задавал бы этот вопрос. Кстати, SRP не только более безопасен, но и имеет ряд других преимуществ по сравнению с SSL. см. srp.stanford.edu/analysis.html. - person x4u; 28.01.2010
comment
Вы также изобретаете волдыри на своей машине, чтобы ездить на работу? - person rook; 28.01.2010
comment
@unknown: все использует ssl ?! Действительно?? Все? Я согласен с тем, что SSL является стандартом для связи между компьютерами через Интернет, но это еще не все. Есть много случаев, когда накладные расходы SSL слишком велики (встроенные устройства) или когда TCP недоступен, поэтому о SSL не может быть и речи. Также во многих случаях необходима только аутентификация, а полнопотоковое шифрование - нет. - person D.Shawley; 28.01.2010
comment
Где я изобретал велосипед? SRP - это ничего, что я мог бы изобрести. Просто это один из самых продвинутых протоколов аутентификации, доступных сегодня. По совпадению, SRP-6 недавно был предложен для улучшения аутентификации TLS / SSL в RFC 5054. Так что, если вам повезет, вы найдете реализацию SSL, которая уже поддерживает это, но может потребоваться дорогой и труднодоступный сертификат CA. - person x4u; 28.01.2010
comment
SSL доступен на каждой отдельной платформе, которая стоит того. Любая платформа, которая может использовать SRP, SSL, будет проще и безопаснее. Нет абсолютно никаких причин не использовать SSL. Я был немного резок, мне очень жаль, что SRP - классный протокол, и он более безопасен, чем OP. - person rook; 28.01.2010