Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Безопасность передачи данных  (Прочитано 14951 раз)
0 Пользователей и 1 Гость смотрят эту тему.
yudjin
Помогающий

ua
Offline Offline
Пол: Мужской

« : 11-11-2010 07:00 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 11-11-2010 07:36 » 

Цитата: yudjin
Но могут перехватить хэш... А ведь сервер работает с хэшом (сверяет в БД в данном случае, и если хэш пароля совпадает с логином то открывает доступ).
Это полное отсутствие шифрования. Просто такие вот логин и пароль - неудобочитаемые. Раз ты делаешь прямое сравнение.

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
yudjin
Помогающий

ua
Offline Offline
Пол: Мужской

« Ответ #2 : 11-11-2010 07:59 » 

Цитата: yudjin
Но могут перехватить хэш... А ведь сервер работает с хэшом (сверяет в БД в данном случае, и если хэш пароля совпадает с логином то открывает доступ).
Это полное отсутствие шифрования. Просто такие вот логин и пароль - неудобочитаемые. Раз ты делаешь прямое сравнение.
Именно.

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

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

Вот что советовали:
Цитата
еще есть вариант использовать md5 на стороне клиента, для этого есть решения на javascript. вроде как тоже должно улучшить безопасность, т.к. пароль не передается.
Генерить на клиенте публичный ключ каждый раз перед отправкой пароля, шифровать в RSA, передавать шифр.
На сервере расшифровывать закрытым ключем так?
Но ведь злоумышленник перехватит шифр - и опять таки может его послать на сервер - сервер его расшифрует и подтвердит доступ... Не совсем понято
Записан
Kivals
Команда клуба

ca
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 11-11-2010 09:07 » 

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

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

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

ua
Offline Offline
Пол: Мужской

« Ответ #4 : 11-11-2010 10:11 » 

Механизм ясен. Как доберусь - столкнусь с проблемами - тогда с вами еще поговорим Улыбаюсь
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 11-11-2010 11:01 » 

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

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

Код:
// if (doForm.user.value.indexOf("@") != -1)
return;
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
yudjin
Помогающий

ua
Offline Offline
Пол: Мужской

« Ответ #6 : 18-11-2010 10:42 » 

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

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

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

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

Т.е. вы не хешируете вообще
« Последнее редактирование: 18-11-2010 10:53 от yudjin » Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #7 : 18-11-2010 11:46 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
yudjin
Помогающий

ua
Offline Offline
Пол: Мужской

« Ответ #8 : 18-11-2010 12:01 » 

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #9 : 18-11-2010 12:41 » 

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

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

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


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

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

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

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

Я к чему? Хочешь повышенной секретности - используй HTTPS.
« Последнее редактирование: 18-11-2010 13:09 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
yudjin
Помогающий

ua
Offline Offline
Пол: Мужской

« Ответ #10 : 18-11-2010 13:11 » 

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #11 : 18-11-2010 13:20 » 

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

Если у тебя нет завязки на браузеры и JS, то проблема решается проще. Смотри пост №9 - нужно организовать первоначальный обмен публичными ключами, после чего пользоваться ими для секретных сообщений.
« Последнее редактирование: 18-11-2010 13:24 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Chaa
Помогающий

ru
Offline Offline
Пол: Мужской

« Ответ #12 : 19-11-2010 11:13 » new

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

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines