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

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Чтобы ответить на ваш общий вопрос: вы просто отправили его. Я думаю, что ваш реальный общий вопрос: & ldquo; Как отправить конфиденциальные данные по небезопасному каналу & mdash; и держать его в безопасности? & rdquo; Вы не можете.

Похоже, вы решили, что безопасность не стоит 10 - 20 долларов США в месяц, а сертификат будет стоить, и для защиты паролей в Twitter это, вероятно, правда. Итак, зачем тратить время на иллюзию безопасности? Просто дайте своим пользователям понять, что их пароль будет отправлен в открытом виде, и пусть они сами сделают выбор.

Answer 4

API и OAuth

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

Обмен ключами

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

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

Со страницы Википедии на Диффи Хеллман :

В оригинальном описании Обмен Диффи-Хеллмана сам по себе не обеспечивает аутентификацию взаимодействующие стороны и, таким образом, уязвимы для атака "человек посередине". Человек посередине может установить два различные обмены ключами Диффи-Хеллмана, один с Алисой, а другой с Бобом, эффективно маскируясь под Алису Бобу, и наоборот, позволяя злоумышленнику расшифровать (и прочитать или сохранить), а затем повторно шифровать сообщения, передаваемые между ними. Метод аутентификации общение сторон друг с другом, как правило, необходимо для предотвращения этот тип атаки. Варианты Диффи-Хеллмана, такие как STS , могут быть вместо этого используется, чтобы избежать атак такого типа.

Даже STS небезопасен в некоторых случаях, когда злоумышленник может вставить собственную идентификационную информацию (ключ подписи) вместо отправителя или получателя.

Идентификация и аутентификация

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

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

Вы можете получить бесплатные сертификаты SSL, действительные в течение 1 года, с https://www.startssl.com/ - я использую их для своих личных сайтов. Они не так «доверяют», что бы это ни значило, поскольку они выполняют автоматические проверки только тех, кто подает заявку, но это бесплатно. Есть также услуги, которые стоят очень мало (£ 10 / год от 123-Reg в Великобритании).

Answer 5

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

Диффи-Хеллман - хорошее решение. Если вам нужно только подтвердить их подлинность, а не передать пароль (так как пароль уже хранится на сервере), вы можете использовать HTTP Digest Authentication или некоторые другие варианты.

Answer 6

Так как же это безопаснее? Даже если у вас есть защищенный браузер <> вашего сервера, как насчет остальной части Интернета (ваш сервер <> твиттер)?

ИМХО, недопустимо спрашивать имя пользователя и пароль другого сервиса и ожидать, что люди его введут. И если вас это очень волнует - не интегрируйте их, пока они не прояснят свои действия и не включат снова OAuth . (Они поддерживали его некоторое время, но отключили несколько месяцев назад.)

А почему бы не предложить OpenID? У каждого аккаунта Google, Yahoo !, VOX и т. Д. Есть один. Люди могут не знать об этом, но шансы действительно, очень высоки, что у них уже есть OpenID. Проверьте этот список , чтобы понять, что я имею в виду.

Answer 7

Проблема с безопасностью JavaScript на стороне клиента заключается в том, что злоумышленник может изменить транзитный javascript до простого {return input;}, тем самым создавая ваш сложный вопрос безопасности. Решение: использовать предоставляемый браузером (т.е. не передаваемый) RSA. Из того, что я знаю, пока нет.

Answer 8

Я реализовал другой подход

1. Сервер: имя пользователя и пароль-хэш хранятся в базе данных
2. Сервер: отправьте запрос с формой для запроса пароля, сохраните его в сеансе с отметкой времени и IP-адресом клиента
3. Клиент: хэшируйте пароль, вызов concat | username | hash password, снова хэшируйте его и отправляйте на сервер
4. Сервер: проверьте метку времени, IP, сделайте то же самое объединение / хэширование и сравните его

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

Есть какие-нибудь комментарии по этому поводу?

Answer 9

У меня похожая проблема (желание зашифровать данные в формах без оплаты ssl-сертификата), поэтому я немного поохотился и нашел этот проект: http://www.jcryption.org/

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

Answer 10

Если вы не хотите использовать SSL, почему бы не попробовать какой-нибудь другой протокол, например, Kerberos?

Базовый обзор здесь: http://www.kerberos.org/software/tutorial.html

Или, если вы хотите углубиться, см. http://www.hitmill.com/computers/kerberos.html