Можно ли не передавать пароль на сервер, а шифровать им соединение (например, через сокеты)?

Question

[Всеволод Родионов]

Почему нет веб-приложений, которые используют примерно такую схему безопасности:
p - пароль, F(p) - функция высшего порядка, которая принимает на вход пароль и возвращает функцию, шифрующую (синхронным шифрованием) текст при помощи пароля, вроде

function getEncoder(password){
return function(message){ return encode(message, hash(password)); }
}

На сервер отправляется сообщение формата {login, F(p)(login)}, на сервере так же хранится хэш пароля, при помощи которого и расшифровывается.
Если нужно увеличить сложность - можно использовать в качестве ключа что-то вроде (uniq_salt передается с сервера, для каждого соединения новая) blowfish(blowfish(uniq_salt) XOR blowfish(password)), например. Достаточно длинная соль сделает подбор практически нереальным.

Все дальнейшее общение между сервером и клиентом идет уже зашифрованным, пароль не передается, вроде все безопасно, нет?

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

Answer 1

[Армянское Радио]

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

• клиент подключается к серверу, поддерживающему TLS, и запрашивает защищённое соединение;
• клиент предоставляет список поддерживаемых алгоритмов шифрования и хеш-функций;
• сервер выбирает из списка, предоставленного клиентом, наиболее надёжные алгоритмы среди тех, которые поддерживаются сервером, и сообщает о своём выборе клиенту;
• сервер отправляет клиенту цифровой сертификат для собственной аутентификации. Обычно цифровой сертификат содержит имя сервера, имя удостоверяющего центра сертификации и открытый ключ сервера;
• клиент может связаться с сервером доверенного центра сертификации и подтвердить аутентичность переданного сертификата до начала передачи данных;
• для генерации сеансового ключа для защищённого соединения клиент шифрует случайно сгенерированную цифровую последовательность открытым ключом сервера и посылает результат на сервер. Учитывая специфику алгоритма асимметричного шифрования, используемого для установления соединения, только сервер может расшифровать полученную последовательность, используя свой закрытый ключ.

Comments

[Всеволод Родионов]

вопрос был скорее "а почему нельзя использовать пароль как ключ?".

[Всеволод Родионов]

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

[Армянское Радио]

Потому, что пароль в чистом виде в качестве ключа - ненадежен, подберут. Поэтому появляется желание добавить соль. И какой тогда смысл в постоянной части ключа, когда можно каждый раз создавать полностью новый?

[Ярослав Астафьев]

Я уже представляю статьи на хабре, в которых говорят: ну подставляем в функцию в качестве ключа "qwerty" и получаем всю подноготную.
Чем вам SSL\RSA не угодил?

[leverun]

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

[Армянское Радио]

Vitaly Antsiferov: HTTPS расшифровывается на клиента, провайдер видит передаваемые данные в шифрованном виде.

Answer 2

[bogolt]

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

Сложность как раз в том чтобы распределить ключи между двумя сторонами, так чтобы никто не смог их перехватить и/или подделать.
В общем публичные ssh ключи установленные на веб серверах как раз и решают эту задачу только с обратной стороны. Они дают клиенту в руки пароль для отправки сообщений на сервер, которые нельзя незаметно подделать.

Answer 3

[other_letter]

Я полагаю, что человек ищет возможность безопасно обмениваться данными с доверенным источником через недоверенные (инет) транспорты