Вы не правы. В данном случае передается именно информация, а ключом обладает клиент и сервер.

Все как-то в кучу смешалось. При чем тут кроссбраузерность, упоминание СОМ, если я все время говорил где это выполняется. Если уж и говорить об этом, то не о кроссбраузерности, а кроссплатформенности, но разве это проблема?
А что гарантированно не может быть атаковано способом "человек посередине"?  

Это сообщение отредактировал(а) Task - 27.2.2012, 07:24

Вопрос не в том, что не может быть атаковано.
А в том, насколько ваш механизм устойчив к таким атакам.

Настолько же, насколько уязвимо и все иное.

Да, прошу прощения. Некорректно выразился. Заранее известно, что в изображении передается аутентификационная информация.



Вы заблуждаетесь. Вы можете почерпнуть интересующую вас информацию из соответствующей литературы.


Это сообщение отредактировал(а) cutwater - 27.2.2012, 12:30

И что, что известно?

 

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

Это сообщение отредактировал(а) cutwater - 27.2.2012, 13:31

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

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

Если уж важна безопасность сделайте SMS на свой телефон да и всё 

Это сообщение отредактировал(а) Sentox - 27.2.2012, 14:57

Я понимаю, что пртокол, но не весь Интернет на ssl. Fortop правильно заметил, что я исхожу от небезопасного соединения. При MitM я смогу проверить целостность структуры данных, нарушения этой структуры, а вот достоверность самих данных, тут да, это проблематично.

Вам не нужен весь. Вам нужен один конкретный ваш! сервер, который будет поддерживать такие соединения

Добавлено через 1 минуту и 45 секунд
А вообще...
Попробуйте разрушить собственный миф сами.

Критическое отношение к своим же идеям принесет вам пользу

А при чем тут лично мои предпочтения? Неважно, что я имею или чего мне хочется.

Тут, видимо, непонимание. Надо его устранить.

У топикстартера УЖЕ есть админка, которая админит пучек сайтов(?) и которая полностью удовлетворяет ТС, не смотря и даже благодаря тому, что работает под win. К сожалению, администрируемые сайты размещаются на серверах, на которых нельзя поднять ssl по тем или иным причинам и предлагается вариант наворачивания секретности на поток данных между админкой и сайтом.

Так что 
-- SSL - нет. 
-- на стороне клиента довольно могучее приложение, которое умеет много
-- на стороне сервера PHP и все.

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

Сайты могут быть перемещены.

Ситуация когда SSL нет и его невозможно поставить, но нужна сопоставимая защищенность - идет в топку, вместе с придумавшим ее.

Во всех остальных случаях - ТС может слать данные открытым текстом или пользуясь чем-то из этого http://www.php.net/manual/en/book.mcrypt.php
Все.

Остальное от лукавого.

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

Почему все-таки изображение. Потому, что:
а) уже при идентификации запроса на сервере я достаточно просто узнаю, что мне подсовывают, если не изображение, то... В случае к примеру с просто бинарными данными, мне бы потребовалось их сперва перебрать, что не разумно;
б) легче разобрать и считать данные именно средствами GD, ну так уж сделано.

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

Теперь о MitM. Что я могу реально сделать:
а) на серверной и клиентской сторонах  просчитать контрольную сумму передаваемых данных;
б) эта контрольная сумма передается с данными, но не отдельным значением, а вшита непосредственно в поток данных;
в) клиент и сервер знают как извлечь эту сумму из потока;
г) извлекаем, проверяем, резюме...

Как на ваш вгляд?  


Это сообщение отредактировал(а) Task - 2.3.2012, 06:48

Task,  идиотизм крепчал.




Форменный бред. Достаточно иметь сигнатуру, например первые несколько байт, по которым можно определить тип содержимого (правда это ничего не гарантирует)
Вывод. Сэр не осилил работу с байтами.




О чем уже я говорил выше, все это не имеет смысла, пока вся защита строится на основе секретности алгоритма.

Выводы: Тему на свалку. Автору грызть гранит науки и перестать страдать херней.

P.S. О бритве Оккама автор вероятно никогда в жизни не слышал.

Это сообщение отредактировал(а) cutwater - 2.3.2012, 18:55