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

Question

Я использую API-интерфейс basic-auth twitter (no longer available) для интеграции twitter с системой комментариев моего блога. Проблема с этим и многими другими веб-интерфейсами заключается в том, что они требуют, чтобы пользовательское имя пользователя и пароль делали что-нибудь полезное. Я не хочу иметь дело с хлопотами и стоимостью установки SSL-сертификата, но я также не хочу, чтобы пароли передавались по проводу в ясном тексте.

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

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

Все комментарии по этому вопросу?

Answer 7

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

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

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

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

Answer 8

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

Answer 9

ДЛЯ ОЛИ

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

Answer 10

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

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

Или, если вы хотите пойти несколько более подробно см http://www.hitmill.com/computers/kerberos.html

Answer 11

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

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

Answer 12

API, и OAuth

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

Key Exchange

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

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

На странице Википедии на Diffie Hellman:

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

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

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

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

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

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

Answer 13

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