Приветствую всех.

Хочу изложить идею еще одного механизма авторизации, и предложить всем заинтересующимся "взломать" ее.

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

При входе в админ. раздел, либо автоматически, либо по запросу администратора, без формы, передаются логин и пароль. Передаеются они вшитыми в изображение, которое программно рисуется на локальной машине. Сервер считывает логин/пароль, дает доступ, с условием, что все последующие запросы будут сопровождаться "картинной подписью", тоже программно рисуемое изображение, но содержащее некую подпись, о которой клиент осведомлен. При каждом запросе на авторизацию изображения логина/пароля и подписи изменяются. Весть механизм (как прочем и весь обмен интерфейса с сервером) построен исключительно на AJAX.  

Ниже (в прикреплении) представлены два "компьютерных Малевича", которые и содержат в себе одни и те же логин и пароль. И логин и пароль записаны в открытом виде.

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




Присоединённый файл ( Кол-во скачиваний: 12 )
 image.rar 2,76 Kb

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


Это жестоко, менять каждый раз логин и пароль.

Если на ряду с сессией использовать постоянно генерацию подписи! вот другое дело, то есть для каждого запроса (страницы) генерируется подпись, которая сохраняется в сессии,  и встраивается в страницу. Только вот генерировать рисунки с каждым запросом ....   
Вместо подписи генерировать символьный код и встраивать в его в страницу.
Впринципе может и есть смысл шифровать символьную подпись в рисунке, но только подпись. Так как она динамически изменяется при каждом запросе и о истинном коде, и алгоритме распаковки будет знать только сервер, который отдаёт аутентифицированному пользователю запакованный код подписи. Но опять же в виду генерации на каждый запрос это только для админки.
Кстати, если уж важна сильная безопасность, можно вводить рандомный выбор алгоритмов упаковки подписи для страницы и так же вносить его в сессию для следуещей распаковки.


И чего ... 

Это сообщение отредактировал(а) Sentox - 26.2.2012, 00:35

Вы либо невнимательно прочли, либо не поняли сути.

Изобретать всегда полезно, ведь по сути все новое, это забытое старое, но обретенное новые формы.

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

Да, есть стандартные инструменты - форма. Но перехватив ваш пароль, им можно будет пользоваться, и в сессию можно внедриться.

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

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

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

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

С каждым запросом на авторизацию изображение будет совсем уже иным, и если его перехватят, то воспользоваться им не смогут - сервер его не примет, ибо он не сможет прочесть его. Изменяется только изображение - размер, содержание, а логин и пароль не изменяются, с чего вы взяли?

Только вот генерировать рисунки с каждым запросом ....

А вы пробовали генерировать изображения такие как я генерирую? И сколько времени на это уходит? Если вас обескураживает время, то вы его не заметите, если вы о содержании, то рисовать "Девятый вал" Айвазовского в данном случае не требуется.

AJAX потому, что позволяет производить авторизаю автоматически, посему и интересует надежность. 

  

Task, это все уже сделано в ssl протоколе (https). И шифрование данных формы на клиенте и новый ключ на сессию... Если делается подобие ssl - то нужно проверять себя по нему, все ли шаги проделаны ;)

Не очень понятно кто будет генерировать картинку на клиенте. JS на canvas? Флешка? Отдельное приложение, которое нужно сначала поставит?

Поддерживаю, и как об этом поймёт сервер что изменился алгоритм распаковки рисунка? Как синхронизируются клиент с сервером? То есть как произведётся это действие 



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

. 
А что такого в запросе AJAX отличного от обычного в плане надёжности?


Несколько не понял, причём тут стандартная форма к сессии и алгоритму распаковки изо подписи? Кстати вот здесь управляющим элементом безопасностью является сервер что более правильно.

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

Отвечаю сразу всем )


1. По поводу высказывания, что авторизация происходит автоматически.
Нет, конечно она не потому автоматическая, что автоматику обеспечивает AJAX, я имел ввиду, что нет ни формы, ни запроса на авторизацию - инициатором ее выступает локальная машина, автоматически генерируя изображение и посредством AJAX отправляя его на сервер. Если все ОК, то дается доступ и сообщается, что вход произведен. В традиционном виде авторизации это форма, ввод, отправка формы.

2. По поводу SSL. 
Да в мире много чего уже сделано, но согласитесь, что не всегда все это доступно, в том числе и HTPPS. Так что об этом можно вообще не говорить. Собственно я и не пытаюсь что-то отменять из существующего, а тем  более противопоставлять ему свое.

3. По поводу генерации изображения - кто является "художником" в данном случае.
Еще раз прошу, прочтите внимательно то, что я написал в первом посте. Там сказано, что данный механизм служит исключительно для административного раздела, и что данный раздел (его интерфейс управления) полностью находится на локальной машие. Вот это, что его держать на локалной машине на 100% выгоднее, чем на сервере, я не просто убежден, я в этом давно убедился, ибо свои таковые разделы я помещаю именно на локалную машину, обмениваясь с сервером только "голыми" данными.
Что это дает? Самое ценное, это обширный инструментарий под рукою, интеграция этого инструментария с приложениями, и т.п..
На чем писать такой инструментарий, это уже по желанию, но под Win вполне хватает HTA как основное приложение, плюс JavaScript, VBsvript. А что-то поставить еще из библиотек необходимых - какая сложность?

"Не очень понятно кто будет генерировать картинку на клиенте. JS на canvas? Флешка?"

И это все, которые способны рисовать? Во-первых - на локалной машине вам доступны средства WinAPI, во-вторых - существует масса библиотек сторонних. В моем случае я применил именно стороннюю, свободно распространяемую библиотеку GflAX, именно она выступает в качестве "художника" будучи подключенной в JavaScript как ActiveXObjec. Выбор пал на стороннюю, а не на WinAPI, только потому, что в первом случае писать меньше, и проще. Думаю, что вам не надо объяснять, что подключение ее непосредственно из приложения (HTA) задача очень простая, и при этом совсем не обязательно трогать системную директорию ОС.

4. "Ещё раз, если изображение будет перехвачено в течении сессии то это изображение нет смысла расшифровывать просто можно "скормить" серверу."
Нет, не получится - уже отосланный экземпялр устаревает сразу при получении его сервером, то есть, перхваченное изображение уже не сработает, сервер будет ожидать совсем иного. Условно скажем так:
в прикрепленном архиве два изображения, пусть это будут запросы на аторизацию А и В. Сервер "знает", что в случае авторизации А, он должен получить именно первое изображение, а для следующей авторизации (В) должно прийти только изображение второе, первое уже не действительно. И так далее. Чтобы задействовать перехваченное изображение, вор должен действовать с авторизуемым синхронно, что не выполнимо практически.  Как это происходит в реальности, каков алгоритм всего, я конечно не буду рассказывать, собственно у вас своей фантазии полно, чтобы написать свой алгоритм, если таковой потребуется.
И сессия в данном случае вообще не применяется, она исключена из процесса авторизации полностью, куки тоже не устанавливаются.
Вместо них дальнейшим связующим сервер/клиент служит "графическая подпись".

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

Это сообщение отредактировал(а) Task - 26.2.2012, 16:19

доступ к веб-панели только с 127.0.0.1 и точка   



API или СУБД открываете во внешку?

И всё же я не услышал, как сервер осведомляется о применённом алгоритме упаковки пароля в изображение что бы его считать из рисунка? То есть, если каждый раз рисунок другой, а логин\пароль одни и те же, серверу нужно сообщить как распаковать рисунок и считать содержимое. Если алгоритм распаковки из рисунка на сервере пароля\логина один и тот же какой смысл в постоянной перепаковке в разные рисунки? 

Это сообщение отредактировал(а) Sentox - 26.2.2012, 17:23

API или СУБД открываете во внешку?

Работа с базой происходит точно так же, как и в обычном случае - запрос, выдаем то, что просили. Отличие только в том, что через AJAX передаются только данные, html шаблоны находятся у клиента.

И всё же я не услышал, как сервер осведомляется о применённом алгоритме упаковки пароля в изображение что бы его считать из рисунка?

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

Если алгоритм распаковки из рисунка на сервере пароля\логина один и тот же какой смысл в постоянной перепаковке в разные рисунки? 

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

Это сообщение отредактировал(а) Task - 26.2.2012, 19:25

Нонсенс

Добавлено через 4 минуты и 1 секунду
По теме.
Автор, вы априори исходите из небезопасного соединения. Т.е. что ваши данные могут перехватываться.

Поэтому если вы не применяете шифрование, то никакие картинки не помогут.

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

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

Я никоим образом не претендую на авторство идеи, но и вшивать можно по разному.

У вас целая куча проблем:

•  Мне неинтересно разбирать конкретно ваш алгоритм шифрования (если он есть)
•  Я не пью и коньяк меня не мотивирует. Можем поговорить о 2к у.е., тогда я подумаю над тем чтобы взяться за это (но маловероятно, ибо с самокритикой у меня все хорошо и я понимаю что не специалист по криптостойкости, а значит 2-4 недель будет мне недостаточно)
•  Это не форум специалистов по криптографии. А значит тестирование не имеет практической ценности
•  Безопасность вашей авторизации не имеет ровно никакого значения, если все остальное идет открытым текстом. Т.е. у вас вместо пароля могут перехватить ключ сессии к примеру. Подменить мак и айпи адрес и вместо вас слать серверу чего-нибудь эдакого.

Это сообщение отредактировал(а) Fortop - 26.2.2012, 21:36

Fortop, наконец-то. 

Теперь можно поговорить по существу всех недостатков высера инновации ТС.

1. Весь тред крутится около изображений. Вопрос автору "Зачем?" задавать я думаю бессмысленно. Изображения в данной схеме не несут абсолютно никакой функциональности, то есть автор фактически передает открытую информацию преобразованную (закодированную) неким алгоритмом (набором алгоритмов).

2. Шифрования, насколько я понял нет, и в помине.

3. То есть вся схема строится на секретности алгоритма (набора алгоритмов) что уже не безопасно. Плюс как уже сказали необходимость наличия протокола синхронизации алгоритмов. 

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

5. Такая схема очевидно уязвима перед атакой "Man in the middle".

6. Стоит отметить, что современная криптография базируется на принципе Керкгоффса, и автору было бы неплохо с ним ознакомиться.

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

Итог. Вся схема автора строится на принципе Security through obscurity. Очевидные недостатки которой автор, я думаю, в состоянии узнать из авторитетных источников.

P.S. Тут были упомянуты средства WinAPI и прочие 3rd party библиотеки, доступные через COM. То есть на кроссбраузерность и кроссплатформенность придется забить. 

P.S. и почему я всегда замечаю, что к псевдонаучным трудам в области безопасности тянутся исключительно пхпшники.

Добавлено через 12 минут и 34 секунды


Этот трюк, а точнее один из методов сокрытия информации, известной как стеганография, предназначен именно для, внимание, сокрытия факта наличия информации на каком-либо носителе, коим может быть изображение, аудио-дорожка, etc. Здесь же никакого сокрытия факта передачи нет. Так как заранее известно что изображение является просто аналогом ключа.

Это сообщение отредактировал(а) cutwater - 26.2.2012, 22:10

Ну вот и веские доводы, наконец-то. Все ясно.

Нет, я не ради самоутверждения, я далек от себялюбия.

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

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

Это сообщение отредактировал(а) 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

[QUOTE=Task,2.3.2012,  06:46]
Поддерживаю cutwater просто нужно разобраться что данные, которые отсылаются на сервер перехватываются и без расшифровывания  используются по середине рассоединяя TCP канал (вклиниваясь).

Вот для понимания, вконце вопросы которые описывают балее стабильную защиту от MITM:




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