Двустороннее шифрование пароля без ssl

Question

Я использую Twitter-API Basic-Auth ( больше не доступен ) для интеграции Twitter с системой комментариев моего блога. Проблема с этим и многими другими веб-API заключается в том, что им требуется имя пользователя и пароль пользователя, чтобы сделать что-нибудь полезное. Я не хочу иметь дело с хлопотами и стоимостью установки SSL-сертификата, но я также не хочу, чтобы пароли передавались по сети в виде открытого текста.

Я думаю, мой общий вопрос: Как я могу отправить конфиденциальные данные по небезопасному каналу?

Это мое текущее решение, и я хотел бы знать, есть ли в нем дыры:

1. Генерация случайного ключа на сервере (я использую php).
2. Сохраните ключ в сеансе, а также выведите ключ в переменной javascript.
3. При отправке формы используйте Triple DES в javascript с ключом для шифрования пароля.
4. На сервере расшифруйте пароль с помощью ключа из сеанса, а затем уничтожьте сеанс.

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

Answer 1

К ОЛИ

В вашем случае, например, я нахожусь в той же подсети с тем же маршрутизатором, поэтому я получаю тот же IP, что и мои коллеги в моей работе. Я открываю тот же URL в браузере, поэтому сервер генерирует метку времени с тем же ip, затем я использую дамп tcp / ip, чтобы прослушать хешированный или нехешированный пароль из моего соединения с коллегами. Я могу нюхать все, что он посылает. Так что у меня есть все хэши из его формы, также у вас есть метка времени (моя) и тот же IP. Поэтому я отправляю все, используя почтовый инструмент, и я вхожу в систему.

Answer 2

Самозаверяющий сертификат ssl не стоит денег. Для бесплатного сервиса твиттера это, вероятно, просто хорошо для пользователей.

Answer 3

Как я могу отправить конфиденциальные данные через небезопасный канал

С предварительным общим секретным ключом. Это то, что вы пытаетесь в предложенном решении, но вы не можете отправить этот ключ по небезопасному каналу. Кто-то упомянул DH, который поможет вам договориться о ключе. Но другая часть того, что делает SSL, - это обеспечение аутентификации, чтобы предотвратить атаки «человек посередине», чтобы клиент знал, что он согласовывает ключ с человеком, с которым он намеревается связаться.

Совет Криса Упчерча - действительно единственный хороший ответ для 99,99% инженеров - не делайте этого. Пусть кто-то другой сделает это и использует свое решение (как, например, парни, написавшие клиент / сервер SSL).

Я думаю, что идеальным решением здесь было бы заставить Twitter поддерживать OpenID, а затем использовать его.