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

Ответ 1

• Создайте случайный ключ на сервере (я использую php).
• Сохраните ключ в сеансе, а также выведите ключ в переменной javascript.
• В форме submit используйте Triple DES в javascript с ключом для шифрования пароля.

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

API и OAuth

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

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

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

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

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

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

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

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

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

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

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

Ответ 7

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

• Сервер: имя пользователя и пароль-хэш, хранящиеся в базе данных
• Сервер: отправьте запрос с формой для запроса пароля, сохраните его в сеансе с меткой времени и IP-адресом клиента.
• Клиент: hash пароль, concat challenge | username | passwordhash, hash it again и отправить его на сервер
• Сервер: проверьте временную метку, IP, выполните одно и то же конкатенацию/хеширование и сравните ее.

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

Любые комментарии по этому поводу?

Ответ 8

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

Ответ 9

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

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

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

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

Ответ 10

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

Ответ 11

TO OLI

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

Ответ 12

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

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

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

Ответ 13

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

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