Задать вопрос

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

Почему нет веб-приложений, которые используют примерно такую схему безопасности:
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)), например. Достаточно длинная соль сделает подбор практически нереальным.

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

Я не криптограф, объясните мне, в чем я не прав, или почему это не делают, пожалуйста.
  • Вопрос задан
  • 3097 просмотров
Подписаться 4 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 3
gbg
@gbg
Любые ответы на любые вопросы
TLS примерно так и работает.
Проблема правда в том, что ключ надо как-то передать на сервер в первый раз, а для этого нужно асимметричное шифрование.
  • клиент подключается к серверу, поддерживающему TLS, и запрашивает защищённое соединение;
  • клиент предоставляет список поддерживаемых алгоритмов шифрования и хеш-функций;
  • сервер выбирает из списка, предоставленного клиентом, наиболее надёжные алгоритмы среди тех, которые поддерживаются сервером, и сообщает о своём выборе клиенту;
  • сервер отправляет клиенту цифровой сертификат для собственной аутентификации. Обычно цифровой сертификат содержит имя сервера, имя удостоверяющего центра сертификации и открытый ключ сервера;
  • клиент может связаться с сервером доверенного центра сертификации и подтвердить аутентичность переданного сертификата до начала передачи данных;
  • для генерации сеансового ключа для защищённого соединения клиент шифрует случайно сгенерированную цифровую последовательность открытым ключом сервера и посылает результат на сервер. Учитывая специфику алгоритма асимметричного шифрования, используемого для установления соединения, только сервер может расшифровать полученную последовательность, используя свой закрытый ключ.
Ответ написан
bogolt
@bogolt
В вашей же схеме предусматривается что обе стороны уже владеют одним общим ключом для связи друг с другом. В этом случае ваша схема будет работать, так как это будет обычное шифрование любым блочным шифром.

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

Войдите, чтобы написать ответ

Похожие вопросы
Rocket Смоленск
от 80 000 до 130 000 ₽
div. Ставрополь
от 40 000 до 90 000 ₽
Wanted. Санкт-Петербург
До 220 000 ₽
18 дек. 2024, в 11:03
5000 руб./за проект
18 дек. 2024, в 10:44
130000 руб./за проект
18 дек. 2024, в 10:02
7000 руб./за проект