Безопасность передачи данных

[yudjin]

без SSL как-то можно?
Расшевелил гугл - предлогали шифровать пароль на клиенте JS'ом и пересылать хэш на сервер. Да, пароль не перехватят в чистом виде. Но могут перехватить хэш... А ведь сервер работает с хэшом (сверяет в БД в данном случае, и если хэш пароля совпадает с логином то открывает доступ). Кто как поступает?

[Dimka]

Но могут перехватить хэш... А ведь сервер работает с хэшом (сверяет в БД в данном случае, и если хэш пароля совпадает с логином то открывает доступ).

Это полное отсутствие шифрования. Просто такие вот логин и пароль - неудобочитаемые. Раз ты делаешь прямое сравнение.

предлогали шифровать пароль на клиенте JS'ом и пересылать хэш на сервер.

Поточнее. Если просто на JavaScript написать алгоритм шифрования, то нет ничего проще взломщику скопировать исходник этого алгоритма и пользоваться им в своё удовольствие.

Смотри в сторону алгоритмов шифрования с открытым ключом.

[yudjin]

Но могут перехватить хэш... А ведь сервер работает с хэшом (сверяет в БД в данном случае, и если хэш пароля совпадает с логином то открывает доступ).

Это полное отсутствие шифрования. Просто такие вот логин и пароль - неудобочитаемые. Раз ты делаешь прямое сравнение.

Именно.

предлогали шифровать пароль на клиенте JS'ом и пересылать хэш на сервер.

Поточнее. Если просто на JavaScript написать алгоритм шифрования, то нет ничего проще взломщику скопировать исходник этого алгоритма и пользоваться им в своё удовольствие.

Смотри в сторону алгоритмов шифрования с открытым ключом.

Вот что советовали:

еще есть вариант использовать md5 на стороне клиента, для этого есть решения на javascript. вроде как тоже должно улучшить безопасность, т.к. пароль не передается.

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

[Kivals]

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

Хеш разный для каждой сессии (из-за уникальности случайной комбинации)
Можно брать не Пароль+СлучайнаяКомбинация а ХешПароля+СлучайнаяКомбинация (чтобы серверу не пришлось хранить пароль у себя)

P.S. Если еще подумать и реализовать все возможные нюансы - получим на выходе SSL, реализованый на JS

[yudjin]

Механизм ясен. Как доберусь - столкнусь с проблемами - тогда с вами еще поговорим

[RXL]

yudjin, посмотри вот это: https://forum.shelek.ru/Themes/default/script.js
См. функцию hashLoginPassword.

Когда разработчики внедрили эту хрень (SMF 1.0), то начались массовые проблемы с логинами. По этому у нас закомментирована одна строка:

Код:

//	if (doForm.user.value.indexOf("@") != -1)
		return;

[yudjin]

А если у пользователя отключены Java скрипты? Кто будет шифровать данные... Извините за наивные вопросы
Можно, конечно, его заставить их включить

yudjin, посмотри вот это: https://forum.shelek.ru/Themes/default/script.js
См. функцию hashLoginPassword.

Когда разработчики внедрили эту хрень (SMF 1.0), то начались массовые проблемы с логинами. По этому у нас закомментирована одна строка:

Код:

//	if (doForm.user.value.indexOf("@") != -1)
		return;

Т.е. вы не хешируете вообще

[RXL]

А нафига? Man in middle может почти  все и передача хеша не повысит секретности.

[yudjin]

Подождите, как это? Способ Kivals выглядит очень убедительным. Если Man in the middle перехватит сообщение - оно будет закодировано. Ведь всевозможные MD5 и RSA не поддаются расшифровке без знания закрытого ключа, который хранится на сервере.

[RXL]

Э... Какое такое шифрование и ключ с SHA1/MD5? Это не алгоритмы шифрования - это хеш-функции! Они из входной последовательности произвольной длины получают последовательность постоянной длины и не более. Восстановить исходную последовательность невозможно.

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

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


Добавлено через 21 минуту и 1 секунду:
Принцип секретного обмена с асимметричным ключем такой:

0. Каждая сторона имеет пару собственных ключей - приватный и публичный. Для повышения секретности обе стороны для разных соединений генерят новую пару ключей (на практике, из-за затратности данного процесса, ключи обновляют периодически, скажем, раз в час).
1. Одна сторона создает случайную последовательность, которую шифрует своим приватным ключом и передает полученное и публичный ключ второй стороне.
2. Вторая сторона с помощью полученного ключа дешифрует сообщение и получает исходную последовательность. Далее она шифрует эту последовательность своим приватным ключом, а также шифрует свой публичный ключ полученным публичным. Все это отсылается назад. В дальнейшем для шифрования используется публичный ключ первой стороны.
3. Первая сторона дешифрует полученный публичный ключ и в дальнейшем использует его для шифрования. Также дешифрует публичным ключом второй стороны исходную последовательность и тем удостоверяется, что обмен произведен верно.

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

Алгоритм я описал очень примерно. При использовании SSL (HTTPS) именно так производится начальный обмен ключами.
Если нужно передавать большие объемы, дальше используются динамически генерируемые блочные ключи. Это из-за того, что алгоритмы типа RSA требуют больших вычислительных ресурсов (т.е. написать его на JS весьма затруднительно).

Я к чему? Хочешь повышенной секретности - используй HTTPS.

[yudjin]

Конфликты между схемами возникают... Сложная архитектура: пишу клиент для сервера картографических данных от ESRI, использую WCF, Silverlight, ArcGIS сервер. Все это не уживается на перекрестных схемах (http-https), это подтверждают и сами ESRI-евцы. Перехожу на http, но нужно передавать безопасно пароли-логины, не более.
Как быть? https отпадает однозначно

[RXL]

В виду того, что MID знает все, что сообщают друг другу клиент и сервер, то:
1. Забить на "безопасно". Делаем допущение, что канал не прослушивается.
2. Использовать некую информацию, которую знаю обе стороны, но в канале она не гуляет. Правда, все равно нужен некий алгоритм и лучше всего - асимметричный.
3. Попытаться реализовать RSA. Кстати, поиск говорит:
http://www.ohdave.com/rsa/
http://www-cs-students.stanford.edu/~tjw/jsbn/rsa2.html

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

[Chaa]

Единственный нормальный вариант - все-таки HTTPS.
Проблема, как я понял, в том, что некая веб-служба (от ESRI) не может работать с этим протоколом.
Тут надо посмотреть, где именно ожидается перехват трафика. И поставить прокси HTTP <-> HTTPS так, чтобы его трафик до веб-службы доходил нормально, а клиенты работали с вашим прокси по защищенному HTTPS.