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

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

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

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

1. Generate a random key on the server (I'm using php).
2. Save the key in a session and also output the key in a javascript variable.
3. On form submit, use Triple DES in javascript with the key to encrypt the password.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How can I send sensitive data over an insecure channel

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

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

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

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

В OLI

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

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

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

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

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

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

API и OAuth

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

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

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

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

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

In the original description, the Diffie–Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack. A person in the middle may establish two distinct Diffie–Hellman key exchanges, one with Alice and the other with Bob, effectively masquerading as Alice to Bob, and vice versa, allowing the attacker to decrypt (and read or store) then re-encrypt the messages passed between them. A method to authenticate the communicating parties to each other is generally needed to prevent this type of attack. Variants of Diffie-Hellman, such as STS, may be used instead to avoid these types of attacks.

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

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

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

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

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

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